Zubair Khalid

Virologist/Molecular Biologist | Veterinarian | Bioinformatician

Conventional & Molecular Virology • Vaccine Development • Computational Biology

Dr. Zubair Khalid is a veterinarian and virologist specializing in conventional and molecular virology, vaccine development, and computational biology. Dedicated to advancing animal health through innovative research and multi-omics approaches.

Dr. Zubair Khalid - Veterinarian, Virologist, and Vaccine Development Researcher specializing in Computational Biology, Multi-omics, Animal Health, and Infectious Disease Research

Category: Guides

Reproducible Research Workflows: A Practical Guide to Version Control, Preregistration, and Open Science

Reproducible research means that an independent researcher can take your raw data, your analysis code, and your documented methods, and obtain the same results you reported. For life-science professionals, students, and researchers, this is not an abstract ideal. It is a practical requirement for building on prior work, for defending findings in peer review, and for ensuring that published conclusions can be verified. This article provides a concrete workflow for implementing reproducibility in your own projects, covering version control with Git, preregistration of study designs, and the use of computational notebooks. The focus is on life-sciences applications, where wet-lab experiments, clinical data, and computational analyses increasingly intersect.

Why Reproducibility Fails in Practice

The gap between what researchers intend to share and what they actually share is wide. Traditional publication practices often fail to provide a comprehensive description of the research context and procedures, which hinders reproducibility. A tutorial on reproducible research using the R programming language notes that many studies across disciplines fail to be fully reproduced due to inadequate dissemination methods. The tutorial covers three essential components: version control using Git, dynamic document creation using rmarkdown, and managing R package dependencies with renv. These tools address specific failure points that researchers encounter regularly.

The cost of irreproducibility is substantial. Estimates of the cost of irreproducible preclinical studies range from 28 billion USD per year in the USA alone to over 200 billion USD per year worldwide. Reproducibility in psychological research has been estimated to be below 50 percent. For computational modeling, the problem may be more severe than for laboratory experiments, based on replication studies of agent-based models. These figures matter because they represent wasted funding, wasted effort, and delayed scientific progress.

For simulation research specifically, problems of reproducibility in agent-based simulations of life and social science problems have been documented. Drawing on best practices research in computer science and in wet-lab experiment design and execution can improve simulation research practice. The same principles that govern good laboratory record keeping apply to computational work, but the tools differ.

Core Principles of a Reproducible Workflow

A reproducible workflow rests on four principles that apply across experimental and computational research. These principles guide the specific practices described in later sections.

Version Control for Everything

Version control tracks changes to files over time. For research, this means tracking changes to analysis code, data-processing scripts, configuration files, and even manuscript drafts. Distributed version control systems such as Git provide a complete audit trail of all relevant study documents. A practical introduction to reproducible analytic workflows using Git and R explains how these tools can be used to track changes, collaborate, disseminate, and archive studies through dedicated project repositories. The audit trail matters because it allows you to answer the question, "What exactly did I do to produce this result?" at any point in the future.

Preregistration of Study Design

Preregistration means recording your study design, hypotheses, and analysis plan before you collect data or conduct analyses. This practice distinguishes confirmatory analyses, which test pre-specified hypotheses, from exploratory analyses, which search for patterns without prior specification. A call for preregistration of in vitro research argues that preregistration can serve as a tool to improve reproducibility and transparency in laboratory research, beyond in clinical trials. The rationale is that preregistration prevents the subtle pressure to report only analyses that produced interesting results.

Computational Notebooks for Analysis

Computational notebooks combine code, results, and narrative text in a single document. Jupyter notebooks, for example, provide a document format for publishing code, results, and explanations in a form that is both readable and executable. Notebooks combine detailed workflows with narrative text and visualization of results. Combined with software repositories and open source licensing, notebooks are powerful tools for transparent, collaborative, reproducible, and reusable data analyses. For researchers with varying levels of programming experience, notebook environments make image-analysis software development accessible through simplified interfaces.

Metadata and Provenance

Metadata provide context and provenance to raw data and methods and are essential to both discovery and validation. Reproducible computational research packages the transformation of raw data to published results. Metadata standards support reproducibility across an analytic stack consisting of input data, tools, notebooks, pipelines, and publications. Without metadata, a data file is just a collection of numbers. With metadata, it becomes interpretable evidence.

At a Glance: Reproducibility Tools and Their Roles

The following table summarizes the primary tools discussed in this article, their main functions, and the research stage where they apply.

