技能 数据科学 JHR研究数据与复制政策

JHR研究数据与复制政策

v20260724
jhr-replication-and-data-policy
本指南为投稿至《人类资源杂志》(JHR)的作者提供详细的实证研究数据和代码包准备流程。它详细阐述了如何确保研究结果的可复现性、数据公开性,包括设置档案计划、处理数据权限(如受限数据),确保学术研究达到最高标准。
获取技能
72 次下载
概览

Replication & Data Policy (jhr-replication-and-data-policy)

When to trigger

  • The paper is being prepared for JHR submission or acceptance
  • You need the archive-plan footnote, Data Availability Statement, or waiver
  • Data are restricted, proprietary, administrative, or RCT-based

JHR policy core

JHR's data policy is unusually concrete: accepted papers must preserve data and post replication materials in a well-curated public repository where possible, with a public-domain CC0 1.0 Universal license. At submission, include an archive plan footnote with a persistent link if available, or request a waiver at initial submission.

Package contents

  • Data files that can legally be shared
  • Code and models needed to reproduce all tables and figures
  • Read-me file explaining the sequence
  • Data Availability Statement on the title page
  • Restricted-data access instructions or waiver justification
  • For RCTs: pre-analysis plan registration and deviations

Acceptance-stage replication gate

Do not wait until conditional acceptance to discover that the archive cannot be built. Run this gate before initial submission and again when the paper enters revision.

Gate Pass condition Blocker to surface early
Exhibit inventory Every main-text and appendix table/figure maps to one script and one input dataset Hand-built table, untracked spreadsheet edit, or private intermediate file
Data rights Each dataset is classified public, restricted, proprietary, confidential, or author-generated No redistribution right or unclear crosswalk ownership
Repository plan Public repository path, DOI plan, CC0 posture, and embargo/waiver status recorded Deposit location or license undecided
Code portability A clean clone runs from raw/public inputs or approved restricted mount points Absolute paths, local user directories, hidden credentials
Reviewer audit trail Read-me explains what a referee can reproduce now and what requires restricted access DAS promises more than the archive can deliver

Waiver logic

Request a waiver at initial submission when data cannot be publicly deposited. State how other researchers can obtain the data and commit to provide reasonable guidance.

Waiver evidence test

A waiver is not a reason to ship a thin package. Before asking for one, prepare evidence that the non-public data barrier is real and that the reproducibility route remains usable.

Question Strong answer Weak answer
Why can the data not be posted? Contract, statute, IRB term, license, or agency rule named in plain language "Confidential" without a source
How can another researcher apply? Agency/vendor/contact path, application steps, and expected constraints "Contact the authors" only
What can still be checked? Code, dictionary, synthetic data, logs, exhibit map, and public-source rebuild scripts PDF tables only
What does the DAS say? Same access route and limits as the footnote and read-me DAS, footnote, and read-me disagree

Restricted-data package

When the data cannot be public, still prepare:

  • synthetic or public-use data that exercises every script path when possible;
  • data dictionary with variable construction and source tables;
  • access instructions, application links, and approval constraints;
  • log showing which outputs require restricted data;
  • archive-plan footnote explaining the waiver and reproducibility route.

Deposit decisions by data source

Data source What can usually be deposited Waiver posture
Public-use surveys (CPS, ACS, NLSY, PSID extracts) Extraction code plus the analysis file, or code that rebuilds it from raw downloads Rarely needed; check redistribution terms of each survey
State administrative records (UI wages, K-12, Medicaid) Code, codebooks, aggregate exhibits; microdata stays with the agency Waiver expected; document the access route precisely
Own RCT microdata De-identified analysis files under CC0 where consent and IRB allow Partial waiver for identifying fields; PAP registration stated
Proprietary/commercial data Code, pseudo-data, purchase or license instructions Waiver with a named acquisition path
Linked or matched files Each source assessed separately; the crosswalk is often the binding constraint Mixed: deposit what is public, waiver the link keys

Repository choice and licensing details evolve — confirm against the journal's current author guidelines before depositing.

Exhibit-to-script map

The read-me should include a compact manifest. This is the fastest way to catch irreproducible tables before upload.

Exhibit Output file Producing script Data requirement Notes
Table 1 tables/table1_balance.tex 03_tables/table1_balance.do public-use extract Rebuilds from raw survey download
Figure 2 figures/event_study.pdf 04_figures/event_study.R restricted admin file Runs only on approved secure machine
Appendix Table A4 tables/a4_placebo.tex 05_appendix/placebo.py synthetic test + restricted file Synthetic version verifies code path

Use the actual filenames from the project. If an exhibit has no producing script, treat that as a package defect, not a documentation detail.

Worked waiver scenario: UI wage records

Illustrative case: earnings outcomes come from one state's unemployment-insurance wage records under a data-use agreement that bars any microdata release.

  1. Footnote at submission: names the agency, the agreement, and states that code, codebooks, and a synthetic test file will be archived under CC0.
  2. The read-me lists the application steps and typical approval constraints a replicator faces, and which exhibits need the restricted extract.
  3. Every script runs against the synthetic file end-to-end so reviewers can verify logic without the data.
  4. The Data Availability Statement mirrors the footnote — the two must not drift apart between submission and acceptance.

Read-me skeleton for the JHR archive

README
  1. Data sources & access (public files included; restricted: how to apply)
  2. Software & versions (Stata/R/Python; packages pinned)
  3. Run order: 00_master -> 01_clean -> 02_analysis -> 03_exhibits
  4. Runtime & hardware notes; random seeds fixed where used
  5. Exhibit map: each table/figure -> producing script -> data requirement
  6. License: CC0 1.0 Universal (data and code deposited)

Pre-acceptance dry run

  • Clone the package to a clean directory and run it without manual edits.
  • Confirm every main-text and appendix exhibit regenerates byte-stable or with documented stochastic variation.
  • Check that no intermediate file under a restrictive license leaks into the deposit.
  • Compare the archive footnote, Data Availability Statement, waiver request, read-me, and repository landing page for identical access claims.
  • Save the run log and unresolved exceptions in the project archive before acceptance, so the team can fix blockers before production deadlines.

Output format

[Data status] public / restricted / proprietary / confidential / mixed
[Archive plan footnote] ...
[DAS] ...
[Waiver needed] yes/no + reason
[Replication gate] exhibit map / data rights / repository plan / code portability / audit trail
[Restricted-data route] public deposit / partial waiver / full waiver + access path
[Dry-run result] clean / stochastic differences documented / blocked
[RCT PAP status] ...
[Next step] jhr-submission
信息
Category 数据科学
Name jhr-replication-and-data-policy
版本 v20260724
大小 7.75KB
更新时间 2026-07-28
语言