Formalize the public contribution surface. Maintainers keep a separate internal process and are exempt from the intake gates; everyone stays bound by review, CODEOWNERS, and branch protection. Model: - Issues = problem reports only (bug form + config.yml redirects ideas to Discussions and disables blank issues). - Discussions = ideas + RFC incubation. - RFCs = anyone (incl. external) authors docs/rfcs/NNNN-*.md; a maintainer merging it is acceptance. Distinct from the maintainer-internal docs/dev/rfc-00N-* track. - PRs = link an `accepted` issue or accepted RFC, or use the trivial fast-lane (typos/docs/deps). Enforced softly to start (template + review). Adds GOVERNANCE.md, rewrites CONTRIBUTING.md, adds docs/rfcs/ (README + template), .github issue/PR/discussion templates. Wires docs/rfcs/ into the doc-link checker (excluded like releases; linked from docs/dev/index.md). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 0000-template.md | ||
| README.md | ||
RFCs
Substantial changes to OmniGraph — new user-facing surface, format or protocol changes, anything irreversible or cross-cutting — go through a lightweight RFC so the design is agreed as reviewable code before implementation starts. This is the public RFC track, open to anyone, including external contributors.
This complements the always-on review bar in ../dev/invariants.md: the invariants say what every change must respect; an RFC says why this particular change is worth making and how.
Two tracks, don't conflate them. This
docs/rfcs/directory is the public contribution track (anyone authors; maintainers accept). The maintainer-internal RFCs underdocs/dev/rfc-00N-*.mdare a separate, team-owned track for in-flight internal work. If you're an outside contributor, you're in the right place here.
When you need one
- RFC required: new query/schema/CLI/HTTP surface; on-disk or wire-format changes; a new substrate dependency; anything the deny-list in ../dev/invariants.md flags; anything irreversible ("reversibility shapes evidence demand").
- RFC not required: bug fixes for an
acceptedissue, and the trivial fast-lane (typos, docs, deps) — see ../../CONTRIBUTING.md.
If you're unsure, start a Discussion; a maintainer will tell you whether it needs an RFC.
Lifecycle
Discussion (incubate, get rough consensus)
│ graduate
▼
RFC pull request → adds docs/rfcs/NNNN-title.md (Status: Proposed)
│
maintainer review ──▶ changes requested / declined (PR closed, with rationale)
│
▼
merged == Accepted (the merged file is the durable decision record)
│
▼
Implementation PR(s) reference the accepted RFC
- Author: anyone. Acceptance: a maintainer decision, performed by merging the RFC PR. Declining is closing it with rationale.
- The merged RFC is the accepted record — there is no separate sign-off step.
- Later reversals don't edit history: supersede with a new RFC that links back
and flip the old one's
StatustoSuperseded.
Numbering & naming
- File:
docs/rfcs/NNNN-kebab-title.md, whereNNNNis the next free zero-padded integer (0001,0002, …).0000-template.mdis reserved. - Pick the number when you open the PR; if it collides with another in-flight RFC, the second to merge bumps theirs.
Status values
Proposed (open PR) · Accepted (merged) · Declined (closed) ·
Superseded by NNNN · Implemented (set once the work lands, optional).
Copy 0000-template.md to start.