Tool or Practice Primary Function Research Stage Typical Users
Git and distributed version control Track changes to code, data, and documents, maintain audit trail Throughout the project lifecycle All researchers doing computational work
Preregistration platforms and study design tools Record hypotheses and analysis plans before data collection Before data collection Clinical researchers, in vitro researchers, social scientists
Jupyter Notebooks Combine code, results, and narrative in executable documents Analysis and publication Researchers with varying programming skills
Dependency management tools such as renv Pin package versions to ensure code runs identically Analysis and publication R users, Python users
Metadata standards and data repositories Provide context and provenance for raw data Data collection, sharing, and publication All researchers

Setting Up Version Control with Git

Git is a distributed version control system that tracks changes to files in a repository. For research projects, Git provides the backbone of a reproducible workflow because it records every change you make to your analysis files, along with who made the change and when.

Initial Repository Setup

Start by creating a repository for each research project. A repository is a folder that Git tracks. Inside that folder, you should maintain a consistent structure that separates raw data, processed data, analysis code, and outputs. A typical structure might include folders for raw data, scripts, results, figures, and manuscript files. The raw data folder should be treated as read-only after collection. Any transformation of raw data should occur through scripts that produce processed data files.

The Research Data Framework from the National Institute of Standards and Technology provides guidance on managing research data across its lifecycle. While the framework addresses data management broadly, its principles apply directly to organizing the files within a Git repository. The framework emphasizes planning for data management from the start of a project instead of treating it as an afterthought.

Tracking Changes and Committing

The basic Git workflow involves three steps. First, you modify files in your working directory. Second, you stage the changes you want to record. Third, you commit the staged changes, which creates a permanent snapshot in the repository history. Each commit should have a message that describes what changed and why. These messages become the narrative of your analysis process.

For research projects, commit early and often. Each commit represents a checkpoint. If you discover that a recent change introduced an error, you can revert to an earlier commit. If you need to reconstruct exactly how you produced a particular figure, you can examine the repository history.

Branching for Experiments

Git branches allow you to work on different versions of your analysis simultaneously. The main branch contains the stable version of your project. When you want to try a new analysis approach, you create a branch, make changes there, and merge the branch back into the main line if the approach works. This practice protects your main analysis from experimental changes that might break it.

For collaborative research, branches are essential. Each collaborator can work on their own branch and merge changes when ready. The distributed nature of Git means that collaborators do not need to be on the same network or use the same computer. The audit trail records who made each change, which is valuable for accountability and for resolving disputes about what was done.

Remote Repositories and Backup

A local Git repository on your computer is vulnerable to hardware failure, theft, or accidental deletion. Remote repositories hosted on services such as GitHub, GitLab, or institutional servers provide backup and enable collaboration. Push your commits to a remote repository regularly. For sensitive data, use institutional repositories that comply with data protection requirements instead of public services.

The FAIRification of research in real-world evidence emphasizes that version control and sharing of analytic code are not yet as established in some fields as in computational biology and health informatics. The tutorial provides detailed step-by-step instructions on how the Git version control system and R programming language can be implemented into study workflows to facilitate reproducible analyses. The same principles apply regardless of your programming language or research domain.

Preregistration in Life Sciences

Preregistration addresses a specific problem in scientific inference. When you analyze data without a pre-specified plan, you have many degrees of freedom in how you clean the data, which variables you include, which statistical tests you run, and how you interpret results. These choices can be influenced by what you hope to find. Preregistration commits you to your analysis plan before you see the results, which protects against this form of bias.

What to Preregister

A preregistration document should specify the study design, the primary and secondary hypotheses, the primary and secondary outcome measures, the sample size and how it was determined, the inclusion and exclusion criteria, and the analysis plan. For clinical trials, this information is typically submitted to a trial registry. For other study types, including in vitro research and observational studies, preregistration platforms accept similar information.

A call for preregistration of in vitro research argues that preregistration can serve as a tool to improve reproducibility and transparency in laboratory research. The argument extends the logic of clinical trial registration to the laboratory bench. If you plan to test a specific hypothesis about a cell line or an animal model, recording that hypothesis before you run the experiment prevents the temptation to reinterpret null results as support for a different hypothesis.

Tools for Study Design and Preregistration

The Experimental Design Assistant from the NC3Rs is a web-based tool that helps researchers design animal experiments. The tool guides you through the decisions that need to be made before an experiment begins, including randomization, blinding, and sample size calculation. Using such a tool before you start your experiment produces a design document that can serve as the basis for a preregistration.

