Most RFC processes don’t fail because the template is wrong. They fail because nobody wrote down when comments close, nobody is accountable for the outcome, and the whole thing ends in a meeting where the loudest voice in the room wins by default.

The document was never the problem. The missing mechanics were.

Three mechanics make an RFC process decide instead of circulate. They are separable, and you can adopt them in order of cost. Adding a review-close date to the header costs nothing. Naming a decision owner costs one line. Defaulting to asynchronous review is the only one that requires a cultural change, so it should come last.

Two jobs people keep conflating

An RFC does two things, and teams routinely blur them:

  • Collecting feedback. Anyone affected gets a chance to raise concerns, surface prior art, and point out what the author missed.
  • Making a decision. Someone states what will happen, why, and when.

Phil Calçado’s write-up of a structured RFC process is explicit that these are not the same activity. Feedback is informational: authors are free to incorporate it or not. And the process he describes requires authors to acknowledge every piece of feedback given, so reviewers don’t feel their time was wasted. He also states the part teams skip: whatever feedback-gathering process you adopt, you must explicitly acknowledge who the decision maker is — the person accountable for the outcome, with veto power over it.

That’s the whole game. Feedback without a decision owner is a suggestion box. A decision owner without a comment deadline is a bottleneck with no exit condition.

Mechanic 1: A comment deadline in the header

The Attentive engineering team’s account of rebuilding their RFC process names the failure mode directly: a document that never leaves draft status creates ambiguity about when feedback is expected. Their fix is to time-box the review period, with a clear opening and closing window. They suggest one week as a default for a medium-sized RFC, expanding or shrinking with scope and complexity.

Treat that week as a starting point, not a rule. The mechanic is the visible close date, not the specific number.

The deadline only works if it lives in the document header. If a reader has to scroll a comment thread to find out when feedback is due, the deadline isn’t doing its job.

Before

# RFC: Cursor pagination for /v2/orders

Author: Priya Anand
Status: Draft

After

# RFC: Cursor pagination for /v2/orders

Author: Priya Anand
Decision owner: Marcus Webb
Review closes: 2026-11-06 (end of day, UTC)
Status: In Review
Revisit: 2027-02-06

Two rules keep the deadline honest:

  • Feedback after close becomes an addendum, not a blocker. The Attentive post states that post-closure changes should be captured as addendums to preserve decision history. This is the difference between a process that closes and a process that reopens every time someone reads the doc late.
  • Extensions are announced, not assumed. If the review genuinely needs more time, the decision owner moves the date and says so in the document. Silent slippage is how perpetual drafts are born.

Mechanic 2: One named decision owner

Naming a decision owner is not the same as naming approvers. An approver can block. A decision owner must also state what happens next. If your header lists three approvers and no owner, the RFC has no exit condition — it has three exit conditions, which is zero.

Calçado’s framing is worth quoting in full because it’s the sentence most teams need to paste into their process doc: the decision maker is “the one accountable for the outcome and with veto power over it.”

The Attentive post puts the same idea in lifecycle terms: authors own the outcome and are empowered to accept or reject feedback and move the proposal forward. Reviewers offer perspectives, not arguments. The goal is not to win a debate.

What the decision owner actually does, concretely:

  • Acknowledges every comment. Not every comment needs a change. Every comment needs a response, even if the response is “considered, not adopted, because X.”
  • States the outcome on the close date. Approved, changes requested, or blocked — with a reason. Silence is not a decision.
  • Owns the revisit date. Calçado’s header format includes a revisit date alongside the review date, and the process requires authors to commit to revisiting the decision later and sharing what they learned.

One caution: a named decision owner does not eliminate disagreement, and it does not guarantee adoption. It makes accountability legible. That’s the whole benefit, and it’s enough.

Mechanic 3: The meeting you skip

Default to asynchronous review. The Attentive post is direct about this: RFCs should default to asynchronous review to allow thoughtful feedback, and meetings are valuable when discussion stalls or complex trade-offs need real-time alignment.

That’s a narrower trigger than most teams use. The meeting you skip is usually a status meeting wearing a design-review costume.

A useful test before you book the room: can the open question be answered by one person reading the document for ten minutes? If yes, it’s a comment, not a meeting.

When a meeting is genuinely warranted, the same source sets three conditions:

  • Ask participants to read the document beforehand.
  • Set a concrete agenda.
  • Link the meeting directly in the RFC so observers can opt in.

If you can’t write the agenda as a list of open questions with named owners, you don’t have a meeting. You have a calendar block.

Status vocabulary small enough to memorize

Perpetual drafts are a status problem. The Attentive process uses five states, and five is enough for most teams:

  • Draft — initial writing; early feedback may be solicited once the design is structurally complete.
  • In Review — ready for broad feedback and active discussion.
  • Changes Requested — serious concerns must be addressed before approval.
  • Approved / Closed — review complete; comments are no longer blocking.
  • Blocked / Discarded — review surfaced major issues or blocking requirements.

