Governance: issue-first intake, Discussions retired (#512)

* docs(governance): issue-first intake, retire Discussions

Features and designs now enter as issues (feature/RFC forms, auto-labelled
needs-triage); the accepted label is the gate before implementation effort,
and a merged RFC sanctions its implementation PRs directly. The trivial
fast-lane stays for small, obviously-correct fixes. Discussions are retired
as an inbound channel; the four open threads were migrated to issues
#508-#511 before the setting was turned off. Internal review mechanics
(approval counts, maintainer process references) are no longer part of the
public surface. Also corrects two CONTRIBUTING inaccuracies: CI checks
openapi.json for drift but never regenerates it, and protoc is a required
build dependency.

* docs(rfcs): repoint RFC-0029 provenance to migrated issue

Discussion #439 became issue #509 when Discussions were retired; the old
link no longer resolves.

* docs(governance): needs-rfc replaces accepted, not stacks on it

The one-status-label rule left size-L triage ambiguous: the rfcs README
diagram showed accepted and needs-rfc together. needs-rfc now explicitly
replaces accepted while the design is outstanding and the issue returns to
accepted when the RFC merges.

Author: aaltshuler

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -6,13 +6,13 @@ body:
   - type: markdown
     attributes:
       value: |
-        Issues are for **reporting problems** — concrete, reproducible bugs.
-        For ideas, feature requests, or questions, please use
-        [Discussions](../../discussions) instead.
-        For a security vulnerability, follow [SECURITY.md](../../blob/main/SECURITY.md) — do **not** file it here.
+        This form is for **reporting problems** — concrete, reproducible bugs.
+        For an idea or feature request, use the
+        [feature proposal form](https://github.com/ModernRelay/omnigraph/issues/new/choose) instead.
+        For a security vulnerability, follow [SECURITY.md](https://github.com/ModernRelay/omnigraph/blob/main/SECURITY.md) — do **not** file it here.
 
         A maintainer will triage this; once labelled **`accepted`** it's open for a pull request
-        (see [GOVERNANCE.md](../../blob/main/GOVERNANCE.md)).
+        (see [GOVERNANCE.md](https://github.com/ModernRelay/omnigraph/blob/main/GOVERNANCE.md)).
   - type: textarea
     id: what-happened
     attributes:

.github/ISSUE_TEMPLATE/config.yml

@@ -1,13 +1,7 @@
-# Issues are for problem reports only. Disable blank issues so everything is
-# routed: bugs through the form, everything else to Discussions / SECURITY.md.
+# Issues are the only inbound channel (see GOVERNANCE.md). Blank issues stay
+# disabled so every report lands on a form; security goes to SECURITY.md.
 blank_issues_enabled: false
 contact_links:
-  - name: 💡 Idea, feature request, or RFC
-    url: https://github.com/ModernRelay/omnigraph/discussions
-    about: Propose features and designs in Discussions. RFCs graduate from there into a docs/rfcs/ pull request.
-  - name: ❓ Question or help
-    url: https://github.com/ModernRelay/omnigraph/discussions
-    about: Ask in Discussions — questions are not tracked as Issues.
   - name: 🔒 Security vulnerability
     url: https://github.com/ModernRelay/omnigraph/blob/main/SECURITY.md
     about: Report security issues privately per SECURITY.md — never as a public Issue.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,33 @@
+name: 💡 Feature proposal
+description: Propose a change. A maintainer triages it; work starts once it is labelled `accepted`.
+labels: ["feature", "needs-triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Every change starts as an issue (see [GOVERNANCE.md](https://github.com/ModernRelay/omnigraph/blob/main/GOVERNANCE.md)).
+        A maintainer triages this: **`accepted`** is the green light for a PR, and a
+        larger design gets **`needs-rfc`** and goes through an RFC first
+        ([docs/rfcs/README.md](https://github.com/ModernRelay/omnigraph/blob/main/docs/rfcs/README.md)).
+        Trivial fixes (typos, obvious small corrections) can skip the issue and go straight to a PR.
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem
+      description: What can't you do today, or what costs too much? Concrete scenarios beat abstractions.
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed change
+      description: What should exist? If it adds user-visible surface (CLI, API, query/schema language), sketch it.
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+      description: Other ways to solve it, including doing nothing.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/rfc_proposal.yml

@@ -0,0 +1,35 @@
+name: 📐 Design / RFC proposal
+description: Propose a design-level change. The issue is accepted first; the RFC document follows as its own PR.
+labels: ["rfc", "needs-triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        For design-level changes: new user-facing surface, on-disk or wire formats,
+        new substrate dependencies, anything irreversible. Do **not** write the RFC
+        document yet — this issue gets `accepted` first, so nobody invests in a
+        design a maintainer hasn't agreed should exist. Once accepted (and labelled
+        `needs-rfc`), open an RFC PR per
+        [docs/rfcs/README.md](https://github.com/ModernRelay/omnigraph/blob/main/docs/rfcs/README.md);
+        the merged RFC then sanctions the implementation PRs, and this issue tracks them.
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem
+      description: What is wrong or missing, and why does it matter?
+    validations:
+      required: true
+  - type: textarea
+    id: direction
+    attributes:
+      label: Proposed design direction
+      description: The shape of the solution — enough to judge whether the problem is worth an RFC, not the full design.
+    validations:
+      required: true
+  - type: textarea
+    id: scope
+    attributes:
+      label: Blast radius
+      description: What does this touch — storage format, wire protocol, query language, dependencies? What becomes hard to reverse?
+    validations:
+      required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,6 @@
 <!--
   Thanks for contributing! See CONTRIBUTING.md and GOVERNANCE.md.
-  A substantive PR needs a backing accepted issue or accepted RFC.
-  Maintainers: your internal process applies; the link requirement below
-  is for external contributions.
+  A substantive PR needs a backing accepted issue or merged RFC.
 -->
 
 ## What & why
@@ -14,7 +12,7 @@
 <!-- Pick one. A substantive change needs (1) or (2). -->
 
 - [ ] Fixes an **accepted** issue: Closes #
-- [ ] Implements / is an **accepted** RFC: <link to docs/rfcs/NNNN-*.md>
+- [ ] Is an RFC PR, or implements a **merged** RFC: <link to docs/rfcs/NNNN-*.md>
 - [ ] **Trivial fast-lane** (typo / docs / dependency bump / comment / one-line CI) — no issue/RFC required
 
 ## Checklist

CONTRIBUTING.md

@@ -7,26 +7,34 @@ rules and decision authority behind it live in [GOVERNANCE.md](GOVERNANCE.md).
 
 | I want to… | Go to | Notes |
 |---|---|---|
-| **Report a bug** or wrong behavior | **[Open an Issue](../../issues/new/choose)** | Concrete and reproducible. A maintainer triages it; once labelled **`accepted`** it's open for a PR. |
-| **Suggest a feature / share an idea / ask** | **[Start a Discussion](../../discussions)** | Ideas and questions live here, not in Issues. |
-| **Propose a design / RFC** | **An RFC pull request** | Anyone can copy the public template and declare `Author track: Public contribution` — see [docs/rfcs/README.md](docs/rfcs/README.md). A maintainer merging a public RFC is acceptance; maintainer design series use their explicit status lifecycle. |
-| **Fix something / implement a change** | **A pull request** | Must link an `accepted` issue or an accepted RFC — unless it's trivial (below). |
+| **Report a bug** or wrong behavior | **[Open an Issue](../../issues/new/choose)** — bug form | Concrete and reproducible. A maintainer triages it; once labelled **`accepted`** it's open for a PR. |
+| **Propose a feature / share an idea** | **[Open an Issue](../../issues/new/choose)** — feature form | A maintainer triages it. **`accepted`** means a PR may follow; a larger design gets **`needs-rfc`** and goes through an RFC first. |
+| **Propose a design / RFC** | **An Issue first**, then an RFC pull request | Get the issue `accepted` before investing in the RFC document. A maintainer merging the RFC PR is acceptance; the merged RFC then sanctions implementation PRs — see [docs/rfcs/README.md](docs/rfcs/README.md). |
+| **Fix something / implement a change** | **A pull request** | Must link an `accepted` issue or a merged RFC — unless it's trivial (below). |
 | **Report a security vulnerability** | **[SECURITY.md](SECURITY.md)** | Do **not** open a public Issue. |
 
+GitHub Discussions are not used — Issues are the only inbound channel.
+
 ### When can I just open a PR?
-The **trivial fast-lane** — open directly, no prior issue/RFC needed: typo and
-wording fixes, doc corrections, dependency bumps, comment fixes, obvious
-one-line CI tweaks. Anything more substantial needs a backing `accepted` issue
-or accepted RFC first, so the *why* is agreed before the *how* is reviewed. A PR
+The **trivial fast-lane** — open directly, no prior issue/RFC needed, when the
+change is clearly broken-fixing with small blast radius and no design impact:
+typo and wording fixes, doc corrections, dependency bumps, comment fixes,
+obvious one-line CI tweaks. **If you cannot tell trivial from real, it is real
+— open the issue.** Anything more substantial needs a backing `accepted` issue
+or merged RFC first, so the *why* is agreed before the *how* is reviewed. A PR
 that turns out to be non-trivial will be redirected — that's about process, not
 the merit of the change.
 
-> **Maintainers (ModernRelay team)** follow a separate internal process and are
-> not bound by the intake rules above. Everyone is bound by review, branch
-> protection, and CI.
-
 ## Development
 
+Building requires the Rust stable toolchain and `protoc` (the Protocol Buffers
+compiler — a build dependency of the storage substrate):
+
+```bash
+brew install protobuf                                  # macOS
+sudo apt-get install -y protobuf-compiler libprotobuf-dev   # Debian/Ubuntu
+```
+
 ```bash
 cargo build --workspace
 cargo test --workspace
@@ -38,18 +46,15 @@ integration tests.
 ### OpenAPI spec
 
 `openapi.json` is a committed artifact generated from the Utoipa annotations in
-`crates/omnigraph-server`. For PRs opened from this repository, a CI job
-regenerates it automatically and commits the updated file back to the PR
-branch. For PRs from forks (where CI cannot push), run the regeneration
-manually:
+`crates/omnigraph-server`. CI never regenerates or commits it — it only checks
+for drift and fails the build if the committed copy disagrees with the source.
+When your change touches the server API surface, regenerate locally and commit
+the result in the same PR:
 
 ```bash
 OMNIGRAPH_UPDATE_OPENAPI=1 cargo test -p omnigraph-server --test openapi openapi_spec_is_up_to_date
 ```
 
-The workspace test run fails if the committed `openapi.json` drifts from what
-the source generates.
-
 ### Cargo features
 
 `omnigraph-server` has an optional `aws` feature that pulls in the AWS
@@ -68,8 +73,8 @@ CI runs both.
 
 ## Pull Requests
 
-- **Link the backing issue or RFC** (`Closes #123`, or reference the RFC) — or
-  mark the PR as trivial per the fast-lane.
+- **Link the backing `accepted` issue or merged RFC** (`Closes #123`, or
+  reference the RFC) — or mark the PR as trivial per the fast-lane.
 - Keep changes focused; one logical change per PR.
 - Include tests for behavior changes when practical.
 - Update public docs when the user-facing surface changes.