Design System RFC

Design system RFCs (Request for Comments) are formal proposals for significant changes that solicit community input before decisions are finalized. RFCs enable participatory decision-making for changes with broad impact, balancing community voice with practical governance.

What Is an RFC Process

An RFC process formalizes how major changes are proposed, discussed, and decided. A proposer writes a detailed document describing the proposed change. The community reviews and comments. Discussion refines the proposal. A decision-maker evaluates input and decides. The outcome is documented.

RFCs suit decisions with significant, broad impact: new architectural patterns, breaking API changes, governance modifications, or major new capabilities. Routine changes do not warrant RFC overhead. The process is reserved for changes where community input is particularly valuable.

How to Implement RFC Processes

RFC templates structure proposal content. Templates typically request problem description, proposed solution, alternatives considered, impact analysis, and implementation approach. Structured content enables consistent evaluation.

Discussion forums provide space for community input. GitHub issues, discussion threads, or dedicated RFC tools enable asynchronous input from interested parties. Moderation keeps discussion constructive.

Review periods allow adequate time for input. Too short periods miss input from busy stakeholders; too long periods delay decisions. Typical periods range from one to four weeks depending on proposal significance.

Decision processes convert discussion into outcomes. Decision-makers (maintainers, committees, or designated authorities) evaluate input and determine whether to accept, reject, or request modifications. Decisions should be explained.

Documentation archives RFCs and their outcomes. Accepted RFCs become reference documentation for implemented changes. Rejected RFCs explain why proposals were not adopted. Archives inform future similar proposals.

Key Considerations

• RFCs require investment; reserve for genuinely significant changes
• Community participation varies; not all RFCs receive extensive input
• RFCs slow decision-making but may improve decision quality
• Clear expectations about what RFCs cover prevents confusion
• RFC outcomes should influence actual development

Common Questions

When should design systems use RFCs?

RFCs fit changes with broad impact: breaking changes affecting many users, significant new capabilities, governance modifications, or architectural decisions. They are less appropriate for routine additions, bug fixes, or changes affecting few users. Judgment determines which changes warrant RFC treatment.

How binding are RFC decisions?

Binding nature depends on governance. Some organizations treat accepted RFCs as committed plans. Others use RFCs for input that informs but does not mandate decisions. Clear expectations about RFC authority prevents confusion about what acceptance means.

Summary

Design system RFCs formalize community input on significant decisions through structured proposals, discussion periods, and documented outcomes. Effective RFC processes include clear templates, accessible discussion forums, adequate review periods, transparent decision-making, and comprehensive archives. RFCs enable participatory governance while maintaining practical decision efficiency.