RFC 流程
什么是 RFC 流程？
许多更改，包括 bug 修复和文档改进，都可以通过常规的 GitHub pull request 工作流程来实施和评审。
但是，一些更改是“重大的”，我们要求这些更改通过一些设计过程，并在 Gatsby 核心团队中达成共识。
“RFC”（征求意见稿）流程旨在为新功能进入项目提供一个一致且可控的路径。
何时遵循此流程
如果您打算对 Gatsby 或其文档进行“重大”更改，则应考虑使用此流程。受益于 RFC 的一些示例包括：
- 一项新的功能，该功能会创建新的 API 表面积，并且在引入时需要功能标志。
- 移除已作为发布频道一部分发布的功能。
- 引入新的习惯用法或约定，即使它们不包含对 Gatsby 本身的代码更改。
RFC 流程是您在提案成为 Gatsby 已发布版本的一部分之前，让更多人关注您的提案的好机会。很多时候，即使看似“显而易见”的提案，在更广泛的利益相关者有机会发表意见后，也能得到显著改进。
RFC 流程也有助于鼓励在设计过程中讨论拟议功能，并在设计更容易更改时（在设计完全实现之前）将其纳入重要约束。
某些更改不需要 RFC
- 重写、重新组织或重构添加或删除警告
- 严格改善客观、数值质量标准的添加（加速、更好的浏览器支持）
- 仅可能被 Gatsby 的其他实现者注意到的添加，对 Gatsby 的用户来说是不可见的。
流程是什么
简而言之，要为 Gatsby 添加一项主要功能，通常需要先在 GitHub 上发起一个讨论。此时，RFC 就“活跃”起来了，可以开始实施，目标是最终将其合并到 Gatsby 中。
将 RFC 模板复制到剪贴板
填写 RFC。请仔细注意细节：未能提出令人信服的理由、未能证明对设计影响的理解，或者对缺点或替代方案不够坦诚的 RFC，往往会收到负面反馈。
由于 RFC 将收到来自社区的设计反馈，因此您应该准备好根据反馈进行修改。因此，要建立共识并整合反馈。得到广泛支持的 RFC 比未收到任何评论的 RFC 更有可能取得进展。
最终，团队将决定 RFC 是否是纳入 Gatsby 的候选。
作为纳入 Gatsby 的候选的 RFC 将进入为期 3 个日历天的“最后评论期”。此期间的开始将通过评论信号。
RFC 可以根据团队和社区的反馈进行修改。
在公开讨论平息并发表总结拒绝理由的评论后，团队可以拒绝 RFC。团队成员应随后添加“status: rejected”标签。
RFC 可以在其最后评论期结束时被接受。团队成员将添加“status: accepted”标签。
RFC 生命周期
一旦 RFC 变得活跃，作者就可以实施它，并将该功能作为一个 pull request 提交给 Gatsby 仓库。变得“活跃”并非一劳永逸，特别是它并不意味着该功能最终将被合并；它确实意味着核心团队已经原则上同意了它，并且愿意合并它。
此外，某个 RFC 被接受并且“活跃”的事实，并不意味着为其实现分配了任何优先级，或者是否有人正在处理它。
对活跃 RFC 的修改可以通过编辑讨论/评论来完成。我们努力以一种反映功能最终设计的方式编写每个 RFC；但流程的性质意味着我们不能期望每个被接受的 RFC 在下一个主要版本发布时都能真正反映最终结果；因此，我们试图让每个 RFC 文档在一定程度上与计划中的语言功能保持同步，通过后续的文档更改来跟踪这些更改。
实施 RFC
RFC 的作者没有义务实施它。RFC 作者（以及任何其他开发者）可以在 RFC 被接受后提交一个实现供评审。
如果您有兴趣处理“活跃”RFC 的实现，但无法确定是否有人已经在处理，请随时询问（例如，通过在相关问题上留言）。
评审 RFC
每个月，团队都会尝试评审一些开放的 RFC 讨论。
每个被接受的功能都应该有一个核心团队的倡导者，他将代表该功能及其进展。
Gatsby 的 RFC 流程的灵感来源于React RFC 流程、Yarn RFC 流程、Rust RFC 流程 和Ember RFC 流程。