RFC 流程
RFC（徵求意見）流程旨在為新功能加入專案提供一致且受控制的路徑。它有助於確保新功能經過良好設計、良好實作和良好測試，並且它們不會與專案的整體方向和範圍衝突。
目標
許多變更，例如錯誤修正和文件改進，可以透過正常的 GitHub pull request 工作流程實作和審閱。然而，某些變更被視為「重大」，我們要求這些變更經過設計流程、徵求社群意見，並在 Storybook 核心團隊中達成共識。
RFC（徵求意見）流程的目的是
- 提供一個透明的系統，以提出新功能想法。
- 建立一個可靠且管理良好的流程，將新功能引入專案。
- 提供一個讓社群參與開發新功能的方式。
「功能請求」與「RFC」
功能請求是 Storybook 使用者建議專案新功能或增強功能的直接且相對非正式的方式。雖然功能請求可以提供有價值的見解和想法，但它們通常不涉及深入的設計流程，也不需要核心團隊達成共識。功能請求通常開放討論，可能會或可能不會根據諸如熱門程度、可行性以及與專案目標的一致性等因素來實作。
另一方面，RFC 是一個更正式和結構化的流程，用於提出對專案的重大變更或新增。它涉及遵循一組定義的步驟，以確保所建議的功能或修改獲得適當的考量、設計和回饋。RFC 通常用於對專案產生重大影響的變更，例如引入新的 API 功能、移除現有功能或建立新的使用慣例。RFC 流程旨在促進討論、收集更廣泛受眾的回饋，並在將建議的變更整合到專案之前，在核心團隊中達成共識。與一般功能請求相比，被接受的 RFC 更有可能被實作。
RFC 生命周期
1. 狀態：已提案
在「RFC」類別中開啟新的 GitHub 討論。按照指示填寫表單。
細節很重要：沒有提出令人信服的動機、顯示對設計影響缺乏理解或對缺點或替代方案不誠實的 RFC，往往會受到負評。
2. 狀態：審閱中
RFC 往往會在這個階段停留一段時間，讓社群和核心團隊成員有時間權衡。在此期間，RFC 的作者應準備好修改提案、整合回饋並建立共識。獲得廣泛支持的 RFC 比沒有收到任何評論的 RFC 更有可能取得進展。
每週，Storybook 核心團隊都會舉行分類會議，以審閱開放的 RFC 作為會議議程的一部分。該活動會公開排程在Storybook Discord中，並在Storybook Discord 的 Watercooler 頻道中舉行。我們邀請 RFC 的作者和感興趣的社群成員參與，並針對 RFC 進行更詳細的討論。如果核心團隊成員認為有必要，他們將被指派為 RFC 的「擁護者」。擁護者將與 RFC 作者合作，並在整個 RFC 流程中協助他們。
3. 狀態：已接受/已拒絕
最終，團隊將決定該 RFC 是否為 Storybook 的候選加入項目。另一方面，在公開討論結束並提出評論總結拒絕理由後，團隊可能會拒絕某個 RFC。
實作已接受的 RFC
RFC 的作者沒有義務實作它。當然，RFC 作者（如同任何其他開發人員）可以在 RFC 被接受後提交實作以供審查。但是，請注意，「已接受」的狀態並不表示優先順序，也不表示它是否正在積極開發中。
如果您有興趣實作一個「啟用中」的 RFC，但無法確定是否有人已經在處理它，請隨時提問（例如，在相關議題上留下評論）。
此 RFC 流程的靈感主要來自 Rust 和 Gatsby 的 RFC 流程。
深入了解如何為 Storybook 做出貢獻