Adding a sixth state usually means the team is encoding an org chart into a document header. Resist.

Keep the record immutable after the decision

Comment deadlines and immutability solve different problems, and merging them breaks both. The deadline governs when input is welcome. Immutability governs what happens to the record afterward.

AWS Prescriptive Guidance on architectural decision records states the rule plainly: when the team accepts an ADR, it becomes immutable; if new insights require a different decision, the team proposes a new ADR, and accepting the new one supersedes the previous. The AzureLocal platform’s ADR process adds the operational detail: accepted ADRs are immutable except for corrections to the Status field when superseded, and you don’t silently edit an accepted ADR — you write a new one that supersedes it.

This is where RFCs and ADRs complement each other rather than compete. An RFC is a proposal under review with a closing window. An ADR is the durable record of a decision that was made. The ADR GitHub organization defines an ADR as capturing a single architectural decision and its rationale, with the collection of ADRs in a project constituting its decision log. AWS’s guidance says at minimum each ADR should define the context of the decision, the decision itself, and the consequences — and notes that the structure focuses on the reason for the decision rather than how the team implemented it.

Practical division of labor for a 20–200 person engineering org:

  • RFC — used when a change extends beyond one team, when the blast radius is large, or when you want structured early feedback from people you don’t work with daily.
  • ADR — written once the decision is made, numbered, immutable, stored close to the code. Google Cloud’s ADR guidance recommends storing ADRs close to the application code, ideally in the same version control system, and notes they help teams avoid repeating the same discussion points.

Don’t write an ADR for a typo fix. Don’t write an RFC for a decision that only affects your own service and has no cross-team contract implications.

The artifact: a header block and a five-line process note

This is the part you can paste into your repo today. It is a header block plus a short process note — not a policy document. Anything longer will not be read by the people who need it most.

RFC header block

# RFC: <title>

Author: <name>
Decision owner: <name>
Review closes: <YYYY-MM-DD> (end of day, UTC)
Status: Draft | In Review | Changes Requested | Approved | Blocked
Revisit: <YYYY-MM-DD>

## Problem
## Proposal
## Alternatives considered
## Open questions

Process note

1. The decision owner is accountable for the outcome and has veto power.
2. Review closes on the date in the header. Feedback after close becomes an addendum.
3. Every comment gets an acknowledgment, even if the answer is "not adopted."
4. Review is asynchronous by default. Schedule a meeting only if discussion stalls
   or trade-offs need real-time alignment — with pre-reading and an agenda.
5. Once decided, the record is immutable. Supersede it; don't edit it.

A worked shape, not a war story

Here’s the shape the process should produce. It’s a hypothetical, but it’s the one you’ll recognize.

A team writes an RFC proposing a new pagination scheme for a public API. The header lists the author, a decision owner, and a review window closing in five business days. Two reviewers raise concerns about cursor stability under concurrent writes. The decision owner acknowledges both, accepts one, rejects the other with a stated reason, and closes the RFC on the stated date. No meeting is scheduled.

That outcome requires no tooling beyond a header block. It requires no bot, no template repository, no governance committee. It requires three lines and the discipline to honor them.

What to change this week

Before you touch the template, add two lines to the next RFC you write: a review-close date and a named decision owner. Then honor the date.

If you want to go further, add the revisit date. Calçado’s process requires authors to commit to revisiting the decision later and sharing what they learned — which is the only mechanism in this whole process that produces evidence about whether the decision was any good.

FAQ

What if nobody comments during the review window?

Silence is not approval, but it is also not a reason to extend indefinitely. The decision owner states the outcome on the close date and notes that no blocking feedback was received. If the decision turns out to be wrong, the revisit date is where you find out.

Can the decision owner also be the author?

Often, yes. The Attentive process treats authors as owning the outcome. The failure mode to avoid is a header with multiple approvers and no single accountable person — that’s the configuration with no exit condition.

How is this different from just writing an ADR?

An ADR records a decision that was made. An RFC is the review process that precedes it. AWS’s guidance describes ADRs as immutable once accepted, with changes requiring a new superseding ADR. If you only write ADRs, you skip the feedback window entirely. If you only write RFCs, you lose the durable decision log.

Do we need tooling for this?

No. A Markdown file in the repo with a header block works. Google Cloud’s ADR guidance recommends storing decision records close to the application code, ideally in the same version control system. The same applies to RFCs. A bot that announces new RFCs is a convenience, not a requirement.

What about RFCs that genuinely need more than a week?

Extend the window and say so in the document. The Attentive process describes the review period as expanding or shrinking based on scope and complexity. The point is that the close date is visible and the extension is announced, not that a specific duration is correct.

Should we use RFC 2119 keywords like MUST and SHOULD in internal RFCs?

Be careful. RFC 2119 defines those keywords for standards-track documents, and it explicitly states that imperatives of this type must be used with care and sparingly — only where actually required for interoperation or to limit behavior with potential for harm. Internal design docs rarely meet that bar. Plain prose is usually clearer.

Sources

No related posts.