Intellectual Frontiers

Use case

A research group can answer reviewers by pointing to code that runs

A research team can publish a companion repository with its paper. When a reviewer asks how a number was produced, the answer is a release that reruns it. The team gets a citable software record, a precise history of every analysis decision, and a way to update the method as new data arrives.

The repository records every analysis decision where it ran

Claim: hypothesis

Teams lose weeks to review rounds about methods, and years later can't always say themselves why an exclusion rule or a threshold was chosen. A companion repository records those decisions where the code ran. The templates and checklists are plain: the existing standards CodeMeta, CITATION.cff and RO-Crate, a README, and the author checklist in the program's companion.

What would show this claim is wrong

  • Reviewers ask the same number of methods questions of papers with a companion repository as of papers without one.

Teams build the repository as the analysis grows

Claim: hypothesis

A team could build the habit into its workflow, so the companion repository grows with the analysis rather than being cleaned up at the end. A university research office or a core facility could offer help with the first one, paid from overhead, since program research suggests the first is the most work. Shared pipelines can then be reused across the group's later papers.

What would show this claim is wrong

  • The time to make the repository doesn't drop after the first paper, so it's a standing cost per paper that teams won't carry.

Your next paper gets the seven steps and a colleague's rerun

Claim: hypothesis

On your next paper, follow the seven steps before you submit, and log the hours each takes. Ask a colleague outside the project to rerun one result from the instructions alone.

What would show this claim is wrong

  • The colleague can't rerun the result from the instructions, even with all seven steps done.

Related

Next