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 的資訊