mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-18 02:24:27 +02:00
governance: external contribution model (issues/discussions/RFCs/PRs) (#143)
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>
This commit is contained in:
parent
c7365bf8ef
commit
343f1f17ed
10 changed files with 406 additions and 8 deletions
|
|
@ -51,6 +51,18 @@ constraints. User-facing behavior should still be documented through
|
|||
| Install and deployment packaging | [install.md](../user/install.md), [deployment.md](../user/deployment.md) |
|
||||
| Release history | [releases/](../releases/) |
|
||||
|
||||
## Contribution & Governance
|
||||
|
||||
| Area | Read |
|
||||
|---|---|
|
||||
| How to contribute (external) | [CONTRIBUTING.md](../../CONTRIBUTING.md) |
|
||||
| Governance model, roles, decision authority | [GOVERNANCE.md](../../GOVERNANCE.md) |
|
||||
| Public contribution RFC track | [rfcs/](../rfcs/) |
|
||||
|
||||
The `docs/rfcs/` track is the **public, externally-authorable** RFC process. The
|
||||
maintainer/internal RFCs below (`rfc-00N-*.md`) are a separate, team-owned
|
||||
track; don't conflate the two.
|
||||
|
||||
## Active Implementation Plans
|
||||
|
||||
Working documents for in-flight feature work. Removed when the work lands.
|
||||
|
|
|
|||
54
docs/rfcs/0000-template.md
Normal file
54
docs/rfcs/0000-template.md
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
# 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.
|
||||
66
docs/rfcs/README.md
Normal file
66
docs/rfcs/README.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
# 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](../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 under `docs/dev/rfc-00N-*.md` are 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](../dev/invariants.md) flags; anything irreversible
|
||||
("reversibility shapes evidence demand").
|
||||
- **RFC not required:** bug fixes for an `accepted` issue, and the trivial
|
||||
fast-lane (typos, docs, deps) — see [../../CONTRIBUTING.md](../../CONTRIBUTING.md).
|
||||
|
||||
If you're unsure, start a [Discussion](../../../discussions); 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 `Status` to `Superseded`.
|
||||
|
||||
## Numbering & naming
|
||||
|
||||
- File: `docs/rfcs/NNNN-kebab-title.md`, where `NNNN` is the next free
|
||||
zero-padded integer (`0001`, `0002`, …). `0000-template.md` is 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](0000-template.md) to start.
|
||||
Loading…
Add table
Add a link
Reference in a new issue