Request for Changes (RFC) Process¶

Overview¶

A Request for Changes (RFC) is a structured proposal process used to introduce, discuss, and approve significant technical or architectural changes in a project or organization. The RFC process provides a transparent, reviewable, and documented path for evolving systems, APIs, or policies while ensuring stakeholder alignment and technical rigor.

RFC processes are commonly used in open-source projects, platform teams, and large engineering organizations to coordinate changes that affect multiple components, contributors, or external users.

Typical use cases include:

(1) Introducing new features or APIs (2) Changing architecture or core abstractions (3) Deprecating or removing existing functionality (4) Defining policies, conventions, or technical standards

The scope of an RFC process is generally project-wide or organization-wide and is applicable to any change that requires consensus, documentation, or long-term maintainability.

Core Concepts and Components¶

RFC Roles and Responsibilities¶

RFC Document Structure¶

While the exact structure varies by project, most RFCs contain the following sections:

Change Types Typically Requiring an RFC¶

This section lists common categories of changes that typically require an RFC. These changes usually have cross-team impact, long-term architectural consequences, or affect public interfaces.

Execution Flow¶

The RFC workflow defines how a proposal moves from idea to accepted or rejected change. This flow is triggered when a contributor identifies a change that affects public interfaces, architecture, or project policies, and it results in a documented decision and implementation plan.

(1) Identify the need for a change

• Author determines that the change is significant enough to require formal review.

(2) Draft the RFC document

• Author prepares the proposal using the project’s RFC template.
• The document includes motivation, design, and trade-offs.

(3) Submit the RFC for review

• The proposal is opened as a pull request or similar review artifact.
• Reviewers and stakeholders provide feedback.

(4) Discussion and iteration

• Author updates the RFC based on comments and technical concerns.
• Design alternatives may be explored.

(5) Decision by maintainers

• Maintainers approve, request further changes, or reject the proposal.
• The decision is documented in the RFC thread.

(6) Merge or close the RFC

• Accepted RFCs are merged into the repository.
• Rejected RFCs are closed with documented reasoning.

(7) Implementation phase

• Author or assigned contributors implement the approved design.
• Implementation typically references the accepted RFC.

Practical Usage Guidelines¶

When to Create an RFC¶

Use the RFC process when:

(1) The change modifies public APIs or protocols (2) Multiple teams or subsystems are affected (3) The decision has long-term architectural impact (4) The change introduces new abstractions or conventions (5) A standard tool or package is being promoted, replaced, or deprecated across the organization

If the impact of a change is unclear, perform the following checks:

(1) Determine whether the change affects public or shared interfaces.
(2) Evaluate whether rollback would be difficult after deployment.
(3) Check if multiple teams or components depend on the behavior.
(4) If any condition is true, create an RFC before implementation.

Author Responsibilities¶

(1) Clearly define the problem and motivation (2) Provide a technically feasible design (3) Document trade-offs and alternatives (4) Respond to reviewer feedback promptly

Before submitting an RFC:

(1) Confirm the problem statement is precise and measurable.
(2) Ensure the design is implementable with current constraints.
(3) Document at least one alternative approach.
(4) Identify affected components and stakeholders.

Maintainer Responsibilities¶

(1) Ensure proposals align with project goals (2) Facilitate constructive discussion (3) Make timely decisions to avoid process stalls (4) Document acceptance or rejection reasons

Inspiration¶

The RFC model is inspired by engineering practices used in large technology organizations and mature open-source communities. These organizations use RFC-style processes to provide a centralized, transparent, and reviewable mechanism for making technical decisions that affect multiple teams or long-term architecture.

Common characteristics of these processes include:

(1) A single repository or directory that stores all accepted proposals (2) Public discussion threads for technical review and feedback (3) Documented decision history for future reference (4) Clear ownership and approval mechanisms

Examples of organizations and projects using RFC-style processes:

(1) Rust language project — uses RFCs to evolve the language and standard library (2) PyTorch — uses RFCs for core framework changes and APIs (3) Kubernetes — uses KEPs (Kubernetes Enhancement Proposals) as a similar model (4) React — uses RFCs for major API and architectural decisions

When introducing an RFC process in an organization:

(1) Define what types of changes require an RFC.
(2) Create a standard RFC template.
(3) Establish clear maintainer or decision authority.
(4) Store all RFCs in a centralized, version-controlled repository.

Limitations and Edge Cases¶

(1) Process overhead

• RFCs introduce review cycles that may slow small or urgent changes.

(2) Ambiguous scope

• Teams may disagree on whether a change requires an RFC.

(3) Stalled proposals

• Without clear ownership, RFCs may remain unresolved.

(4) Implementation drift

• Approved RFCs may diverge from the final implementation if not enforced.

(5) Consensus vs. decision authority

• Projects must define whether decisions are consensus-based or maintainer-driven.

Do not create RFCs for:

(1) Minor bug fixes
(2) Localized refactoring
(3) Changes with no external impact

Excessive RFC usage can slow development without improving decision quality.

Reference¶

(1) https://github.com/pytorch/rfcs (2) https://github.com/rust-lang/rfcs