The EQUATOR Network provides reporting guidelines for health research. These guidelines specify what information should be included in reports of different study types. While reporting guidelines apply to the publication stage, they are useful at the design stage because they tell you what information you will need to report. Designing your study with the reporting guideline in mind ensures that you collect the necessary information from the start.

Blinding and Its Role in Reproducibility

Blinding is a procedure that prevents researchers from knowing which treatment group a participant or sample belongs to. The rationale for blinding is that knowledge of treatment assignment can influence assessments of outcomes. A study on the quality of reports of randomized clinical trials found that blind assessments produced significantly lower and more consistent scores than open assessments. This finding has implications for systematic reviews, meta-analytic research, and the peer-review process.

For animal research, blinding means that the person assessing outcomes does not know which animals received which treatment. For in vitro research, blinding can mean that the person measuring outcomes does not know which samples came from which experimental condition. Blinding is a design feature that should be specified in the preregistration.

Preregistration and the Publication Process

Preregistration does not guarantee publication, and it does not prevent you from conducting exploratory analyses. It does provide a record that distinguishes confirmatory from exploratory findings. When you submit a manuscript, you can reference your preregistration to show that your primary analyses were specified in advance. Reviewers and readers can then evaluate whether the reported analyses match the pre-specified plan.

A study protocol for a randomized waitlist-controlled intervention study on music-based rehabilitation after stroke provides an example of how preregistration works in practice. The protocol specifies the background, the study design, the inclusion criteria, the intervention, and the outcome measures. The protocol was published before the study was completed, which means that the research community can compare the final report against the protocol.

Using Computational Notebooks for Reproducible Analysis

Computational notebooks have become a tool of choice for many applications because they combine detailed workflows with narrative text and visualization of results. For life-science researchers, notebooks offer a way to document analyses that is both readable and executable.

Notebook Structure and Best Practices

A notebook consists of cells that can contain code, markdown text, or rich output such as figures and tables. The markdown cells allow you to explain what you are doing and why. The code cells allow you to perform the analysis. The output cells show the results. This structure means that a notebook is a complete record of an analysis, from data loading through to final figures.

Ten simple rules for reproducible research in Jupyter notebooks provide guidance on how to set up and document reproducible data analyses or simulations. The rules address technical and non-technical barriers to reproducible computational studies. They cover questions such as what tools are available, how they can be used effectively, and what opportunities and challenges computational notebooks offer.

Managing Dependencies

A common failure in computational reproducibility is that code runs on the author's computer but fails on a reviewer's computer because the software versions differ. Dependency management tools address this problem by pinning the exact versions of all packages used in an analysis.

The renv package for R manages package dependencies by creating a project-specific library. When you share your project, the renv lock file specifies the exact versions of all packages. A tutorial on reproducible research in R covers managing R package dependencies with renv as one of three essential components, alongside version control and dynamic document creation.

For Python projects, the Davos package provides a lighter-weight solution. When used in combination with a notebook-based Python project, Davos provides a mechanism for specifying the correct versions of the project's dependencies directly within the code that requires them, and automatically installing them in an isolated environment when the code is run. Davos ensures that those packages and specific versions are used every time the notebook's code is executed. This enables researchers to share a complete reproducible copy of their code within a single Jupyter notebook file.

Notebooks for Education and Collaboration

Notebooks are also for individual research projects. They also support education and team collaboration. An image-analysis environment based on Jupyter notebooks supports the use of computational tools that facilitate reproducible research and support scientists with varying levels of software development skills. The environment enables flexible, well-documented, and reproducible workflows via literate programming. A large number of examples illustrating educational and research-oriented image analysis workflows are available for free download.

For collaborative projects, notebooks can be shared through online repositories. The integration of online data repositories, computational environments, and model Application Programming Interfaces supports open and reproducible environmental modeling. The same integration approach applies to life-science research, where data repositories, computational environments, and analysis tools need to work together.

Integrating Data Repositories and Metadata

Reproducibility requires that data be available, beyond analysis code. Data repositories provide a home for research data that ensures it remains accessible over time. Metadata standards ensure that the data can be understood by others.

Choosing a Data Repository

The choice of repository depends on your research domain, the type of data, and any legal or ethical constraints. For life-science research, the National Center for Biotechnology Information provides access to a range of databases for biomedical and genomic data. PubMed, part of the National Library of Medicine, provides access to the biomedical literature. These resources are essential for finding prior work and for depositing certain types of data.

