| name | apsr-transparency-and-data-policy |
| description | Use when preparing the reproducibility / replication materials for an American Political Science Review (APSR) manuscript. APSR requires conditionally accepted authors to deposit a reproducibility package in the APSR Dataverse (Harvard Dataverse), which the editorial office verifies before publication. Covers quantitative and qualitative transparency and exemptions. Prepares the package; it does not waive requirements. |
Transparency & Data Policy (apsr-transparency-and-data-policy)
APSR does not just ask for data — it verifies that the deposited materials reproduce the
manuscript's tables and figures before publication. Build the package as you go so conditional
acceptance does not stall.
When to trigger
- Building the reproducibility/replication package
- A manuscript reached conditional acceptance and the editorial office requested materials
- Data cannot be fully shared (privacy, ethics, legal/provider restrictions) and you need the
exemption path
- A Replications and Reappraisals submission (materials expectations are central)
What APSR requires (verify current wording on the policy page)
- Deposit to the APSR Dataverse. Authors of conditionally accepted manuscripts submit a
reproducibility package to the APSR Dataverse on Harvard Dataverse — the journal's
dedicated repository with permanent identifiers and preservation. Not a personal website or generic
cloud link.
- Editorial verification. The office reviews the package to confirm it can reproduce the
manuscript's tables and figures and that the research process is documented well enough. Treat
this as a real check, not a formality.
- Quantitative materials. Data, code, and documentation sufficient to regenerate every reported
result. Master script + README + pinned versions + seeds.
- Qualitative materials. Share the materials and data used, alongside literature citations, in a
form that supports the claims (e.g., evidence tables, annotated sources), with access controls
where needed (QDR is an option for controlled access).
When data cannot be shared (exemption path)
- Explain why the relevant data are not available (ethical/privacy concerns or legal restrictions
by the data provider).
- Provide README instructions on exactly how others can obtain the data (access process,
application, provider contact).
- Where possible, provide synthetic data resembling the unavailable data so the code can be run.
Package skeleton (what the verifiers should find)
apsr-repro/
├── README.md # provenance, environment, run instructions, exhibit map
├── run_all.{R,do,sh} # one entry point → every table and figure
├── data/
│ ├── raw/ # as obtained (or access instructions if restricted)
│ └── constructed/ # built by scripts, never by hand
├── code/
│ ├── 01_build.* # raw → analysis data
│ ├── 02_analysis.* # estimates
│ └── 03_exhibits.* # writes output/Table1.tex, output/Figure2.pdf, ...
└── output/ # regenerated exhibits, named to match the manuscript
The README's exhibit map — "Table 1 ← code/03_exhibits.* lines …; runtime ~N minutes" — is what
lets the editorial office verify quickly instead of bouncing the package back.
Verification dry run (before conditional acceptance, not after)
- Clone the package to a fresh directory or machine — not your working tree.
- Run only what the README says. Any manual step you perform but did not write down is a defect.
- Diff every regenerated exhibit against the manuscript: numbers, rounding, N's, note text.
- Record total runtime in the README; flag any step needing > a few hours or special hardware.
- Have a coauthor or colleague repeat steps 1–3 cold. If they ask you a single question, the
answer belongs in the README.
Preregistration discipline (APSR-specific)
Preregistration and pre-analysis plans are encouraged, not required — but if you reference one:
- Share it anonymized (as an appendix or via an anonymized OSF view) so double-anonymous review
survives; a PAP with your name on it defeats the anonymization you did everywhere else.
- Mark registered vs. unregistered analyses clearly in the text — this is the stated
expectation, and it converts "exploratory" from a weakness into a labeled category.
- Keep a deviations note: every departure from the plan, with the reason, in the appendix.
Build-as-you-go checklist
Anti-patterns
- Treating the deposit as a post-publication afterthought (it gates publication)
- Depositing code that does not actually reproduce the printed tables/figures
- A personal URL instead of the APSR Dataverse
- Claiming data are restricted without giving an access path or synthetic substitute
- Undocumented, un-seeded, unpinned code that "works on my machine"
Output format
【Repository】APSR Dataverse (Harvard) — package staged? [Y/N]
【Reproduces tables/figures?】master script verified locally? [Y/N]
【Documentation】README + provenance + seeds + pinned versions? [Y/N]
【Restricted data?】exemption note + access path + synthetic data?
【Qualitative transparency】evidence/sources documented? [Y/N/NA]
【Next】apsr-review-process
Supplementary resources
