Facebook已经决定采用一种新的征求意见（Request for Comments，RFC）流程，来帮助指导React的设计，同时使从想法到实现的过程更加顺利。

新的流程要求，对于React的重大变更需要在开发工作开始前经过一个审核流程。这些重大变更包括：

新增功能，这项功能会创建新的API模块并且如果引入该功能会需要一个feature flag（feature flags是软件开发的一种最佳实践，通过feature flag，你可以控制一个功能的完整生命周期）。删除功能，这项功能已经作为发布渠道的一部分进行了交付。引入新的惯用做法或约定，即使这些并不包含对React本身的代码修改。

上述列表引自RFC流程的README文档

作为流程的一部分，开发者需要创建一个RFC文档，向RFC仓库提交一个pull request，然后将社区的反馈包含在提案中。是否接受这个RFC，由React核心团队做最终决定。

这似乎是React项目曾经采用的非正式的惯用流程的正规化。一个GitHub上的React项目的调查显示，有许多issue都是开始于伴随不同层次讨论的RFC。

Facebook将Rust RFC流程作为他们流程的灵感来源，因此两者的RFC主页有许多相同的内容和步骤。当然，RFC并不新鲜，它们是互联网工程任务组（Internet Engineering Task Force，IETF）完成的许多工作的基础。

Juan Pablo Buritica说，开源项目使用RFC流程的好处之一是人们更有融入感：

我从未发现，有比让人们参与决策更好的方法，来让人们获得团队归属感。如果我们参与重要的决定，我们的工作可能会更有影响力，而这也让我们更有工作的动力。通过给予团队成员机会去评论其他人提出的决策，RFC成为增强团队融入感和成员参与度的非常好的工具，而这也会形成工作中的影响力。

RFC流程会为开源项目维护人和想要为开源项目做贡献的人都节省时间。对一个代码库做了一个大型的改动，然后提交了一个pull request，却只是被代码维护人拒绝，这完全是浪费时间。Jeff Geerling说，没有经过讨论的大型改动是他拒绝许多pull request的原因之一：

我曾经收到过一些将整个项目架构或测试架构替换了的PR。我不会合并像这样的PR，除非这个PR已经先在一个issue中被彻底地讨论过（并经过了核准）。通常，事出必有因（事实上，原因还不止一个）。

目前RFC中的文档列表包括一些由React核心团队成员撰写的文档。

查看英文原文：React Adopts RFC Process