Dataset Publication Policy: named maintainer, terms of reference, end-of-life/succession (journal phase 1) #84

Phase 1 of the journal strategy (#91). One public policy document plus small mechanical changes. Build this regardless of whether the journal ever launches — it closes gaps visible from the outside today: no maintenance policy anywhere on the site/guide/repos, maintainers tracked internally but not displayed (contact is a generic ghe@mavt.ethz.ch), no terms of use or contributor agreement, no stated versioning policy, 10 of 50 published packages without DOIs.

Why the CRAN model alone is insufficient

CRAN's "one maintainer, one email" contract is the right floor, but washr's own history shows its failure mode: the v1.0.2 release was gated on CRAN mail going to a departed maintainer's dead mailbox (premortem R2, issue openwashdata/washr#61). WASH practitioners and NGO staff churn faster than academics. The evidence base (dev/journal-2026-07/research-submission-governance.md on main) points to combining:

• CRAN: single named maintainer with monitored email; response deadlines; bouncing address is grounds for the end-of-life clock; archival not deletion; orphaned-package handling; maintainer change needs the outgoing maintainer's agreement or a formal orphaning.
• Bioconductor: staged one-year end-of-life for unresponsive maintainers (automated outreach → private email → deprecation warning → archival).
• rOpenSci: documented maintainer-handover chapter, co-maintainership encouraged, public "call for new maintainer" before archiving, dignified archive org as end state.
• DataCite schema 4.5: the maintainer is encoded as contributorType ContactPerson ("person with knowledge of how to access, troubleshoot, or otherwise field issues related to the resource") — and contacts can be organizational, which is the schema-native institutional fallback.

Policy contents (one page-scale document, versioned in a public repo)

• Maintainer: every dataset names one maintainer with a monitored email (DESCRIPTION cre, surfaced as DataCite ContactPerson), plus a required institutional fallback contact; openwashdata is maintainer of last resort.
• Obligations: respond to data issues within a stated window (e.g. 4 weeks); keep contact details current; a bouncing address starts the end-of-life clock.
• End-of-life/succession: staged outreach → public call for a new maintainer → archival with DOI and record kept citable. Archive, never delete.
• Floor requirements: CC BY 4.0 (or justified exception), complete dictionary, passing R CMD check (Check script crashes on data with invalid UTF-8 strings #86 makes this true by construction), DOI minted before "published" status, PII screening attestation (pkgreview's PII chapter).
• Versioning: semantic dataset versioning; Zenodo versioned DOIs; what constitutes a new version vs a new dataset.
• Responsibility split (currently absent entirely): what the maintainer warrants (provenance, consent/PII, license authority) vs what openwashdata provides (hosting, tooling, review, archival). This is the clause that protects both sides.

Mechanical changes (mostly cross-repo; tracked here for coherence)

• Surface maintainer + DOI in the public catalogue table (openwashdata/website — the columns already exist in the sheet snapshot, they are just not displayed)
• Mint the 10 missing DOIs for published packages
• Intake issue template on openwashdata/data gains the policy checklist (maintainer, fallback contact, license authority, PII attestation)
• check_publication_readiness() (Fix the main-branch tag check after a release merge #82) becomes the automated submission gate; policy floor items map one-to-one to its checks
• washr: maintainer/ContactPerson mapping folded into the Metadata design decision: canonical sources and field mappings (resolves #47) washr#67 field-mapping decision so DESCRIPTION cre flows to CITATION.cff, JSON-LD, and the future Zenodo record (washr 1.1.0: API changes to reconcile in the skills and the standard before the release lands #56)

Scope fence

Out of scope: journal name, ISSN, review process changes (phase 2, see openwashdata/washr#91), anything requiring new external services. The washr v1.0.2/v1.1.0 engineering plan is already full; this phase consumes policy-writing bandwidth.

Kill criterion (#91): policy not agreed within 6 weeks of starting → cut to maintainer + end-of-life clauses only, ship, iterate the rest.