docs: add CODEOWNERS, ADR template, and RFC process

[demohan]

Summary

Introduces three lightweight governance mechanisms so contributions to sensitive surfaces (wire protocol, storage trait, auth, on-disk format, public CLI) get the right review and a written record.

• .github/CODEOWNERS — auto-requests reviewers and (with branch protection enabled) gates merges on sensitive paths.
• docs/adr/ — adds 0000-template.md and a README.md describing when to write an ADR. Renames the two existing ADRs to 0001-documentation-format.md and 0002-sql-injection-defense.md so the numbering convention is consistent going forward.
• docs/rfcs/ — adds 0000-template.md and a README.md describing when an RFC is required and the Draft → Under Review → FCP → Accepted lifecycle.
• CONTRIBUTING.md — adds a "When you need an ADR or an RFC" section explaining the difference (ADR records a decision, RFC solicits input on a proposal).
• README.md — adds a "Contributing" section linking to ADRs, RFCs, and CODEOWNERS so contributors find the process from the project front door.
• .github/pull_request_template.md — adds one checklist line so PRs touching protected surfaces link to an ADR or RFC.

ADR vs. RFC, in one line each

• ADR records a decision after it is made (Context, Options, Decision, Consequences).
• RFC proposes a change before it is made and runs a structured comment period.

Why this shape

ExtendDB already had a docs/adr/ folder and two ADRs, but no template, no README, no numbering, and no documented trigger for when one is required. This PR fills those gaps with the lightest mechanism that still creates the discipline.

CODEOWNERS is intentionally uniform across paths today (same four owners on every line). The per-path lines are kept so future specialization (e.g., a dedicated storage maintainer) is one edit away.

Activation note (for maintainers)

CODEOWNERS does not gate merges by itself. To enforce, go to Settings → Branches → branch protection rule for main and enable "Require review from Code Owners".

Follow-ups

• Formalize maintainer set and governance model #117 — Formalize the maintainer set and governance model. The RFC acceptance rule in this PR currently treats .github/CODEOWNERS as the maintainer list. Issue Formalize maintainer set and governance model #117 tracks the eventual MAINTAINERS.md / GOVERNANCE.md work that would replace this stopgap.

Test plan

• Verify renamed ADR files render on GitHub
• Verify docs/adr/README.md index links resolve
• Verify docs/rfcs/README.md links to .github/CODEOWNERS resolve
• Verify CODEOWNERS syntax (GitHub will surface errors in the PR sidebar if any handle is wrong)
• Verify the PR template renders the new checklist line

[jcshepherd]

Nice! I left a few comments/questions around the RFC process (based on lessons learned/observed in the Cassandra world) but overall this is a nice start.

[jcshepherd]

Might also add something like "New operational requirements" or similar. Are users going to need understand anything new to use the proposed thingie?

[demohan]

Added an explicit "New operational requirements" bullet to the Detailed Design section so authors have to think about what an operator learns, configures, monitors, or runs differently after the change lands (new daemons, ports, config keys, metrics, runbooks, dependencies). e1ce936.

[jcshepherd]

What about significant new features in general: e.g., replication?

[demohan]

Agreed. The trigger list was surface-defined and would have let big subsystems slip through. Added a catch-all bullet: "A significant new feature or subsystem, even if it does not directly touch the surfaces above (for example, replication, multi-region, change data capture, a new auth provider, a new query interface)." e1ce936.

[jcshepherd]

I haven't looked at GitHub "Discussions" at all, but would it be worth having RFC submitters start a discussion with a link to the PR with the RFC, and have the discussion there, rather than cluttering the PR with potentially long wandering conversations? (The RFC can also have a link back to the discussion, for posterity.)

[demohan]

For now we are going with PR-as-thread because (a) it keeps line-level review and high-level debate in one place, and (b) we do not yet have enough RFC volume to know whether thread bloat will actually be the problem. I added a sentence noting that a maintainer can move broad design debate to GitHub Discussions if a PR becomes hard to follow, with the PR reserved for line-level comments. We can codify a stricter split if we hit the pain. e1ce936.

[jcshepherd]

How many?

[demohan]

Specified: minimum two maintainers, including at least one code owner for each surface the RFC affects. For now we are treating the people listed in .github/CODEOWNERS as the maintainer set, which keeps the rule grounded in something concrete without us needing a separate MAINTAINERS.md yet. e1ce936.

[jcshepherd]

Would any kind of voting mechanism be useful? E.g., minimum of X maintainers vote to accept, and none vote to reject?

[demohan]

Pulling out the lazy "no objections surface" wording. It concentrated too much call-it discretion in whichever maintainer announced FCP and did not tell a contributor what success looked like. Replaced with an explicit rule: at end of FCP, the RFC is accepted if (a) at least two maintainers have approved, (b) no maintainer has requested changes, and (c) no new substantive objection was raised during the FCP. A new substantive objection resets the 7-day clock. This gives contributors a deterministic finish line and gives any maintainer a real veto without naming any one person as a blocker. e1ce936.

[jcshepherd]

One other suggestion: I'd suggest putting rfcs/ under docs/ instead of in the project root.

[demohan]

Done in 407c85c. Moved rfcs/ to docs/rfcs/ and updated the cross-references in CODEOWNERS, README, CONTRIBUTING, the ADR README, and the relative paths inside the RFC files themselves.