RFC 流程
RFC（征求意见）流程旨在为新功能进入项目提供一致且受控的路径。它有助于确保新功能经过精心设计、良好实现和充分测试，并且不会与项目的总体方向和范围冲突。
目标
许多更改（例如错误修复和文档改进）可以通过常规的 GitHub 拉取请求工作流程来实现和审查。然而，一些更改被认为是“实质性的”，我们要求这些更改需要经过设计流程、征集社区意见并获得 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 的“倡导者”（champion）。倡导者将与 RFC 作者协作，并在整个 RFC 流程中提供协助。
3. 状态：已接受/已拒绝
最终，团队将决定该 RFC 是否适合纳入 Storybook。另一方面，在公开讨论结束后，团队可能会拒绝某个 RFC，并对拒绝的理由进行总结说明。
实施已接受的 RFC
RFC 的作者没有义务实现它。当然，RFC 作者（就像任何其他开发者一样）在 RFC 被接受后，欢迎发布实现供审查。然而，请注意，“已接受”状态并不表示优先级，也不表示正在积极开发中。
如果您对实现一个“活跃的”RFC 感兴趣，但无法确定是否有人正在处理，请随时询问（例如，在相关 issue 上留言）。
此 RFC 流程在很大程度上借鉴了 Rust 和 Gatsby 的 RFC 流程。
了解更多关于贡献 Storybook 的信息