Facebook已經(jīng)決定采用一種新的征求意見（Request for Comments，RFC）流程，來幫助指導(dǎo)React的設(shè)計，同時使從想法到實現(xiàn)的過程更加順利。

新的流程要求，對于React的重大變更需要在開發(fā)工作開始前經(jīng)過一個審核流程。這些重大變更包括：

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

作為流程的一部分，開發(fā)者需要創(chuàng)建一個RFC文檔，向RFC倉庫提交一個pull request，然后將社區(qū)的反饋包含在提案中。是否接受這個RFC，由React核心團(tuán)隊做最終決定。

這似乎是React項目曾經(jīng)采用的非正式的慣用流程的正規(guī)化。一個GitHub上的React項目的調(diào)查顯示，有許多issue都是開始于伴隨不同層次討論的RFC。

Facebook將Rust RFC流程作為他們流程的靈感來源，因此兩者的RFC主頁有許多相同的內(nèi)容和步驟。當(dāng)然，RFC并不新鮮，它們是互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force，IETF）完成的許多工作的基礎(chǔ)。

Juan Pablo Buritica說，開源項目使用RFC流程的好處之一是人們更有融入感：

我從未發(fā)現(xiàn)，有比讓人們參與決策更好的方法，來讓人們獲得團(tuán)隊歸屬感。如果我們參與重要的決定，我們的工作可能會更有影響力，而這也讓我們更有工作的動力。通過給予團(tuán)隊成員機(jī)會去評論其他人提出的決策，RFC成為增強(qiáng)團(tuán)隊融入感和成員參與度的非常好的工具，而這也會形成工作中的影響力。

RFC流程會為開源項目維護(hù)人和想要為開源項目做貢獻(xiàn)的人都節(jié)省時間。對一個代碼庫做了一個大型的改動，然后提交了一個pull request，卻只是被代碼維護(hù)人拒絕，這完全是浪費時間。Jeff Geerling說，沒有經(jīng)過討論的大型改動是他拒絕許多pull request的原因之一：

我曾經(jīng)收到過一些將整個項目架構(gòu)或測試架構(gòu)替換了的PR。我不會合并像這樣的PR，除非這個PR已經(jīng)先在一個issue中被徹底地討論過（并經(jīng)過了核準(zhǔn)）。通常，事出必有因（事實上，原因還不止一個）。

目前RFC中的文檔列表包括一些由React核心團(tuán)隊成員撰寫的文檔。

查看英文原文：React Adopts RFC Process