Requests for Comments (RFCs) are a formal process for proposing, discussing, and deciding on significant technical changes that affect multiple teams or systems. This template provides a structured format with metadata (status, author, reviewers, decision date), a problem statement, proposed solution, impact analysis, and a discussion section. It is designed for cross-team proposals that need broad input and formal approval.
When to Write an RFC
Not every change needs an RFC. Write one when the change affects multiple teams, introduces a new technology or pattern, has significant performance or cost implications, or is irreversible. RFCs are about building consensus before committing to a direction, so save them for decisions that truly benefit from broad discussion.
RFC Lifecycle
The template supports a clear lifecycle for the proposal.
- Draft: Author is writing the RFC, not yet ready for review
- In Review: RFC is published and open for comments from all stakeholders
- Accepted: Reviewers have approved the proposal and implementation can begin
- Rejected: The proposal was not approved, with reasons documented
- Superseded: A newer RFC has replaced this one
Structuring Your Proposal
The most important sections are the problem statement (why this change is needed) and the proposed solution (what we will do). Be explicit about trade-offs, migration plans for existing systems, and the expected impact on other teams. The stronger your alternatives analysis, the more confident reviewers will be in your recommendation.