gcb-reporting-and-data-policy

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)

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

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

1. Data availability statement. State exactly where the data and code live and how to access them;

"available on request" is not sufficient.

1. Reviewer access. Make data accessible to peer reviewers on request during evaluation.
2. 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](../../resources/external_tools.md) — repositories (Dryad/Zenodo/PANGAEA) and reproducibility tooling
• [../../resources/official-source-map.md](../../resources/official-source-map.md) — GCB data- and code-archiving policy