RFCs (requests for comment)
RFCs are written proposals for significant engineering work: new subsystems, migrations, security posture changes, or anything that is expensive to undo. They complement ADRs, which record decisions after consensus.
When to write an RFC
Create an RFC when two or more of the following apply:
- The change spans multiple services (
frontend,backend,python-service) or shared infrastructure. - There are multiple viable designs with different operational tradeoffs.
- Rollout, backfill, or data migration risk is non-trivial.
- You need explicit review from security, ops, or product before coding.
Small, localized changes follow the normal PR flow described in Conventions.
RFC lifecycle (lightweight)
- Draft — Open a PR that adds
docs/projects/rfcs/YYYY-MM-DD-short-title.md(or discuss in an issue first if discovery is still ongoing). - Review — Tag reviewers in the PR; incorporate feedback in the same document.
- Accepted — Merge the RFC PR with an explicit Accepted note and links to implementation PRs.
- Superseded — If plans change materially, add a banner at the top pointing to the newer RFC or ADR.
Library
There are no standalone RFC markdown files in this repository yet. When the first RFC lands, add it here:
| RFC | Status | Summary |
|---|---|---|
| — | — | No RFCs published in-tree yet. |
Until then, use the Architecture hub for module-level design context and ADRs for locked-in decisions.