RFCs¶

How significant technical changes get proposed and discussed. Live RFCs are GitHub Issues; this directory is the permanent archive of accepted RFCs.

New here? The concepts — what an RFC is and why it works this way — are explained on the homepage. This page is the process.

Lifecycle¶

stateDiagram-v2
    [*] --> draft: issue opened (RFC form)
    draft --> review: author signals ready
    review --> final_comment: FCP opens (≥5 working days)
    review --> withdrawn: author withdraws
    final_comment --> accepted: decision
    final_comment --> rejected: decision
    final_comment --> review: substantial objection reopens discussion
    accepted --> [*]: archived here + ADR recorded
    rejected --> [*]: issue closed, stays searchable

State = exactly one rfc/* label. Engineering leadership applies rfc/final-comment, rfc/accepted, rfc/rejected; the other transitions are the author's.

On acceptance¶

When an RFC is labeled rfc/accepted, automation posts the checklist on the issue. The author (or a lead) then opens one PR that:

Archives the RFC body as RFCs/RFC-<issue#>-<kebab-title>.md, using templates/rfc.md — the RFC's ID is its issue number.
Records the resulting decision as an ADR in ADRs/, linked back via the rfc: frontmatter field.

Review process¶

Anyone may open an RFC — seniority is not a prerequisite; evidence is.
The author drives: incorporates feedback by editing the issue body (GitHub keeps edit history), answers or explicitly parks every open question.
Silence is not consent until the Final Comment Period has run.

What warrants an RFC¶

New technology adoption, cross-team contracts, anything hard to reverse. Team-local, reversible choices don't — record them as a lightweight ADR directly if worth remembering.

Archive¶

No accepted RFCs yet — open the first one and start the flow.

ID	Title	Outcome

Open RFCs → · Rejected RFCs →