13 Reproducible Science, Open Science, and Version Control
Reproducibility is one of our core values and a competitive advantage. It is also how we train independent scientists: a reproducible workflow is a teachable workflow. This chapter sets the standard.
13.1 The standard
If it isn’t reproducible, it isn’t finished. Anyone in the group should be able to clone a project, restore the environment, and regenerate every figure, table, and number in a manuscript from raw inputs.
13.2 Version control with Git and GitHub
All code lives in Git, hosted on GitHub under the RIPLRT organization. No exceptions, no “I’ll add it later,” no analysis living only on a laptop.
Workflow basics:
- Work on branches, not directly on
main. - Commit early and often with clear messages (
fix: correct lag window in DLM, notstuff). - Open pull requests for review; analysis code gets a second set of eyes before it shapes a result.
- Use issues to track bugs, questions, and tasks.
- Never commit data, credentials, or secrets — enforce with
.gitignore.
Use the GitHub Repository Checklist when setting up any new project.
Before making any repository, dataset, or notebook public, confirm with the PI or project lead. Public release must respect DUAs, IRB terms, embargoes, and authorship plans (this rule is inherited from the original manual and still applies).
13.3 Reproducible analysis with Quarto
We author analysis and manuscripts in Quarto (modernizing the group’s earlier R Markdown / Bookdown practice) unless otherwise stated. Quarto lets prose, code, and output live together and render to HTML, PDF, and Word.
Standards:
- Analyses are literate: code, narrative, and results in one document.
- Computational environments are captured — use
renv(R) or a lockfile /requirements.txt/environment.yml(Python) so versions are pinned. - Set a random seed for any stochastic step.
- Documents render cleanly from scratch (use Quarto’s
freezethoughtfully, but verify a clean render before milestones). - Paths are relative, never absolute (
data/not/Users/you/Desktop/...).
Run the Reproducible Analysis Checklist before any submission.
13.4 Project repository structure
A consistent skeleton makes every project legible:
project-name/
├── README.md # what this is, how to run it
├── data/ # raw/ (gitignored), interim/, processed/
├── R/ or src/ # functions and scripts
├── analysis/ # numbered Quarto notebooks
├── outputs/ # figures/, tables/, dashboards/
├── docs/ # manuscripts, briefs
├── renv.lock / env.yml # pinned environment
└── .gitignore # excludes data, secrets, large files
- Raw data is read-only and never edited by hand — all cleaning is scripted, so it’s reproducible and auditable.
- Number notebooks (
01-clean.qmd,02-model.qmd) so the pipeline order is obvious. - When a project uses physical samples, keep sample provenance and location in Aliquary (Section 17.5) so inventory history can be traced alongside the analysis pipeline.
13.5 Open science
We contribute to open science deliberately, within what agreements allow:
- Preregister analysis plans on OSF where appropriate — especially for forecasting work, to separate confirmatory from exploratory analysis.
- Archive curated code and (permissible) data with DOIs via Zenodo or FigShare.
- Share reproducible notebooks and manuscripts open-access where possible.
- Re-analyzing public datasets is good open science, not plagiarism — it advances reproducibility.
Our bias is toward openness and transparency. But openness never overrides a data-use agreement, IRB term, participant privacy, or an embargo. When the two seem to conflict, governance wins and you ask the PI.
13.6 Reproducibility as mentoring
Building a reproducible pipeline is one of the most valuable things a mentee learns here. It is also a deliverable in its own right: a clean, documented, reproducible notebook is a legitimate scholarly product and a strong portfolio piece. We credit reproducibility work like the real work it is (Chapter 15).