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.
Installs into .claude/skills of the current project.
Are you the author of Gcb Reporting And Data Policy?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-gcb-reporting-and-data-policy)
---
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."
category: backend-and-data
source_repo: brycewang-stanford/Awesome-Journal-Skills
source_path: "Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md"
source_url: https://github.com/brycewang-stanford/Awesome-Journal-Skills/blob/HEAD/Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md
---
# 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.
2. **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.
3. **Data availability statement.** State exactly where the data and code live and how to access them;
**"available on request" is not sufficient**.
4. **Reviewer access.** Make data accessible to peer reviewers on request during evaluation.
5. **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
---
**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `Global-Change-Biology-Skills/skills/gcb-reporting-and-data-policy/SKILL.md`