pubar-transparency-and-data
GitHub用于准备公共行政审查(PAR)稿件的透明度和可重复性材料。遵循COS TOP指南,涵盖数据共享、引用、报告文档及预注册。提供按证据类型构建材料的清单和路径,确保符合期刊标准。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill pubar-transparency-and-data -g -y
SKILL.md
Frontmatter
{
"name": "pubar-transparency-and-data",
"description": "Use when preparing the transparency \/ reproducibility materials for a Public Administration Review (PAR) manuscript. PAR is a signatory of the Center for Open Science TOP Guidelines and has adopted transparency standards (data citation, data sharing via Dataverse\/QDR, reporting documentation, pre-registration). Covers quantitative and qualitative transparency and the restricted-data path. Prepares the package; it does not waive requirements."
}
Transparency & Data Policy (pubar-transparency-and-data)
PAR endorses the Center for Open Science's Transparency and Openness Promotion (TOP) Guidelines and has adopted transparency standards for authors (检索于 2026-06;以官网为准). Build the materials as you go so a transparency request at review or acceptance does not stall the paper.
When to trigger
- Building the reproducibility / transparency materials and the data-availability statement
- A reviewer or editor requested data, code, or documentation
- Data cannot be fully shared (privacy, FOIA limits, agency restrictions, IRB) and you need the path
- Deciding whether to pursue pre-registration badges
What PAR's TOP standards cover (verify current wording)
- Data & materials citation. Cite all research materials and data sources used, with persistent identifiers where available — treat data as a citable research output.
- Data sharing. PAR encourages depositing data in an appropriate repository — Dataverse for quantitative data, the Qualitative Data Repository (QDR) for qualitative data — with a data-availability statement in the manuscript.
- Reporting documentation. PAR recommends documenting research design, data preparation, and analysis decisions in a supplementary document, following the relevant reporting standard where applicable (e.g., CONSORT for experiments, STROBE for observational, PRISMA for reviews, COREQ for qualitative).
- Pre-registration. Pre-registration of studies and/or analysis plans is supported, and
badges may be available — register before data collection/analysis (see
pubar-research-design).
Build-as-you-go checklist
- One master script regenerates every table and figure from raw/constructed data
- README documents data provenance, construction steps, and how to reproduce each exhibit
- Seeds set and reported for every stochastic step
- Software/package versions pinned (
renv.lock/requirements.txt/ recorded installs) - Exhibit numbers in the manuscript match the deposited output exactly
- Data-availability statement drafted (where data live, or why they cannot be shared)
- Reporting-standard supplement (CONSORT/STROBE/PRISMA/COREQ) where applicable
- Pre-registration / pre-analysis plan linked (anonymized) where applicable
Transparency package by evidence type
Build the package around the evidence product, not around a generic folder dump.
| Evidence type | Minimum package | PAR-specific risk |
|---|---|---|
| Administrative microdata | Data dictionary, construction log, access conditions, replication code, and an approved restricted-data statement if raw data cannot ship | A practitioner-facing claim with no auditable data provenance |
| Survey / experiment | Instrument, sampling frame, recruitment/consent language, randomization code, preregistration or exploratory label, and cleaning scripts | Treatments or outcomes cannot be interpreted by public managers |
| Qualitative interviews / fieldwork | Interview protocol, coding scheme, memo trail, anonymized excerpts or controlled-access deposit, and IRB/consent constraints | Over-disclosure that harms participants, or under-documentation that blocks audit |
| Case comparison / process tracing | Case-selection memo, source inventory, evidence tests, chronology, and rival-explanation log | "Illustrative" cases presented as field-wide lessons |
| Public datasets / dashboards | Persistent links, download dates, version snapshots, transformation scripts, and archived outputs | Live web data change after review and no longer reproduce the exhibits |
Restricted-data decision tree
- Can raw data be public? Deposit the exact analysis data plus code in Dataverse or another persistent repository and cite it in the Data Availability Statement.
- Can de-identified analysis data be public? Deposit the de-identified data and document what was removed, masked, top-coded, aggregated, or perturbed.
- Can synthetic or toy data run the code? Provide synthetic data plus a validation note that the code path reproduces the tables/figures but not the confidential estimates.
- Can only metadata be shared? Provide a data-access route, DUA/IRB constraints, variable list, and a read-only replication log that maps each exhibit to the restricted source.
- Is nothing shareable? Treat this as an editor-facing exception request; explain why the claim is still auditable and which independent checks remain possible.
For every restricted path, separate legal/ethical inability from convenience. Convenience is not a transparency rationale.
When data cannot be shared (restricted-data path)
- Explain why the data are restricted (privacy, IRB, agency/legal restrictions, FOIA limits).
- Provide instructions on how others can obtain the data (access process, agency contact, DUA).
- Where feasible, provide synthetic data or de-identified extracts so the code can be run.
- For qualitative data, QDR supports controlled-access sharing with appropriate protections.
Reproducibility smoke test
Before submission, run a clean-room check:
- start from a fresh directory or container with only the repository/deposit files;
- install from the recorded environment file;
- run the master script end to end;
- compare every printed table/figure number against the manuscript;
- record any manual step, proprietary software dependency, or restricted-data substitution.
If the smoke test fails, do not call the package "reproducible"; report the remaining limitation honestly in the Data Availability Statement.
Anti-patterns
- Treating transparency as a post-acceptance afterthought
- Depositing code that does not actually reproduce the printed tables/figures
- A personal URL or dead link instead of a persistent repository (Dataverse/QDR)
- Claiming data are restricted with no access path or synthetic substitute
- Undocumented, un-seeded, unpinned code that "works on my machine"
Output format
【Repository】Dataverse (quant) / QDR (qual) — materials staged? [Y/N]
【Evidence type】admin / survey-experiment / qualitative / case-process / public-dataset
【Reproduces tables/figures?】master script verified locally? [Y/N]
【Documentation】README + provenance + seeds + pinned versions + reporting standard? [Y/N]
【Data-availability statement】drafted? [Y/N]
【Restricted data?】public / de-identified / synthetic / metadata-only / exception request
【Smoke test】fresh-run status + remaining manual step
【Pre-registration】badge pursued? [Y/N/NA]
【Next】pubar-review-process
Supplementary resources
../../resources/external_tools.md— reproducibility tooling and qualitative-transparency options (QDR)../../resources/official-source-map.md— PAR TOP guidelines + Dataverse/QDR
Version History
- 1839142 Current 2026-07-05 14:16


