RFC 流程

RFC（征求意见）流程旨在为新功能进入项目提供一致且受控的路径。它有助于确保新功能设计良好、实现良好、测试良好，并且不会与项目的整体方向和范围相冲突。

¥The RFC (Request for Comment) process is intended to provide a consistent and controlled path for new features to enter the project. It helps ensure that new features are well-designed, well-implemented, and well-tested, and they do not conflict with the project's overall direction and scope.

目标

¥Goal

许多更改（例如错误修复和文档改进）都可以通过正常的 GitHub 拉取请求工作流程来实现和审查。然而，一些变化被认为是“实质性的”，我们要求这些变化经过设计过程，征求社区意见，并在 Storybook 核心团队中达成共识。

¥Many changes, such as bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow. Some changes, however, are considered “substantial”, and we ask that these undergo a design process, solicit community input, and reach a consensus among the Storybook core team.

RFC（征求意见）流程的目的是：

¥The purpose of the RFC (Request for Comment) process is to:

• 提供一个透明的系统来提出新功能想法。

  ¥Provide a transparent system for proposing new feature ideas.

• 建立一个可靠且规范的流程，将新功能引入项目。

  ¥Establish a reliable and well-regulated process for introducing new features into the project.

• 为社区提供一种参与开发新功能的方式。

  ¥Provide a way for the community to participate in developing new features.

“功能请求”与“RFC”

¥“Feature Request” vs. “RFC”

功能请求是 Storybook 用户为项目建议新功能或增强功能的一种直接且相对非正式的方式。虽然功能请求可以提供有价值的见解和想法，但它们通常不涉及深入的设计过程或需要核心团队达成共识。功能请求通常可以讨论，并且可能会或可能不会根据受欢迎程度、可行性和与项目目标的一致性等因素实现。

¥A feature request is a straightforward and relatively informal way for Storybook users to suggest a new feature or enhancement to the project. While feature requests can provide valuable insights and ideas, they typically do not involve an in-depth design process or require consensus among the core team. Feature requests are usually open to discussion and may or may not be implemented based on factors like popularity, feasibility, and alignment with the project's goals.

另一方面，RFC 是一个更正式和结构化的过程，用于对项目提出重大更改或添加。它涉及遵循一组定义的步骤，以确保所提议的功能或修改得到适当的考虑、设计和反馈。RFC 通常用于对项目产生重大影响的更改，例如引入新的 API 功能、删除现有功能或建立新的使用约定。RFC 流程旨在促进讨论，​​收集更广泛受众的反馈，并在将提议的变更整合到项目中之前在核心团队中达成共识。与常规功能请求相比，接受的 RFC 更有可能被实现。

¥On the other hand, an RFC is a more formalized and structured process for proposing substantial changes or additions to the project. It involves following a defined set of steps to ensure that the proposed feature or modification receives proper consideration, design, and feedback. RFCs are typically used for changes that significantly impact the project, such as introducing new API functionality, removing existing features, or establishing new usage conventions. The RFC process aims to foster discussions, gather feedback from a wider audience, and reach consensus among the core team before integrating the proposed change into the project. Accepted RFCs are more likely to be implemented than regular feature requests.

RFC 生命周期

¥The RFC lifecycle

1. Status: Proposed

在 “RFC”类别 中打开一个新的 GitHub 讨论。按照说明填写表格。

¥Open a new GitHub discussion in the “RFC” category. Fill out the form as instructed.

细节很重要：没有提出令人信服的动机、缺乏对设计影响的理解或对缺点或替代方案不诚实的 RFC 往往会受到冷遇。

¥Details matter: RFCs that do not present convincing motivation, demonstrate a lack of understanding of the design's impact, or are disingenuous about the drawbacks or alternatives tend to be poorly received.

2. Status: In review

RFC 往往会在此阶段停留一段时间，让社区和核心团队成员有时间权衡。在此期间，RFC 的作者应准备好修改提案，整合反馈并建立共识。获得广泛支持的 RFC 比没有收到任何评论的 RFC 更有可能取得进展。

¥RFCs tend to remain in this stage for a while, giving the community and core team members time to weigh in. During this period, the author of an RFC should be prepared to revise the proposal, integrate feedback, and build consensus. RFCs that have broad support are much more likely to make progress than those that don't receive any comments.

每周，Storybook 核心团队都会举行一次分类会议，以审查开放的 RFC，这是会议议程的一部分。该事件在 Storybook Discord 中公开安排，并在 Storybook Discord 的 Watercooler 通道 中举行。我们邀请 RFC 作者和感兴趣的社区成员参与并参与对 RFC 的更详细讨论。如果核心团队成员认为有必要，他们将被指定为 RFC 的 "champion"。冠军将与 RFC 作者合作并在整个 RFC 过程中为他们提供帮助。

¥Every week, the Storybook core team conducts a triage meeting to review open RFCs as part of the meeting's agenda. The event is publicly scheduled in the Storybook Discord and held in the Storybook Discord's Watercooler channel. We invite the RFC author(s) and interested members of the community to participate and engage in a more detailed discussion of the RFC. If a core team member deems it necessary, they will be assigned as the "champion" of the RFC. The champion will collaborate with the RFC author and assist them throughout the RFC process.

3. Status: accepted/rejected

最终，团队将决定 RFC 是否是 Storybook 的候选者。另一方面，在公开讨论结束并发表总结拒绝理由的评论后，团队可能会拒绝 RFC。

¥Eventually, the team will decide whether the RFC is a candidate for inclusion in Storybook. On the other hand, an RFC may be rejected by the team after a public discussion has settled and comments have been made summarizing the rationale for rejection.

实现已接受的 RFC

¥Implementing an accepted RFC

RFC 的作者没有义务实现它。当然，在 RFC 被接受后，欢迎 RFC 作者（与任何其他开发者一样）发布实现以供审查。但是，请注意，“已接受”状态并不表示优先级，也不表示是否正在积极处理。

¥The author of an RFC is not obligated to implement it. Of course, the RFC author (like any other developer) is welcome to post an implementation for review after the RFC has been accepted. However, note that the “accepted” status does not indicate priority nor whether it’s being actively worked on.

如果你有兴趣实现 "active" RFC，但无法确定是否有其他人正在处理它，请随时询问（例如，通过在相关问题上发表评论）。

¥If you are interested in implementing an "active" RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g., by leaving a comment on the associated issue).

此 RFC 流程从 Rust 和 Gatsby 的 RFC 流程中汲取了大量灵感。

¥This RFC process took heavy inspiration from the RFC processes from Rust and Gatsby.

了解有关为 Storybook 做贡献的更多信息

¥Learn more about contributing to Storybook

• 编写功能请求的 RFC 流程

  ¥RFC process for authoring feature requests

• 代码 用于功能和错误修复

  ¥Code for features and bug fixes

• 框架 用于开始使用新框架

  ¥Frameworks to get started with a new framework

• 文档 用于文档改进、拼写错误和澄清

  ¥Documentation for documentation improvements, typos, and clarifications

• 示例 提供有关新代码片段和示例

  ¥Examples for new snippets and examples