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
感谢罗远航对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
评论