Define the result that should be reproduced
“Reproduce the whole thesis” is usually too vague to test. List the central tables, figures and statistics that the package is intended to create. Assign result IDs and map them to chapters. State whether the workflow begins with raw data, an authorised derived dataset or a small technical example. Put these boundaries near the top of the README.
Keep reproduction distinct from replication. This package should first show that the declared process applied to the same permitted inputs produces the documented outputs. A new sample and independent replication answer another scientific question. Claim only the level that the clean test has demonstrated.
Let the folder layout express the data journey
Keep the top level small: README, licensing and citation information, environment specification, and directories for data, code, output and supporting documentation. Analysis must never overwrite source data. Derived data should be rebuildable from the permitted input. The generated-output folder begins empty, or reference outputs are stored in a clearly separate location.
Use relative paths so the package is not tied to a user name or desktop. Filenames can communicate execution order, such as 01_import, 02_clean and 03_models. Exclude caches, temporary files, operating-system debris and credentials. A manifest lists every included file, its purpose and, for important inputs, a checksum.
Write a README for someone outside the project
Open with purpose, coverage and expected result IDs. Name prerequisites, tested software versions and installation steps. Give one launch command or a numbered graphical sequence. Mention runtime only when measured and qualify hardware dependence. Explain where logs and generated files will appear and what a successful run looks like.
Add a data inventory containing file, provenance, version, licence or access condition, protection class and producing step. Explain abbreviations, units and missing-value codes. Document expected warnings and accepted numerical tolerances. Conclude with creators, preferred citation, licensing, contact details and a concise change history.
Openness stops where rights and duties require it
Check version history, metadata, logs and intermediate outputs as well as visible folders for personal or confidential information. Credentials, tokens and live local configuration never belong in the release. If source data cannot be distributed, the README should provide a precise description and access conditions. A small synthetic dataset can test the technical pathway without pretending to reproduce the confidential study result.
Separate licences for software, data and written documentation. Obtain third-party packages through declared dependencies rather than copying them without review. Cite external code and data. Check consent, ethics conditions, contracts and repository terms. For sensitive material, use the anonymisation and residual-risk workflow before release.
Run the package in a clean environment
Unpack the fixed release into an empty directory or new virtual environment. Follow only the README, without relying on knowledge from the development computer. Test installation, paths and the single entry point. The run should write to output/generated without replacing reference files. Compare result IDs, case counts, tables and checksums or documented numerical tolerances.
Ask another person to repeat the process and capture every question. Correct the instructions or structure, fix a new version and test again. Record date, platform, outcome and residual differences. Do not silently edit the tested release afterwards; corrections receive a new version and concise change note.
Connect submission, preservation and citation
Create an archive and manifest for the tested state. Deposit it in the permitted institutional or research repository and describe access restrictions accurately. Point the thesis to the precise version rather than a moving shared folder. For Git-based work, the guide to releases, commits and archive DOIs helps select the citation target.
Finally, verify that result IDs in the thesis match the package and public links work for a signed-out visitor where access is meant to be open. Back up the submitted release independently. A collection of files is not a reproducibility package merely because it runs on its creator's laptop; an independent reader must understand its scope, protection boundary and execution.
Maintain the release without rewriting history
A thesis package can reveal a typo or code defect after submission. Preserve the deposited state, record the problem and issue a corrected version where policy permits. Explain whether reported conclusions changed. A new DOI version, release note or erratum can keep the trail clear. Never replace an archived package in a way that makes the cited evidence silently different.