RFC Process for Engineering Teams: Template and Steps

RFC stands for request for comments. In an engineering team, an RFC process is how someone proposes a change in writing, collects feedback from the people it affects, and gets a clear decision from a named owner, usually without needing a meeting.

The term comes from the internet's early days. Since 1969, the standards behind protocols such as HTTP and email have been published as numbered RFC documents. Engineering teams borrowed the name for a lighter version of the same idea: write it down, ask for comments, then decide.

What an RFC process is for

An RFC suits decisions that need input from several people but should not need everyone in a room. Typical examples are a new service, a change to a shared API, a new framework, or a change to how teams deploy. Small changes do not need one. A pull request with a good description is enough for those.

The process does three jobs. It forces the author to think the proposal through before asking for time. It lets reviewers respond when they have time, which matters on a team spread across time zones. And it leaves a written record of what was proposed, what people objected to, and what was decided.

The steps

1. Draft: the author writes the proposal using the template below and names a decider: the one person who will make the final call.
2. Share: the author posts the link where the affected people will see it and states the review window, usually three to five working days.
3. Comment: reviewers comment in the document. The author replies, changes the proposal, or notes open objections.
4. Decide: at the end of the window, the decider accepts, rejects or asks for changes, and writes the decision and the reason at the top of the document.
5. Record: the author adds a line to the team's decision log, linking to the RFC. Architecture decisions also get an ADR.

The decide step is where most RFC processes fail. Without a named decider and a deadline, an RFC stays open for weeks, collects comments, and stalls. Naming the decider in the first line of the document fixes most of this. If you are not sure who that should be, check your decision authority map.

An RFC template

RFC-17: Move inter-service calls to the shared event queue

Author: Dana Kim        Decider: Priya Shah (staff engineer)
Status: Open for comments until Friday
Decision: (filled in by the decider when the RFC closes)

Problem
What is wrong today, and who it affects. Two or three sentences.

Proposal
What you want to change, in enough detail to review.

Options considered
The alternatives, and why this one is better.

Risks and costs
What could go wrong, what it costs to build and run, how to roll it back.

Open questions
What you have not decided, and need input on.

Rollout
Steps, owners and rough timing.

Using the template in Confluence or Google Docs

The template works in any tool your team already uses. In Confluence, save it as a page template and keep all RFCs under one parent page, so they are numbered and easy to browse. In Google Docs, keep a template doc and a folder. Whichever tool you use, put the status and the decision at the very top, where a reader sees them first.

Running RFCs across time zones

RFCs are well suited to distributed teams because nobody has to be online at the same time. A few rules keep them moving:

• Set the review window in working days, so every time zone gets the same chance to comment.
• Ask reviewers to say plainly whether they object or only have a suggestion.
• If comments go in circles for more than two rounds, the decider calls a short meeting and writes the outcome back into the document.
• Close on time. A late decision is better than an RFC that never ends.

Turning the RFC into the record

An accepted RFC is a useful record of the reasoning, but it is long, and it describes the proposal as it stood on the day it was accepted. Six months later, people need the short answer: what was decided, who decided, and is it still current? That is why the last step adds a line to the decision log. The RFC holds the detail. The log holds the result, and points back to the detail.

When a later RFC changes the decision, update the old RFC's status to "replaced by RFC-24" so nobody follows outdated advice. The guide to a system of record for decisions covers how these pieces fit together.

Where StandIn fits

StandIn answers your teammates' questions from the work you have already done, in your words, with a source under every answer. If you wrote the RFC and you are away when someone asks why the team chose the queue, your StandIn answers from the RFC and your brief, with your name and the source. When the answer is not written down, it never guesses. See how StandIn works.