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