SMR Software and Reproducibility
Use this to meet SMR's defining expectation: a methods paper should ship a method other people can
run. SMR readers adopt methods, so released, documented software and a reproducible pipeline are
not optional extras — a beautiful estimator with no usable code is a method no one will use, and
reviewers know it.
What "released software" means at SMR
- A package or well-structured code implementing the method in a mainstream environment (R, Stata,
Python — whatever the audience uses), with a documented interface, not a private analysis script.
- Worked usage: a minimal example that runs the method on toy or example data, so a reader can
confirm it works before adapting it.
- Versioned and citable: deposit in a trusted public repository (e.g., a tagged release with a DOI)
rather than a personal homepage that can disappear.
The reproducibility pipeline
Every exhibit in the paper must be regenerable:
- A README stating software versions, dependencies, expected runtime, and the entry-point command.
- A master script that runs the full pipeline: simulation grid → tables → figures → illustration,
with seeds fixed so Monte Carlo results reproduce exactly.
- One command per exhibit mapping (or a clear table) so a replicator knows which script produces
Table 2, Figure 3, etc.
- For long simulations, provide a smoke-test mode (few replications) that runs quickly and a
full-run mode that reproduces the paper.
The SMR availability statement
SMR requires a data-and-code availability statement (检索于 2026-06;以官网为准):
- Disclose how the study data, code, and materials can be permanently accessed — repository name,
DOI/URL, and any access conditions.
- Code and materials are expected; data should be deposited where possible, and restricted data
must state the reason and the access path/conditions in the statement.
- Use a trusted public repository; reference datasets in DataCite style.
- Write the statement at submission, not at acceptance — it is part of the manuscript's conformance.
Anonymization of the package under double-anonymized review
- The released materials submitted for review must not deanonymize: strip author names, institutional
paths, and account handles from code, README, and repository metadata.
- Use an anonymized repository (e.g., a blinded archive) for the review copy; reveal the public,
citable version at acceptance.
Checklist
Anti-patterns
- Private analysis script as "software": code that only the authors can run.
- Unseeded simulation: Monte Carlo results that cannot be reproduced.
- Disappearing host: code on a personal homepage with no archive/DOI.
- Missing exhibit map: a replicator cannot tell which script makes which table.
- Availability statement deferred to acceptance, or vague ("available on request").
- Deanonymizing repo metadata in the review copy.
Output format
[Reproducibility status] release-ready / needs work / not ready
[Software] package/structured code? usage example? citable deposit?
[Pipeline] master script + seeds + exhibit map present? smoke-test mode?
[Availability statement] written? repository/DOI + access conditions stated?
[Anonymization] review-copy materials clean? yes/no
[Next SMR skill] smr-submission
Source: brycewang-stanford/Awesome-Journal-Skills → Sociological-Methods-and-Research-Skills/skills/smr-software-and-reproducibility/SKILL.md
1---2name: smr-software-and-reproducibility3description: Use when preparing the released software, code, data, and reproducibility materials for a Sociological Methods & Research (SMR) paper — a usable package plus scripts that recreate every table, figure, and simulation, and the SMR data-and-code availability statement. Builds the reproducibility layer; does not write the manuscript.4---5
6
7# SMR Software and Reproducibility
8
9Use this to meet SMR's defining expectation: a methods paper should ship a **method other people can
10run**. SMR readers adopt methods, so released, documented software and a reproducible pipeline are
11not optional extras — a beautiful estimator with no usable code is a method no one will use, and
12reviewers know it.
13
14## What "released software" means at SMR
15
16- A **package or well-structured code** implementing the method in a mainstream environment (R, Stata,
17 Python — whatever the audience uses), with a documented interface, not a private analysis script.
18- **Worked usage**: a minimal example that runs the method on toy or example data, so a reader can
19 confirm it works before adapting it.
20- **Versioned and citable**: deposit in a trusted public repository (e.g., a tagged release with a DOI)
21 rather than a personal homepage that can disappear.
22
23## The reproducibility pipeline
24
25Every exhibit in the paper must be regenerable:
26
27- A **README** stating software versions, dependencies, expected runtime, and the entry-point command.
28- A **master script** that runs the full pipeline: simulation grid → tables → figures → illustration,
29 with **seeds fixed** so Monte Carlo results reproduce exactly.
30- **One command per exhibit** mapping (or a clear table) so a replicator knows which script produces
31 Table 2, Figure 3, etc.
32- For long simulations, provide a **smoke-test mode** (few replications) that runs quickly and a
33 full-run mode that reproduces the paper.
34
35## The SMR availability statement
36
37SMR requires a **data-and-code availability statement** (检索于 2026-06;以官网为准):
38
39- Disclose **how the study data, code, and materials can be permanently accessed** — repository name,
40 DOI/URL, and any access conditions.
41- **Code and materials** are expected; **data** should be deposited where possible, and restricted data
42 must state the reason and the access path/conditions in the statement.
43- Use a **trusted public repository**; reference datasets in **DataCite** style.
44- Write the statement at submission, not at acceptance — it is part of the manuscript's conformance.
45
46## Anonymization of the package under double-anonymized review
47
48- The released materials submitted for review must not deanonymize: strip author names, institutional
49 paths, and account handles from code, README, and repository metadata.
50- Use an **anonymized repository** (e.g., a blinded archive) for the review copy; reveal the public,
51 citable version at acceptance.
52
53## Checklist
54
55- [ ] The method is released as a usable package/structured code, not a private script.
56- [ ] A minimal runnable usage example is included.
57- [ ] The code is versioned and deposited in a trusted, citable public repository.
58- [ ] A README states versions, dependencies, runtime, and the entry command.
59- [ ] A master script reproduces every table, figure, and the simulation, with seeds fixed.
60- [ ] An exhibit→script map lets a replicator find each result.
61- [ ] A smoke-test mode exists for long simulations.
62- [ ] The data-and-code availability statement is written, with repository/DOI and any access conditions.
63- [ ] The review-copy materials are anonymized.
64
65## Anti-patterns
66
67- **Private analysis script as "software"**: code that only the authors can run.
68- **Unseeded simulation**: Monte Carlo results that cannot be reproduced.
69- **Disappearing host**: code on a personal homepage with no archive/DOI.
70- **Missing exhibit map**: a replicator cannot tell which script makes which table.
71- **Availability statement deferred** to acceptance, or vague ("available on request").
72- **Deanonymizing repo metadata** in the review copy.
73
74## Output format
75
76```text
77[Reproducibility status] release-ready / needs work / not ready
78[Software] package/structured code? usage example? citable deposit?
79[Pipeline] master script + seeds + exhibit map present? smoke-test mode?
80[Availability statement] written? repository/DOI + access conditions stated?
81[Anonymization] review-copy materials clean? yes/no
82[Next SMR skill] smr-submission
83```
84
85---
86
87**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `Sociological-Methods-and-Research-Skills/skills/smr-software-and-reproducibility/SKILL.md`