Reproducibility in Practice: A Researcher's Checklist for Work Others Can Verify

Reproducibility, the ability of others to obtain the same results from the same data and methods, is a basic expectation of science. Yet many published findings cannot be reproduced, even by their own authors, because data are missing, code is lost, steps are undocumented or software has changed. Making research reproducible does not require heroic effort. It requires habits built into everyday work: organising files, documenting decisions, scripting analyses and sharing materials. This guide sets out a practical checklist for researchers in any discipline and explains how a source-linked research assistant such as Yila can support the related task of keeping the literature behind your work traceable.

Reproducibility, replicability and why they matter

Terms vary across fields, but a common distinction is:

• Reproducibility: obtaining the same results using the original data and analysis.
• Replicability: obtaining consistent results in a new study that collects new data.

Both matter, and reproducibility comes first. If an analysis cannot be reproduced, it is impossible to know whether a failed replication reflects a real difference or an error in the original. Reproducible work also benefits its authors: it is easier to revise after peer review, to build on in later projects and to hand over to new team members.

1. Organise your project from the start

A consistent folder structure saves time and prevents mistakes. A simple layout might include:

• data/raw for original, untouched data;
• data/processed for cleaned and derived data;
• code for scripts;
• output for figures and tables;
• docs for protocols, notes and documentation.

Never edit raw data by hand. Keep it read-only and make every change through code, so the path from raw to processed data can be repeated. Use clear, consistent file names, avoid spaces and include dates in a sortable format where needed.

2. Script your analysis

Point-and-click analyses are hard to reproduce because the steps are not recorded. Writing analyses as scripts in a language such as R, Python or Stata creates a record of exactly what was done. Even if you explore data interactively, convert the final analysis into a script that runs from start to finish.

Good scripts:

• run without manual intervention;
• use relative file paths rather than paths specific to one computer;
• set random seeds for any procedure involving randomness;
• are divided into logical steps, such as cleaning, analysis and figures;
• include comments explaining why, not just what.

Test reproducibility by running the entire pipeline on a clean machine or in a fresh environment.

3. Use version control

Version control systems such as Git record every change to your code and documents, along with who made it and why. They make it possible to return to earlier versions, compare changes and collaborate without overwriting each other's work. Commit regularly with informative messages. Tag the version used for each submitted manuscript so you can always recover it.

Version control has a learning curve, but basic use, such as committing changes and viewing history, can be learned in an afternoon.

4. Record the computing environment

Results can change when software versions change. Record the versions of your programming language, packages and operating system. Tools such as package lock files, environment specifications or containers make it possible to recreate the environment later. At minimum, include a session information output in your project documentation.

5. Document data thoroughly

Data without documentation are of limited use. Create a data dictionary describing every variable: its name, meaning, units, coding and allowed values. Document how data were collected, cleaned and transformed. Note any known problems, such as measurement errors or changes in procedures.

A README file at the top of the project should explain what the project is, how files are organised, how to run the analysis and whom to contact with questions.

6. Keep a research log

Many decisions in a project are never written down: why a participant was excluded, why a variable was transformed, why a model was changed. A dated research log, kept alongside the code, captures these decisions. It makes writing the methods section easier and helps you answer reviewers' questions months later.

7. Keep your literature traceable

Reproducibility extends to the claims in your introduction and discussion. Readers should be able to check that the studies you cite say what you say they do. Keep a reference manager library linked to the project, store notes on key papers and record where specific claims come from, including page or section numbers for important facts.

Research assistants that link each statement to a source can help you build and verify this trail. Always open the source and confirm the claim before citing it. Unverified citations can propagate errors through the literature just as unreproducible analyses do.

8. Share data, code and materials

Where ethics and law allow, share the data and code needed to reproduce your results. Deposit them in a trusted repository that issues persistent identifiers, rather than on a personal website that may disappear. Choose an appropriate licence so others know how they can use the materials.

If data cannot be shared because of confidentiality, share code, synthetic data or detailed descriptions of how qualified researchers can access the data. Partial sharing is better than none.

Also share materials such as questionnaires, stimuli and protocols. These are essential for replication.

9. Report methods completely

Reporting guidelines exist for many study designs and specify the information readers need. Follow the relevant guideline and include a completed checklist with your submission. Report all analyses you ran, not only those in the final paper, or explain how you selected them. State which analyses were planned and which were exploratory.

10. Check before submission

Before submitting a manuscript, run a reproducibility check:

• Delete all outputs and rerun the full pipeline.
• Confirm that every number, table and figure in the manuscript matches the outputs.
• Ask a colleague to run the code on their computer using only your instructions.
• Verify that shared files are complete and accessible.

This check often reveals small errors, such as a figure generated from an older version of the data, that would otherwise reach print.

Building a reproducible culture

Individual habits are easier to maintain when the team shares them. Labs and groups can adopt common folder templates, coding standards and review practices, such as having a colleague check analysis code before submission. Supervisors can teach reproducible methods to students from the start. Institutions can support training and provide infrastructure for data storage and sharing.

Common objections

• "It takes too much time." Reproducible habits take time to learn but save time later, especially during revision.
• "My data are too sensitive." Code, materials and documentation can still be shared.
• "Others will find mistakes." Finding mistakes is the point. Correcting them strengthens science and your reputation.
• "Nobody will use my materials." Many shared datasets and scripts are reused in ways their creators never anticipated.

Conclusion

Reproducibility is built from small, consistent practices: organised files, scripted analyses, version control, documented environments and data, a research log, traceable citations and shared materials. None of these is difficult on its own, and together they make research more reliable and easier to build upon. Tools such as Yila can help you keep the literature side of your work verifiable, while good data and code practices take care of the rest. Start with one or two habits on your next project, and add more as they become routine.