RFC process

For anything bigger than a bug fix or a few-line refactor, we ask for an RFC (Request For Comments).

How to write one

1. Copy docs/rfc/_template.md to docs/rfc/NNN-short-name.md (next free NNN).
2. Open a PR with only the RFC, in Draft state.
3. Solicit feedback. Iterate.
4. Maintainers mark accepted or rejected. Implementation PRs reference the RFC number in their description.

Why we run this way

• The RFC is the design. The code is the implementation of the design. When the two diverge, we update the RFC.
• The RFC is the changelog of decisions. Future maintainers can read the RFCs and understand why the engine looks like it does.
• Reviewers can argue with text before anyone has written a thousand lines they’re emotionally invested in.

What lives in docs/rfc/

Every accepted RFC. See the index for the full list (we’re at RFC-020 today, with RFC-021 in flight for the read fan-out work).

See also

• Internals (RFCs)
• Contributing