| 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
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
