RFC 流程
RFC（Request for Comment，征求意见稿）流程旨在为新功能进入项目提供一个一致且受控的路径。它有助于确保新功能设计良好、实现良好、测试良好，并且不与项目的整体方向和范围发生冲突。
目标
许多更改，例如 bug 修复和文档改进，可以通过正常的 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 的信息