最近參與一個從零開始的開源專案，開完幾次會議後正式分組準備進入第一階段的功能實作，由於之前對 RFC 流程很有興趣，就在 Discord 群裡推廣了下 RFC 流程。
TL;DR: 在沒有實際產品前的開發階段不適合使用 RFC，比較適合在有產品的開源專案裡使用，以及大家有共識的工作流程才是好的工作流程。
什麼是 RFC#
RFC (Request for Comments) 又稱意見請求、意見徵求，很多開源專案都能看到有自己的 RFC 工作流程
Rust
Bytecodealliance
Reactjs
VueJS
Ethereum
在開源專案裡執行RFC 驅動開發的好處是任何改動可以透明的被討論與取得共識，最後在根據定義好的 RFC 文件去實作改動。
自己也是第一次實作 RFC 流程，參考了幾篇流程文章後，在 Discord 中與大家分享 (推坑 ，團隊都對 RFC 流程很有興趣但不知道該怎麼執行，與有在執行 RFC 的朋友討論跟其他公司的流程分享，最後起草了一份模板讓大家來討論。
RFC 驅動開發
Gatsby RFC 流程
起草的討論#
為什麼使用 RFC#
"RFC"（意見請求）流程旨在為產品的變更（例如新功能）提供一致且受控的路徑，以便所有成員都能對項目的方向充滿信心。
許多變更，包括錯誤修復和文檔改進，可以通過正常的 GitHub 拉取請求工作流程來實施和審查。
然而，有些變更是 "實質性的"，我們要求這些變更經過一定的設計流程，並在產品社區中達成共識。
RFC 模板#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC: [您的主題標題]
## 摘要
對所提議的功能或變更的簡短、簡潔的描述。這應用於提供對提案的高層次理解。
## 動機
解釋背景以及為什麼您會提出這個提案。需要解決的問題是什麼？支持哪些使用案例？預期的結果是什麼？
## 提案草圖 / 詳細設計
對於早期階段的RFC，至少提供一個草圖來解決問題，以幫助將討論集中在具體的起點上。
對於更詳細的RFC，這一部分應包含足夠的信息，以便其他人理解和評估提案。它應涵蓋關鍵點和設計考量，包括架構的討論、設計細節的解釋，以及您選擇背後的理由。
### 組件圖
如果可能，提供組件圖。
### 序列圖
如果可能，提供序列圖。
### 類圖
如果這對提案增加價值和理解，則提供類圖。
### OpenAPI規範
如果提案涉及API，請包含OpenAPI規範。
## 理由和替代方案
討論選擇所提議設計的原因以及它所涉及的權衡。此外，描述考慮過的替代方案以及為什麼它們被放棄。
## 開放問題
討論設計中仍未解決或需要進一步討論的方面。可以分為兩個部分，您希望在最終確定RFC之前回答的問題，以及在實施階段將解決的問題。
## 缺點
這個提案的潛在缺點是什麼？對用戶或現有系統有什麼影響？
## 採納策略
如果提案獲得接受，請描述在當前系統中採納的路徑。整合策略是什麼？
## 行動計劃
列出RFC獲得批准後需要完成的關鍵行動。如果可能，還包括討論、審查和批准的日期。
- [ ] 設計討論於YYYY-MM-DD
- [ ] RFC審查於YYYY-MM-DD
- [ ] RFC批准於YYYY-MM-DD
RFC 草稿模板#
---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC標題
## 摘要
提供對變更的簡短單段解釋。
## 動機
描述這個RFC背後的動機。當前狀態是什麼，為什麼這個變更是有益的？支持哪些使用案例？預期的結果是什麼？
## 提案草圖
在這個階段，提案不需要完全形成。草圖足以集中討論。高層次地詳細描述所提議的解決方案。如果引入了任何新概念或術語，請在此定義它們。
## 開放問題
設計中哪些部分仍不清楚或需要解決？您希望通過與社區的討論解決哪些問題，然後再將此RFC推進到完整提案？
## 權衡
這個提案的潛在權衡或影響是什麼？如果有的話，它如何影響系統的其他領域？
## 未解決問題
提案的哪些部分尚待決定（待定）？
討論 RFC 流程#
-
討論到 RFC：在 repo 的討論部分開始一個公開討論主題。在達成共識後，主題的作者起草 RFC。一旦 RFC 準備好，開發可以開始，並以拉取請求結束。
-
草稿 RFC 到拉取請求：提議者通過創建草稿 RFC 並將其提交為草稿拉取請求來啟動過程。在討論和改進後，拉取請求正式審查，然後合併或關閉。
-
綜合方法：在討論部分開始初步討論。一旦想法變得相對清晰和具體，便開始起草 RFC 並將其提交為拉取請求，以進行深入討論和正式審查。這結合了討論的開放性和 RFC 及拉取請求流程的結構化格式。
結論#
剛前面有提到，我參與的是從零開始設計討論的開源專案，我們一開始的開會模式是使用 FigmaJam 做產品發想與討論，而後面則是使用 google doc 紀錄了需要開發的功能，由於產品屬於準備進入實作時期，大家討論的點是在 spec 還未正式定案加上已有 google doc 版本的 spec 和 UIUX 對於 github 的操作流程不一定熟悉等的因素，我們做了一次投票，最終大家決定先以 google doc + FigmaJam 為主要開發文件，主要是開發初期要做好 RFC 文件對於大家都有難度，也會使產品的開發週期變得更長；最終大家有共識的工作流程才是最適合的工作流程。
如果覺得我的文章不錯，歡迎買杯咖啡給我#
