An RFC, or request for comments, is a written proposal circulated to a defined audience for structured feedback before a decision is made. The author lays out the problem, the proposed solution, alternatives considered, and tradeoffs. Reviewers comment in writing, and the author either revises or proceeds.
RFCs are distinct from design docs in intent: a design doc explains a chosen approach, while an RFC asks whether the approach should be chosen. They are distinct from decision logs in time: the RFC is the deliberation, the decision log is the outcome.
RFCs work especially well for distributed teams because the entire decision process happens in writing. There is no privileged information from a meeting that didn't get recorded.
Why rfc (request for comments) matters for distributed teams
RFCs prevent the most common distributed-team failure: a decision made in a meeting that half the team wasn't in. When the decision lives in an RFC, anyone in any timezone can read the reasoning and contribute before it closes.
RFCs also create durable artifacts. A year later, a new engineer can read the RFC and understand why the architecture looks the way it does.
RFC (request for comments) in practice
A distributed team proposes migrating their primary database. Rather than deciding in a meeting that half the team cannot attend, the lead engineer writes an RFC: problem statement, proposed migration path, two alternatives considered and why they were ruled out, a list of risks, and a decision-close date two weeks out. Engineers across three time zones comment asynchronously. The RFC is accepted with one modification. The decision log captures the final choice and links back to the RFC for future reference.
A platform team wants to change how services authenticate with each other. A junior engineer writes a draft RFC describing the problem. Before any code is written, the security team adds concerns in comments, the infra lead proposes a different approach, and the final RFC reflects both inputs. No meeting was required.
Frequently asked questions
What is an RFC in engineering?
An RFC, or request for comments, is a written proposal circulated for feedback before a decision is made. It captures the problem, proposed solution, alternatives, and tradeoffs. Reviewers comment in writing rather than in meetings.
What does RFC stand for?
RFC stands for Request for Comments. In engineering contexts it refers to a structured written proposal used to gather feedback on technical decisions before they are finalized. The term originates from the IETF, which published foundational internet standards as RFCs, but engineering teams have adopted the format broadly for architecture and process decisions.
What is RFC meaning in software development?
In software development, an RFC is a document that proposes a technical change, new feature, or architectural decision and invites structured feedback from the team before the decision is made. It is a deliberation artifact — the decision log captures the outcome after the RFC closes.
What is the difference between an RFC and a design doc?
A design doc explains a chosen approach after the decision has been made. An RFC asks whether the proposed approach should be chosen before the decision is made. RFCs are open for comment and revision; design docs document what was decided.
How do you write an RFC?
A minimal RFC includes: (1) a problem statement — what is broken or missing; (2) a proposed solution — how to fix it; (3) alternatives considered — what else was evaluated and why it was ruled out; (4) open questions — what the author is uncertain about; and (5) a decision-close date — when feedback ends and a decision is made.
Related terms
Decision log
A decision log is a chronological record of decisions made by a team. Each entry captures the question that was decided,...
Read definition →Decision documentation
Decision documentation is the written record of decisions made by a team, including the question, the options considered...
Read definition →Asynchronous decision making
Asynchronous decision making is the practice of reaching decisions without requiring all participants to be online at th...
Read definition →Get the vocabulary that makes distributed teams work
One email per week on async governance. No spam.
See rfc (request for comments) in action.
StandIn is built around these concepts. Engineers publish declared state before going offline. The next shift starts with full context.