For data that does not fit into domain-specific repositories, general-purpose repositories accept a wide range of data types. The Research Data Framework from the National Institute of Standards and Technology provides guidance on managing research data across its lifecycle. The framework addresses questions about data formats, documentation, storage, and sharing.

Metadata Standards

Metadata provide context and provenance to raw data and methods. A review of the role of metadata in reproducible computational research identifies metadata standards that support reproducibility across an analytic stack consisting of input data, tools, notebooks, pipelines, and publications. The review explores gaps and discovers component trends of embeddedness and methodology weight.

For life-science data, metadata standards vary by data type. Genomic data have their own standards. Imaging data have different standards. Clinical data have yet other standards. The key principle is that metadata should be sufficient for an independent researcher to understand what the data are, how they were collected, and how they were processed.

Data Versioning

Data files change over time. A raw data file might be corrected, or a processing script might produce updated output. Data versioning tracks these changes so that you can always identify which version of the data was used for a particular analysis.

The DGChain system proposes data control version for trustworthy reproducibility with blockchain. The title and publication metadata indicate that blockchain-based approaches are being explored for data versioning. For most research projects, however, Git-based versioning combined with a data repository provides sufficient tracking.

Practical Workflow: From Project Start to Publication

This section provides a step-by-step workflow that integrates the tools and practices described above. The workflow assumes a research project that involves both data collection and computational analysis.

Step 1: Plan the Study Design

Before collecting any data, use a study design tool to plan your experiment. For animal research, the Experimental Design Assistant from the NC3Rs guides you through the decisions that need to be made before an experiment begins. For clinical research, consult the EQUATOR Network for reporting guidelines that specify what information you will need to report.

Document your study design in a protocol that specifies the hypotheses, outcome measures, sample size, inclusion and exclusion criteria, and analysis plan. This protocol becomes the basis for your preregistration.

Step 2: Preregister the Study

Submit your protocol to a preregistration platform appropriate for your study type. The preregistration should be time-stamped and publicly accessible. If you are conducting a clinical trial, register it in a recognized trial registry. For other study types, use a general preregistration platform.

The preregistration creates a permanent record of your planned analyses. When you later report your results, you can reference this record to show which analyses were planned and which were exploratory.

Step 3: Set Up the Project Repository

Create a Git repository for the project. Set up a folder structure that separates raw data, processed data, analysis code, and outputs. Initialize the repository and make an initial commit that includes the study protocol and the preregistration document.

Configure the repository to exclude large data files if they will be stored elsewhere. Many research groups use Git for code and a separate data repository for large datasets. The Git repository tracks the code and documents, while the data repository stores the raw data.

Step 4: Collect and Document Data

During data collection, maintain detailed records of how the data were collected. This documentation becomes part of the metadata that will accompany the data when it is deposited in a repository. Record any deviations from the study protocol, because these deviations will need to be reported.

For computational data, such as simulation output, ensure that the code that generated the data is committed to the repository. The code should be versioned so that you can reconstruct exactly how any data file was produced.

Step 5: Perform the Analysis in a Notebook

Use a computational notebook for your analysis. The notebook should load the raw data, perform any necessary processing, and produce the results and figures. The narrative cells should explain each step.

Commit the notebook to the repository when it produces results that you want to keep. Each commit represents a version of the analysis. If you later change the analysis approach, the repository retains the earlier version.

Step 6: Manage Dependencies

Use a dependency management tool to pin the versions of all packages used in your analysis. For R, use renv. For Python, consider Davos or a virtual environment tool. The goal is to ensure that your analysis can be re-run on a different computer with the same software environment.

Document the software environment, including the operating system and the versions of all software packages. This documentation should be part of the repository.

Step 7: Deposit Data and Code

When the analysis is complete, deposit the raw data in an appropriate data repository. Include metadata that describes the data collection methods, the data format, and any processing that was applied. Deposit the analysis code, including the notebooks, in a code repository.

The integration of online data repositories, computational environments, and model Application Programming Interfaces supports open and reproducible research. For life-science research, this means ensuring that the data, the code, and the computational environment are all accessible.

Step 8: Write the Manuscript with Reference to the Reproducibility Record

When writing the manuscript, reference the preregistration, the data repository, and the code repository. The methods section should describe the analysis in sufficient detail that a reader could reproduce it. The reporting guidelines from the EQUATOR Network specify what information should be included.

The manuscript should distinguish confirmatory analyses, which were pre-specified in the preregistration, from exploratory analyses, which were not. This distinction helps readers interpret the strength of the evidence.

