gcb-reporting-and-data-policy
GitHub用于准备全球变化生物学(GCB)稿件的数据可用性声明和数据/代码归档。GCB要求数据代码必须存入带DOI的公共仓库，不接受‘依请求提供’。本技能协助选择仓库、生成DOI及撰写合规声明。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill gcb-reporting-and-data-policy -g -y
SKILL.md
Frontmatter
{
"name": "gcb-reporting-and-data-policy",
"description": "Use when preparing the data availability statement and the data\/code archive for a Global Change Biology (GCB) manuscript. GCB requires data and code to be archived in a public repository with a persistent DOI as a condition of publication, and \"available on request\" is not accepted. Prepares the deposit; it does not waive requirements."
}
Reporting & Data Policy (gcb-reporting-and-data-policy)
GCB treats open data and code as a condition of publication, not a courtesy. Primary and secondary data supporting the results must be archived in a publicly accessible repository with a persistent identifier (DOI), code/software likewise (e.g., Zenodo), and the manuscript must carry a data availability statement. Crucially, "available on request" is not accepted. Build the deposit as you go. Confirm current wording on the policy page before submission.
When to trigger
- Writing the data availability statement
- Choosing repositories and minting DOIs for data and code
- Handling data that cannot be fully shared (sensitive species locations, third-party/licensed data)
- Final reporting checks before submission
What GCB requires (verify current wording)
- Archive data with a DOI. Deposit primary and secondary data in a public, DOI-minting repository (e.g., Dryad, Zenodo, PANGAEA) with metadata sufficient for a third party to interpret the data correctly — before acceptance/publication.
- Archive code with a DOI. Code, software, and documentation supporting the results go to an appropriate public repository (e.g., Zenodo via a GitHub release) with a persistent identifier.
- Data availability statement. State exactly where the data and code live and how to access them; "available on request" is not sufficient.
- Reviewer access. Make data accessible to peer reviewers on request during evaluation.
- Reporting completeness. Report sample sizes, replication, units, methods, and software versions well enough to reproduce every result.
When data cannot be fully shared
- Sensitive data (e.g., precise locations of threatened species, human-subjects or provider-licensed data): explain the restriction, give a clear access pathway (provider, application process), and share what can be shared (de-sensitized/aggregated layers) plus full code.
- Document why the restriction applies; do not use sensitivity as a blanket reason to skip deposit.
Build-as-you-go checklist
- Data archived in a DOI-minting public repository with interpretable metadata
- Code/software archived (Zenodo/GitHub release) with a DOI
- Data availability statement names repository + access (not "on request")
- Sample sizes, replication, units, software versions reported
- Sensitive data: restriction explained + access pathway + shareable subset
- Manuscript exhibit numbers match the archived outputs
Repository fit by data type
Different global-change data types land best in different DOI-minting archives. Treat this as a routing guide, then confirm the current accepted list against the journal's author guidelines.
| Data type | Typical archive | Note |
|---|---|---|
| Ecological tabular / experimental | Dryad | Curated, ecology-oriented |
| Code + figure pipeline | Zenodo via a GitHub release | Versioned, DOI per release |
| Oceanographic / Earth-system | PANGAEA | Geo/environmental specialist |
| Sequences | INSDC (GenBank/ENA) | Domain-mandated, then cite accession |
| Sensitive species locations | Restricted deposit + access pathway | Share de-sensitized layer + full code |
Worked micro-example (illustrative)
A remote-sensing carbon-flux paper archives three things, not one: the gap-filled flux table to a DOI-minting repository; the processing and modelling code to Zenodo via a tagged GitHub release; and the raw tower coordinates with a stated restriction because one site is on a protected reserve. The data availability statement names each DOI and the access route for the restricted coordinates. A weak version deposits only the figures' CSV and writes "code available on request" — which GCB does not accept. The DOIs here are illustrative placeholders; mint real ones before submission.
Compliance pushback patterns and the fix
- "Statement says available on request" → replace with named repository, DOI, and access route; GCB does not accept request-only.
- "Code not archived, only data" → deposit the analysis/modelling code so every figure reproduces.
- "Metadata insufficient" → add units, sampling design, and variable definitions a third party can read.
- "Sensitive locations withheld with no pathway" → explain the restriction, give the application route, and share an aggregated layer plus full code.
Anti-patterns
- "Data available on request" (explicitly rejected by GCB)
- A personal website or transient cloud link instead of a DOI-minting repository
- Archiving data but not the code that produced the figures
- Metadata too thin for a third party to interpret the data
- Treating deposit as a post-acceptance afterthought
Output format
【Data archived】DOI-minting repo + metadata? [Y/N]
【Code archived】Zenodo/release with DOI? [Y/N]
【Availability statement】names repo + access (not "on request")? [Y/N]
【Sensitive data】restriction explained + access path + shareable subset?
【Reproducible reporting】n, units, versions complete? [Y/N]
【Next】gcb-writing-style
Supplementary resources
../../resources/external_tools.md— repositories (Dryad/Zenodo/PANGAEA) and reproducibility tooling../../resources/official-source-map.md— GCB data- and code-archiving policy
Version History
- 1839142 Current 2026-07-05 13:16
