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 核心团队都会举行一次 triage 会议，以审查作为会议议程一部分的开放 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 的更多信息