30 lines
1.8 KiB
Markdown
30 lines
1.8 KiB
Markdown
# Governance
|
|
|
|
Nic Weyand is the initial code maintainer. Maintainers review implementation,
|
|
dependency, format, provenance and source-license changes. There is no established
|
|
multi-party review board or centrally operated public dataset implied by this repo.
|
|
Maintainer additions and changes to this policy should be reviewed in public Git
|
|
history, with conflicts of interest disclosed.
|
|
|
|
Dataset publishers operate independently. Each publisher names its reviewers,
|
|
publishes its evidence and review policy, and distributes trusted signing keys
|
|
through a channel separate from the dataset. Consumers decide which publisher
|
|
identities they accept. Code-maintainer status does not grant authority to change
|
|
a consumer's accepted destinations or signing keys.
|
|
|
|
Policy, license, normalization, source-allowlist and signature changes receive
|
|
explicit maintainer review and complete acceptance checks. Additional independent
|
|
review is appropriate for trust-boundary changes when another qualified reviewer
|
|
is available. This is a governance expectation; the current software does not
|
|
enforce a multi-reviewer quorum or authenticate a free-text reviewer name.
|
|
|
|
Corrections and appeals must identify the exact assertion or review fingerprint
|
|
and supply contrary evidence. Retain the original claim and decision, append the
|
|
correction or revocation, and explain its scope. Urgent suspected malicious
|
|
destinations may be revoked pending investigation. A release signer must not hide
|
|
revocations by selecting an old generation.
|
|
|
|
No payment, source popularity or contributor reputation buys destination approval.
|
|
Repeated deceptive submissions can be rejected while their supporting incident
|
|
record remains available to affected publishers. Avoid public exposure of secrets
|
|
or personal information when documenting abuse; follow SECURITY.md.
|