ReactがRFCプロセスを採用

Facebookは、Reactの設計を導いて、アイデアから実装までの道のりをスムーズにするために、新しいRFC（Request for Comments）プロセスを採用することを決定した。

新しい手順では、Reactへの大きな変更に対して、開発を行う前に、審査プロセスを経ることを求めている。そうした変更の例をいくつか挙げる。

• 新しいAPI界面を作成し、導入時にはフィーチャーフラグが必要になるような新機能。
• リリースチャンネルの一部として出荷済みの機能の削除。
• React自体へのコード変更が含まれていなくても、新しいイディオムや決まりごとの導入時。

RFCプロセスのREADMEから引用

プロセスの一環として、開発者はRFCドキュメントを作成し、RFCリポジトリにプルリクエストを投げ、コミュニティからのフィードバックを提案に組み込む必要がある。そのRFCが受け入れられるかどうかの最終決定は、コアReactチームの責務だ。

これはReactプロジェクトが非公式に採用していた慣習を公式化したように見える。GitHubのReactプロジェクトを検索すると、さまざまなレベルの議論で、RFCからはじまるイシューが多数あることがわかる。

このプロセスにインスピレーションを与えたものとして、FacebookはRustのRFCプロセスを讃えている。そのRFCホームページには同様のコンテンツと手続きが多数ある。もちろん、RFCは新しいものではなく、IETF（Internet Engineering Task Force）が行ってきた多くの作業の土台だ。

オープンソースプロジェクトにRFCプロセスを用いる利点の1つは、人々がより参加していると感じることだ、Juan Pablo Buritica氏は語る。

人々を意思決定に参加させること以上に、チームへの所属感を生み出すのに良い方法は見つかりませんでした。重要な決定に関与すると、作業がもっと影響力のあるものになる可能性があり、これは目的意識を与えてくれます。チームメンバーに他人が提案した判断にコメントする機会を与えることにより、RFCは受け入れのための優れたツールとなり、作業に影響を与える可能性のある参加を可能にします。

RFCプロセスは、オープンソースメンテナーとコントリビューションしたい人、両者の時間を節約するはずだ。コードベースに大きな変更を加えて、メンテナーにリジェクトさせるだけのプルリクエストを投げるのは、時間の無駄だ。Jeff Geerling氏によると、議論されていない大きな変更は、プルリクエストをリジェクトする理由の1つだという。

プロジェクト全体のアーキテクチャやテストアーキテクチャを入れ替えるようなプルリクエストがありました。まず問題について徹底的に議論し（承認され）ない限り、私はこういうものを決してマージしません。なにかがそうなっているのには、たいてい理由（実際のところ、たくさんの理由）があるのです。

RFCのドキュメントリストには、今のところReactコアチームメンバーが書いたものがいくつか含まれている。