Records and Measurements for Reproducibility

Reproducibility depends on records. The following measurements and records should be maintained for every research project.

Commit History

The Git commit history is a record of every change to the analysis code and documents. Each commit should have a message that describes what changed and why. The commit history allows you to reconstruct the analysis process and to identify when specific decisions were made.

Preregistration Record

The preregistration record includes the study protocol, the time-stamp of registration, and any updates to the protocol. If the protocol was amended, the amendments should be documented with their rationale.

Data Documentation

Data documentation includes the metadata that describes the data collection methods, the data format, and any processing steps. This documentation should be sufficient for an independent researcher to understand the data without consulting the original researcher.

Software Environment Record

The software environment record includes the operating system, the versions of all software packages, and the configuration settings. This record enables the analysis to be re-run in an equivalent environment.

Analysis Output

The analysis output includes the results, figures, and tables produced by the analysis. These outputs should be reproducible from the raw data and the analysis code. If an output cannot be reproduced, the reason should be documented.

Common Failure Patterns in Reproducibility

Understanding common failure patterns helps you avoid them. The following patterns are frequently observed in research projects that fail reproducibility checks.

Missing or Incomplete Metadata

Data files without metadata are unusable by independent researchers. The data might be perfectly collected, but without documentation of the collection methods, the variable definitions, and the data format, the data cannot be interpreted. Metadata provide context and provenance to raw data and methods and are essential to both discovery and validation.

Unpinned Dependencies

Analysis code that runs on the author's computer but fails elsewhere is a common failure. The cause is usually that the software environment differs. Dependency management tools address this problem by pinning package versions. Without pinned dependencies, the analysis cannot be reliably reproduced.

Manual Data Processing Steps

If data processing involves manual steps, such as editing a spreadsheet by hand, those steps are not captured in the code. An independent researcher cannot reproduce manual steps unless they are documented in detail. The solution is to perform all data processing through scripts that are versioned in the repository.

Incomplete Preregistration

A preregistration that does not specify the analysis plan in sufficient detail does not serve its purpose. The preregistration should specify the statistical tests, the variables, and the criteria for interpreting results. If the preregistration is vague, it does not constrain the analysis choices.

Notebooks That Do Not Run

A notebook that produces results on the author's computer but fails on a reviewer's computer is not reproducible. The causes include unpinned dependencies, missing data files, and code that depends on the local file system. The solution is to test the notebook in a clean environment before sharing it.

Limitations and Boundaries of Reproducibility Practices

Reproducibility practices have limitations that researchers should understand. These limitations do not undermine the value of the practices, but they do affect what can be expected.

Reproducibility versus Replicability

Reproducibility means that the same analysis of the same data produces the same results. Replicability means that a new study with new data produces the same findings. Reproducibility practices address the first goal. They do not guarantee replicability, which depends on the validity of the underlying scientific hypothesis.

Data That Cannot Be Shared

Some data cannot be shared publicly due to privacy, confidentiality, or legal constraints. Clinical data, for example, often contain personal information that is protected by law. In these cases, the analysis code can be shared, and the data can be made available through controlled access mechanisms. The metadata should describe the data and the access procedure.

Computational Cost

Some analyses require substantial computational resources that are not available to all researchers. A simulation that requires a supercomputer cannot be re-run by a researcher with a laptop. In these cases, the analysis code and the results should be shared, and the computational environment should be documented.

The Time Cost of Reproducibility Practices

Implementing reproducibility practices requires time and effort. Setting up a Git repository, writing a preregistration, and documenting metadata all take time that could be spent on other activities. The investment pays off when the research is shared, reviewed, and built upon, but the immediate cost is real.

Quality Controls and Verification

Quality controls help ensure that your reproducibility practices are working. The following verification steps should be part of your workflow.

Test the Notebook in a Clean Environment

Before sharing a notebook, test it in a clean environment. Create a fresh virtual environment, install the pinned dependencies, and run the notebook from start to finish. If the notebook fails, fix the issues before sharing.

Verify the Commit History

Check that the commit history tells a coherent story. Each commit should have a clear message. The history should show the progression of the analysis from initial exploration to final results. If the history is confusing, consider reorganizing the commits.

Confirm the Preregistration Matches the Analysis

Compare the preregistration with the analysis that was actually performed. Any deviations should be documented. If the analysis deviates from the preregistration, the deviation should be reported in the manuscript.

Validate the Data Documentation

