RFC Process

Author(s):

Gordo Lowrey - Architect

Date:

February 2024

Summary

This document outlines a proposed process for documenting proposals, discussing ideas, and making decisions in a structured, transparent, and collaborative manner.

What is an RFC?

An RFC, or Request for Comments, is a document used to propose a new idea or significant change to existing systems or processes. It invites feedback and discussion from relevant stakeholders, ensuring diverse perspectives are considered in decision-making.

Purpose of an RFC Process

• Collaboration and Transparency: Facilitate open discussions and collective decision-making.
• Documentation: Provide a formal record of proposals, considerations, and decisions.
• Standardization: Ensure consistency and clarity in how new ideas and changes are proposed and evaluated.
• Integration with ADRs: Linking RFCs with Architectural Decision Records (ADRs) for comprehensive documentation and traceability of decisions.

Principles of an RFC Process

• Open Participation: All team members are encouraged to contribute to an RFC process, regardless of their role or seniority.
• Constructive Feedback: Discussions should focus on constructive and objective feedback aimed at improving the proposal.
• Respect and Inclusivity: Embrace diverse perspectives and treat all contributions with respect and serious consideration.
• Iterative Improvement: RFCs are living documents, subject to revision and improvement as new information and feedback are received.

RFC Process

1. Drafting: Author drafts an RFC document outlining the proposal, rationale, impact, and technical details.
2. Request for Comments: An RFC document is shared with relevant stakeholders for comments and feedback.
3. Discussion and Revision: The proposal is discussed, and revisions are made based on feedback.
4. Reference Related ADRs: If the RFC leads to or is related to an architectural decision, reference the corresponding ADRs for context and completeness.
5. Final Review: The revised proposal undergoes a final review by a decision-making body or stakeholders.
6. Approval or Rejection: The proposal is either approved, requiring further action or implementation (and subsequent documentation in an ADR, if relevant), or rejected, with reasons provided.

RFC Document Structure

• Title: Clearly and concisely reflects the proposal.
• Author: Individual or team responsible for the proposal.
• Date: Date of document creation.
• Summary: Brief overview of the proposal.
• Current Status: Description of the current system or process and its limitations.
• Proposed Change: Detailed explanation of the proposed change or new idea.
• Technical Details: In-depth technical specifics, if applicable.
• Impact Analysis: Evaluation of the potential impacts and benefits.
• Alternatives Considered: Other options or solutions considered.
• Related ADRs: Reference any ADRs that are directly related to the RFC.
• Appendices: Supplementary information, data, or references.

Version Control and Tracking

• Git Repository: All RFCs are stored and tracked in a version-controlled Git repository.
• Branching Strategy: Use feature branches for individual RFCs to facilitate discussion and revision.
• Commit Messages: Clear and descriptive commit messages to document the evolution of the proposal.
• Merge Requests: Finalized RFCs are merged into the main branch for record keeping and reference.

Appendices

Appendix A: Process Flow Diagram

@startuml
start
:Draft RFC Document;
:Include Proposal, Rationale, Impact, and Technical Details;
:Share RFC for Comments and Feedback;
repeat
  :Collect Feedback from Stakeholders;
  :Revise RFC Based on Feedback;
  backward: Is there more feedback?;
repeat while (More Feedback?)
-> No more feedback;
:Final Review by Decision-Making Body or Stakeholders;
if (RFC Approved?) then (yes)
  :RFC Approved for Implementation;
  :Document and Implement Changes;
else (no)
  :RFC Rejected;
  :Provide Reasons for Rejection;
endif
:Archive RFC in Version-Controlled Repository;
stop
@enduml