f2c512ae26
The repo is a 2-person team where both maintainers own every path, so the CODEOWNERS machinery (generated CODEOWNERS, roles yml, render script, the two drift/hand-edit CI jobs) gated nothing real while adding friction: every PR showed "Review required" and own-PRs merged only via admin/bypass override. Remove the whole chassis and drop the review gate: - delete .github/CODEOWNERS, codeowners-roles.yml, render-codeowners.py, the CODEOWNERS workflow, and docs/dev/codeowners.md - branch-protection.json: drop the two CODEOWNERS required status checks, set require_code_owner_reviews=false and required_approving_review_count=0 (CI checks are the gate; maintainers merge their own PRs once green) - scrub CODEOWNERS references from AGENTS.md, docs indexes, branch-protection and ci docs, GOVERNANCE.md, and CONTRIBUTING.md The policy change is inert until an admin runs scripts/apply-branch-protection.sh. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5.8 KiB
Governance
This document describes how external contributions to OmniGraph are proposed, accepted, and merged. It exists so an outside contributor can answer, without asking: where does my report/idea/change go, who decides, and what has to happen before code lands?
Scope. This governs the public contribution surface — Issues, Discussions, RFCs, and pull requests from people outside the ModernRelay team. Maintainers operate under a separate internal process and are not bound by the intake gates below. Everyone, maintainer or not, is still bound by the universal gates: branch protection on
mainand CI (see docs/dev/branch-protection.md).
Roles
| Role | Who | Authority |
|---|---|---|
| Maintainer | The ModernRelay team (repository admins) | Validate issues, accept/reject RFCs, review and merge PRs, set direction. Final decision authority. |
| Contributor | Anyone else | Report problems (Issues), propose ideas (Discussions), author RFCs, and open pull requests. |
Decision authority rests with the maintainers (the ModernRelay team holding repository-admin access).
The three channels
Each channel has one job. Using the right one is the first thing we ask of a contribution.
| Channel | Purpose | Not for |
|---|---|---|
| Issues | Report a problem — a bug, a regression, a documented behavior that's wrong. Something concrete and reproducible. | Feature requests, ideas, questions, or design proposals (→ Discussions). |
| Discussions | Propose and explore — new ideas, feature requests, questions, and the incubation of RFCs. | Bug reports (→ Issues). |
| Pull requests | Land a sanctioned change — a fix for a validated issue, an accepted RFC, or a trivial change (see fast-lane). | Substantive change with no backing issue/RFC — it will be redirected. |
How a change becomes mergeable
┌─────────── bug ───────────┐ ┌──────── idea / feature ────────┐
▼ │ ▼ │
Issue (problem report) │ Discussion (idea / RFC incubation) │
│ │ │ │
maintainer triage │ rough consensus │
│ │ │ graduate │
▼ │ ▼ │
label: accepted ──────────┐ │ RFC PR (docs/rfcs/NNNN-*.md) │
│ │ │ │ │
│ │ │ maintainer review │
▼ ▼ │ ▼ │
Pull request ◀──────────┴──────────│── merged == accepted │
(links the issue or the accepted RFC) ◀───────┘ (implementation PRs reference it) │
│
review + branch protection + CI
▼
merged
Issues → validated
A new issue starts unlabeled. A maintainer triages it and, if it's a real,
in-scope problem, applies the accepted label. Only accepted issues are
open for a contributor PR. This prevents the "I fixed an issue you hadn't
agreed was a problem" rejection. Want to fix something? Get the issue accepted
first, or pick one already labelled accepted / help wanted.
Discussions → RFCs → accepted
Ideas and feature requests start in Discussions. Anyone — including external
contributors — may then author an RFC by opening a pull request that adds
docs/rfcs/NNNN-title.md (see docs/rfcs/README.md). The
RFC is reviewed as code; a maintainer merging it is the act of acceptance
(it becomes the durable decision record). Implementation PRs then reference the
accepted RFC.
Authoring an RFC is open to everyone; accepting one is a maintainer decision. Maintainers may also decline an RFC, with rationale, by closing it.
Pull requests → sanctioned
A contributor PR must do one of:
- link a maintainer-
acceptedissue it fixes, or - be (or reference) an accepted RFC, or
- qualify for the trivial fast-lane.
Trivial fast-lane — these may be opened directly, no prior issue/RFC: typo and wording fixes, documentation corrections, dependency bumps, comment fixes, and obviously-correct one-line CI tweaks. When in doubt, open an Issue or Discussion first; a PR that turns out to be non-trivial will be asked to.
A substantive PR with no backing issue/RFC will be closed with a pointer to the right channel — not as a judgment of the idea, but to keep design discussion where it's reviewable.
What maintainers do not gate
Maintainers' own changes do not pass through the intake gates above — the team runs a separate internal process. The universal gates (review, branch protection, CI) apply to everyone. Enforcement of the intake rules is, to start, by convention and review (PR template + labels); an automated check keyed to author association may be added later if volume warrants.
Code of conduct & security
- Conduct: CODE_OF_CONDUCT.md.
- Security issues are not public Issues — see SECURITY.md.
Changing this document
Governance changes the same way code does: a pull request, reviewed by maintainers. This file describes the external surface; the internal maintainer process is intentionally out of scope here.