最近參與一個從零開始的開源專案，開完幾次會議後正式分組準備進入第一階段的功能實作，由於之前對 RFC 流程很有興趣，就在 Discord 群裡推廣了下 RFC 流程。
TL;DR: 在沒有實際產品前的開發階段不適合使用 RFC，比較適合在有產品的開源專案裡使用，以及大家有共識的 work flow 才是好的 work flow。
什麼是 RFC#
RFC (Request for Comments) 又稱意見請求、意見徵求，很多開源專案都能看到有自己的 RFC work flow
Rust
Bytecodealliance
Reactjs
VueJS
Ethereum
在開源專案裡執行RFC driven development的好處是任何改動可以透明的被討論與取得共識，最後在根據定義好的 RFC 文件去實作改動。
自己也是第一次實作 RFC 流程，參考了幾篇流程文章後，在 Discord 中與大家分享 (推坑 ，團隊都對 RFC 流程很有興趣但不知道該怎麼執行，與有在執行 RFC 的朋友討論跟其他公司的流程分享，最後起草了一份 template 讓大家來討論。
RFC driven development
Gatsby RFC process
起草的 Discussion#
Why use RFC#
The "RFC" (request for comments) process is intended to provide a consistent and controlled path for changes to product (such as new features) so that all member can be confident about the direction of the project.
Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.
Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the product community.
RFC template#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC: [Your Topic Title]
## Summary
A short, concise description of the feature or change proposed. This should be used to provide a high-level understanding of the proposal.
## Motivation
Explain the context and why you're making this proposal. What is the problem that needs solving? What use cases does it support? What is the expected outcome?
## Proposal Sketch / Detailed Design
For early-stage RFCs, provide at least a sketch of how to address the problem to help center the discussion on a concrete starting point.
For more detailed RFCs, this section should contain enough information for others to understand and evaluate the proposal. It should cover the key points and design considerations, including a discussion of the architecture, an explanation of design details, and a reasoning behind your choices.
### Components Diagram
Provide a components diagram if possible.
### Sequence Diagram
Provide a sequence diagram if possible.
### Class Diagram
Provide a class diagram if it adds value and understanding to the proposal.
### OpenAPI Spec
Include an OpenAPI specification if the proposal involves an API.
## Rationale and Alternatives
Discuss the reasons for choosing the proposed design along with the trade-offs it involves. Moreover, describe the alternatives that have been considered and why they were discarded.
## Open Questions
Discuss aspects of the design which are still unresolved or require further discussion. It can be divided into two sections, questions that you hope to answer before finalizing the RFC and questions that would be resolved during the implementation phase.
## Drawbacks
What are the potential downsides of this proposal? What are the implications for users or existing systems?
## Adoption Strategy
If the proposal gets accepted, describe the path for adoption in your current system. What is the integration strategy?
## Action Plans
List the key actions that need to be completed once the RFC is approved. Also include dates for discussions, reviews, and approvals if possible.
- [ ] Design discussion at YYYY-MM-DD
- [ ] RFC review at YYYY-MM-DD
- [ ] RFC approval at YYYY-MM-DD
RFC Draft template#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC Title
## Summary
Provide a brief single-paragraph explanation of the change.
## Motivation
Describe the motivation behind this RFC. What is the current state, and why is this change beneficial? What use cases does it support? What is the expected outcome?
## Proposal Sketch
At this stage, the proposal does not need to be fully formed. A sketch is enough to center the discussion. Detail the proposed solution at a high level. If any new concepts or terms are introduced, define them here.
## Open Questions
What parts of the design are still unclear or need resolving? What do you hope to resolve through discussion with the community before progressing this RFC to a full proposal?
## Trade-offs
What are the potential trade-offs or impacts of this proposal? How does it affect other areas of the system, if any?
## Unresolved Questions
What parts of the proposal are TBD (to be decided)?
Discuss RFC flow#
-
Discussion to RFC: Start with an open discussion thread in the repo's Discussion section. After reaching a consensus, the author of the thread drafts an RFC. Once the RFC is ready, development can commence, ending with a Pull Request.
-
Draft RFC to Pull Request: The proposer initiates the process by creating a draft RFC and submitting it as a draft Pull Request. After discussions and refinements, the Pull Request is formally reviewed and then either merged or closed.
-
Combined Approach: Begin with preliminary discussions in the Discussion section. Once the idea is somewhat clear and specific, move to drafting an RFC and submitting it as a Pull Request for in-depth discussions and formal review. This combines the open nature of discussions with the structured format of the RFC and Pull Request process.
結論#
剛前面有提到，我參與的是從零開始設計討論的開源專案，我們一開始的開會模式是使用 FigmaJam 做產品發想與討論，而後面則是使用 google doc 紀錄了需要開發的功能，由於產品屬於準備進入實作時期，大家討論的點是在 spec 還未正式定案加上已有 google doc 版本的 spec 和 UIUX 對於 github 的操作流程不一定熟悉等的因素，我們做了一次投票，最終大家決定先以 google doc + FigmaJam 為主要開發文件，主要是開發初期要做好 RFC 文件對於大家都有難度，也會使產品的開發週期變得更長；最終大家有共識的 work flow 才是最適合的 work flow。
如果覺得我的文章不錯，歡迎買杯咖啡給我#
