mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-09 01:35:18 +02:00
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>
54 lines
1.7 KiB
Markdown
54 lines
1.7 KiB
Markdown
# RFC NNNN: <title>
|
|
|
|
| | |
|
|
|---|---|
|
|
| **Status** | Proposed |
|
|
| **Author(s)** | <your name / handle> |
|
|
| **Discussion** | <link to the originating Discussion, if any> |
|
|
| **Implementation** | <issue/PR links, filled in as work lands> |
|
|
|
|
> Status is maintained by maintainers: `Proposed` while the PR is open,
|
|
> `Accepted` on merge, `Declined` on close, `Superseded by NNNN` later.
|
|
|
|
## Summary
|
|
|
|
One paragraph: what this changes, in plain terms.
|
|
|
|
## Motivation
|
|
|
|
What problem does this solve, and why is it worth the ongoing cost? Tie it to a
|
|
concrete need (a Discussion, a recurring issue, a user request). Per the
|
|
project's first principle, argue the *long-run liability*, not just the
|
|
short-term convenience.
|
|
|
|
## Guide-level explanation
|
|
|
|
Explain the change as you'd teach it to a user or contributor: new commands,
|
|
syntax, API shapes, behavior. Examples first.
|
|
|
|
## Reference-level design
|
|
|
|
The precise design: data structures, IR/AST/planner changes, storage/format
|
|
impact, migration path, error behavior. Enough that a reviewer can find the
|
|
holes.
|
|
|
|
## Invariants & deny-list check
|
|
|
|
Which Hard Invariants in [../dev/invariants.md](../dev/invariants.md) does this
|
|
touch? Does it brush against any deny-list item — and if so, why is this the
|
|
justified exception? State explicitly that no invariant is weakened, or which
|
|
Known Gap moves.
|
|
|
|
## Drawbacks & alternatives
|
|
|
|
What does this cost, what did you reject, and why. "Do nothing" is a valid
|
|
alternative to weigh.
|
|
|
|
## Reversibility
|
|
|
|
Is this reversible? On-disk/wire/format and substrate choices are near-permanent
|
|
and demand more evidence; a CLI flag or doc is cheap to undo. Say which this is.
|
|
|
|
## Unresolved questions
|
|
|
|
What's deliberately left open for review to settle.
|