React 采用新的 RFC 流程

  • David Iffland
  • 张健欣

2017 年 12 月 18 日

话题:JavaScript语言 & 开发

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)关注我们。

JavaScript语言 & 开发