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 的“负责人”。负责人将与 RFC 作者合作并在整个 RFC 流程中为其提供帮助。
3. 状态：已接受/已拒绝
最终，团队将决定 RFC 是否适合纳入 Storybook。另一方面，在公开讨论结束后并对拒绝的理由进行总结后，团队可能会拒绝 RFC。
实施已接受的 RFC
RFC 的作者没有义务实施它。当然，RFC 作者（像任何其他开发人员一样）欢迎在 RFC 被接受后发布实现以供审查。但是，请注意，“已接受”状态并不表示优先级，也不表示它正在积极开发中。
如果您有兴趣实施一个“活跃”的 RFC，但无法确定是否有人已经在处理它，请随时提问（例如，在相关问题上发表评论）。
此 RFC 流程大量借鉴了Rust和Gatsby的 RFC 流程。
详细了解如何为 Storybook 贡献代码