RFC Process (Engineering)
The RFC (Request for Comments) process, in software engineering, is a structured practice for proposing, documenting, and gathering feedback on significant technical decisions through a written document that is circulated to relevant…
Definition
The RFC (Request for Comments) process, in software engineering, is a structured practice for proposing, documenting, and gathering feedback on significant technical decisions through a written document that is circulated to relevant stakeholders before implementation begins.
Overview
The RFC process originated in the early Internet Engineering Task Force (IETF) standards process, where 'Request for Comments' documents were used to propose and iterate on Internet protocols, and the practice has since been widely adopted inside individual engineering organizations as a way to make significant technical decisions more transparent, deliberate, and well-documented than an informal hallway conversation or a decision made unilaterally by whoever happens to be building the feature. An RFC document typically follows a semi-standard structure: a statement of the problem or motivation, the proposed solution, alternatives that were considered and why they were rejected, the scope and non-goals of the proposal, and open questions the author is still working through. The document is then shared broadly — often via a pull request, wiki, or dedicated internal tool — allowing engineers across the organization, not just the immediate team, to comment, raise concerns, or suggest alternatives during a defined review period before the proposal is finalized. The process serves several purposes beyond simply gathering feedback: it forces the author to think through a proposal rigorously enough to write it down clearly, which often surfaces gaps or flawed assumptions before any code is written; it creates a durable, searchable record of why a significant decision was made, which is valuable when questioned or revisited months or years later; and it distributes awareness of significant technical changes across the organization, reducing the chance that a major decision surprises teams it affects. RFCs are commonly used for decisions with a large blast radius or long-term consequences — introducing a new core technology, significant API changes affecting other teams, deprecating a widely used system, or major architectural shifts — while smaller, contained decisions are typically left to normal team-level judgment without requiring the overhead of a full RFC. Many organizations pair the RFC process with a defined approval mechanism, such as sign-off from an architecture review board or a set of designated technical stakeholders, to formally close out the review period and move the proposal toward implementation.
Key Concepts
- Structured written proposal process for significant technical decisions
- Originated from the IETF's Request for Comments Internet standards process
- Typically documents motivation, proposed solution, alternatives, and open questions
- Circulated broadly for feedback during a defined review period
- Forces rigorous thinking by requiring the proposal to be written down clearly
- Creates a durable, searchable record of why a decision was made
- Reserved for decisions with large blast radius or long-term consequences
- Often paired with a formal approval step, such as architecture review board sign-off