Ask an independent colleague to review the data documentation. Can they understand what the data are, how they were collected, and how they were processed? If not, the documentation needs to be improved.

Check the Reproducibility of Key Results

Attempt to reproduce the key results from the raw data and the analysis code. This check should be performed before submission, not after publication. If the key results cannot be reproduced, investigate the cause.

Professional Escalation Criteria

Some situations require escalation to a supervisor, a data manager, or an institutional research integrity office. The following criteria indicate when escalation is appropriate.

Suspected Data Fabrication or Falsification

If you suspect that data have been fabricated or falsified, escalate immediately. This is a serious breach of research integrity with severe consequences. Do not attempt to investigate on your own.

Irreconcilable Differences Between Preregistration and Analysis

If the analysis deviates from the preregistration in ways that cannot be justified, escalate to a supervisor or a research integrity officer. The deviation might indicate a misunderstanding of the preregistration requirements or a more serious problem.

Inability to Reproduce Published Results

If you are unable to reproduce results from your own published work, escalate to your supervisor. The cause might be a technical issue, such as a missing data file, or a more serious problem with the analysis.

Data Breach or Unauthorized Data Access

If data are accessed without authorization, escalate immediately. Data breaches have legal and ethical implications. Your institution will have procedures for responding to data breaches.

Requests for Data That Cannot Be Fulfilled

If a reviewer or another researcher requests data that you cannot provide, escalate to your supervisor. The request might be reasonable, and the inability to fulfill it might indicate a problem with your data management practices.

Frequently Asked Questions

What is the difference between reproducibility and replicability?

Reproducibility means that the same analysis of the same data produces the same results. Replicability means that a new study with new data produces the same findings. Reproducibility practices address the first goal. They ensure that your analysis can be re-run by an independent researcher. Replicability depends on the validity of the underlying scientific hypothesis, which reproducibility practices do not address.

Do I need to preregister every study?

Preregistration is most valuable for confirmatory research, where you are testing a specific hypothesis. For exploratory research, where you are searching for patterns without a pre-specified hypothesis, preregistration is less applicable. However, even exploratory research can benefit from preregistering the data collection plan and the general approach to analysis. A call for preregistration of in vitro research argues that preregistration can improve reproducibility and transparency in laboratory research.

What should I do if my analysis deviates from my preregistration?

Document the deviation and the rationale. The deviation should be reported in the manuscript. If the deviation is substantial, consider whether the analysis should be described as exploratory instead of confirmatory. The preregistration record remains valuable even when deviations occur, because it shows what was planned and what was actually done.

How do I choose between R and Python for reproducible research?

Both R and Python support reproducible research workflows. R has the renv package for dependency management and rmarkdown for dynamic document creation. Python has Jupyter notebooks and tools such as Davos for dependency management. The choice depends on your research domain, your existing skills, and the tools used in your field. The principles of version control, dependency management, and documentation apply regardless of the programming language.

What data should I deposit in a repository?

Deposit the raw data that underlie your reported results. If the raw data cannot be shared due to privacy or legal constraints, deposit the processed data and document the processing steps. The metadata should describe the data collection methods, the data format, and any processing that was applied. The goal is to make the data as accessible as possible while respecting ethical and legal constraints.

How much time does a reproducible workflow add to a project?

The time cost varies depending on the project and the researcher's experience. Setting up a Git repository and learning the basic commands takes a few hours. Writing a preregistration takes additional time. Maintaining the workflow throughout the project requires ongoing effort. The investment pays off when the research is shared, reviewed, and built upon. The cost of irreproducibility, estimated at billions of dollars per year, far exceeds the cost of implementing reproducibility practices.

Can I use computational notebooks for wet-lab experiments?

Computational notebooks are most directly applicable to the computational analysis of data. For wet-lab experiments, the notebook can document the analysis of the data generated by the experiment. The experimental procedures themselves should be documented in a laboratory notebook or an electronic laboratory notebook. The computational notebook and the laboratory notebook together provide a complete record of the research.

What should I do if a reviewer asks for my data and code?

Provide the data and code through the repositories where they are deposited. If the data cannot be shared publicly, explain the constraints and provide access through the appropriate controlled access mechanism. The reviewer's request is an opportunity to demonstrate the reproducibility of your work. If you cannot fulfill the request, escalate to your supervisor to determine the appropriate response.

Related Articles

References and Further Reading

This article is educational and does not replace institutional policy, professional advice, or applicable safety and regulatory requirements.