| RFC-0001：Fuchsia 意見請求 (RFC) 程序 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這是一個用於做出全專案技術決策的程序。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-02-20 |
| 審查日期 (年-月-日) | 2020-02-27 |
摘要
Fuchsia RFC 程序旨在提供一致且透明的途徑，讓您做出全專案的技術決策。舉例來說，RFC 程序可用於改善專案路線圖和系統架構。
提振精神
目前，Fuchsia 專案並未制定正式程序，用於做出全專案的技術決策。在目前的規模下，這種非正式的做法會導致不同人員對專案的方向和系統組合方式有不同的 (甚至不一致的) 觀點。建立一致且透明的專案全局技術決策途徑，讓所有利益相關者都能對專案的技術方向充滿信心。
設計
本節將說明 RFC 程序的設計。
使用程序的時機
絕大多數的 Fuchsia 變更都不需要 RFC。相反地，您可以透過程式碼審查程序進行這些變更。不過，對整個專案影響甚鉅的技術決策需要更廣泛的共識，且必須透過 RFC 程序與專案進行交流。
以下類型的變更必須使用 RFC 程序：
變更專案路線圖。專案路線圖會說明對整個系統造成廣泛影響的變更，這些變更通常會影響系統的大部分或跨越子系統之間的界線。
為日後的開發作業新增限制條件。有些決定一旦做出，就會限制系統日後的發展。我們必須謹慎做出這類決定，因為日後可能難以修改。
制定專案政策。專案政策對整個系統影響廣泛，通常會影響整個專案的貢獻者。舉例來說，變更支援語言組合會影響所有需要偵錯及瞭解系統的使用者，即使不是每個人都會使用新語言也一樣。
變更系統架構系統架構說明系統如何整合為整體。根據定義，變更系統架構會跨越子系統之間的界線，因此需要與許多利益相關者進行仔細諮商。
委派決策權。專案經常需要做出某些類型的決策，並從專業知識中獲益。專案可以將這些類型的決策授權委派給其他群組或程序，而非透過 RFC 程序做出所有決策。舉例來說，我們經常需要針對平台 API 做出決策，這會為日後的開發作業增加限制，但如果每次變更平台 API 都要使用 RFC 程序，就會不切實際。
回報問題和錯誤：最後，RFC 程序的透明度和清晰度可讓有爭議性的變更有所助益。如果技術方向有爭議，而單一技術主管無法解決，則其中一方或其他貢獻者可以將決定提報至 RFC 程序。
RFC 程序也適用於其他類型的變更，因為這些變更可從其結構化決策方法和永久記錄決策中受益。
角色和職責
人員可透過幾種角色參與 RFC 程序：
RFC 作者：RFC 作者是指撰寫 RFC 的人員。凡是為 Fuchsia 做出貢獻的人都可成為 RFC 作者。特定 RFC 可以有一位或多位作者。特定 RFC 的作者會主導該 RFC 的程序。
利害關係人。利益相關者是指在專案接受特定 RFC 時，具有利益關係的人員。利益相關者通常是 Fuchsia 的貢獻者，但有些 RFC 的利益相關者可能不限於 Fuchsia 專案。舉例來說，利害關係人可能會參與使用 Fuchsia 的其他專案，或是受到 Fuchsia 變更的影響。利益相關者不一定會直接參與 RFC 相關討論。相反地，利益相關者通常會由某人代表，通常是技術主管或負責一組利益相關者的其他人員。
工程委員會：Eng Council 會促進討論，並就專案是否接受 RFC 做出最終決定。
運作方式
本節將說明 RFC 程序的各個步驟。
步驟 1：社交互動
RFC 程序的第一步，就是與專案分享您的想法。舉例來說，您可能會發現某個問題，並認為必須解決這個問題。其他人是否也遇到這個問題？其他人可能已在處理這個問題，或是可能對這個問題有實用的背景資訊或相關資訊。越早發現這項資訊越好。
相較於流程中的其他步驟，這個步驟相對不正式。本文件並未詳細說明如何將想法分享給他人。將技術構想分享給他人，本身就是一項技能。不過，建議您先與技術主管討論相關問題，並提出相關問題。舉例來說，您可能需要諮詢 OWNERS 檔案中的人員，瞭解程式碼集的哪些部分需要修改，才能執行您的想法。
如果不確定如何分享您的想法，不妨向技術主管尋求建議。他們通常有更多經驗可用於分享構想，也許能為您指出正確方向。
示例：我們在工程論壇中討論這項 RFC，並將討論結果公開。工程論壇是 Google 內部定期召開的會議，參與者包括參與專案的各個工程主管。我們也將 RFC 與 FTP 和 CTP 程序的建立者分享，他們對這些程序的背景和脈絡瞭若指掌。
步驟 2：草稿
蒐集完所有背景資訊和背景資訊後，您就可以開始 RFC 程序的正式部分。接下來，請撰寫 RFC 文件的初稿。
從機械角度來說，RFC 是 //docs/contribute/governance/rfcs 目錄中的 Markdown 檔案。如要建立 RFC，您必須建立 CL，將檔案新增至該目錄。首先，請複製 RFC 範本。雖然不強制規定，但這個範本旨在引導您以半結構化的方式思考要解決的問題，進而撰寫高品質的 RFC。
請勿在這個階段為 RFC 指派編號。請改用 0000 做為預留位置。例如，檔案名稱應為 0000_my_idea.md。在 RFC 獲得核准或拒絕前，就會在發布前取得編號。
建議建議您在準備好接受意見回饋前，將包含 RFC 的 CL 標示為「work-in-progress」(進行中的工作)。
步驟 3：重複執行
建立包含 RFC 初稿的 CL 後，您就可以與適當的利益相關者討論構想。希望您在分享想法時，已經找到大多數適當的利害關係人，但您很可能會在這個階段發現其他利害關係人。
從機制上來說，您應該邀請利害關係人針對 RFC 提供意見回饋，方法是將他們加入 CL 中的「Reviewers」或「CC」欄位，就像進行一般程式碼審查一樣。利害關係人應在程式碼審查工具中對 RFC 留下意見，提供意見回饋。
如果討論內容過於複雜，不利於程式碼審查工具，建議您安排與相關利害關係人開會，以便更有效率地進行討論。會議結束後，您必須在 CL 的留言中發布會議摘要，方便未出席會議的人員瞭解會議討論內容。
如果討論內容變得有爭議，請將問題提報給 RFC 編輯人員。工程委員會可以協助推動討論，例如為討論提供額外架構，或將討論移至其他論壇。無論討論如何進行，任何非 CL 討論的結果都必須記錄在 CL 中，通常是將討論摘要以 CL 留言的形式發布。
如果您想撤銷 RFC，可以將包含 RFC 的 CL 標示為已放棄。日後如果情況有變，您或其他人隨時可以復活 RFC。如果您要復活他人建立的 RFC，應從頭開始執行 RFC 程序，但可以使用撤銷的 RFC 做為起點，而非 TEMPLATE.md。請與原作者洽談，瞭解他們是否希望繼續將自己的名字與 RFC 的新版本相關聯。
建議如果您對 RFC 感興趣，建議您設定 Gerrit Code Review 工具，以便在 CL 修改
//docs/contribute/governance/rfcs目錄時傳送電子郵件 > 通知。
步驟 4：核准
當 RFC 的迭代作業完成後，您就可以進入核准階段，在這個階段中，利害關係人會將 Code-Review 標記設為 +1 或 +2，以便簽署 RFC。一般來說，需要核准 CL 的利害關係人 (也就是需要簽核才能讓 RFC 繼續進行的利害關係人) 應以 +2 簽核，而不需要簽核的利害關係人則應以 +1 簽核，但如果想表達對 RFC 的熱情，所有利害關係人都可以以 +2 簽核。
如要反對 RFC，利害關係人可以將 Code-Review 標記設為 -1 或 -2，視他們認為 RFC 不應繼續推進的強烈程度而定。將 Code-Review 標記設為 -1 或 -2 時，利害關係人必須說明反對的原因，最好是讓對方清楚瞭解異議，而不需要閱讀提出異議前的完整討論內容。
利益相關者將 Code-Review 標記設為 -1 或 -2，不一定會阻止專案接受 RFC。如要進一步瞭解專案如何決定是否接受 RFC，請參閱下方的「如何做出決策」一節。
所有利益相關者都已提供 Code-Review 標記，請傳送電子郵件至 eng-council@fuchsia.dev，提醒工程委員會決定是否接受 RFC。
步驟 5：提交
如果專案決定接受您的 RFC，工程委員會成員會在 CL 中說明 RFC 已接受，並指派 RFC 編號，通常是該系列中下一個可用的編號。如果有任何 -1 或 -2 程式碼審查標記，工程委員會會明確清除每個標記，並概述反對意見，以及為何在反對意見下仍要繼續推動 RFC。
如果專案決定拒絕你的 RFC，工程委員會成員會在 CL 中說明 RFC 遭拒，並提供拒絕的理由。遭拒的 RFC 是寶貴的工程產物。工程委員會將與 RFC 作者合作，發布標示為已拒絕的 RFC 版本，並納入相關理由。
您應上傳 RFC 的新修補程集，並在 RFC 的標題和檔案名稱中加上指定的編號。如果 RFC 已獲核准且需要實作，請務必在問題追蹤器中提交問題，並在 RFC 的標頭中加入問題的連結。
工程委員會會將 CL 標示為「程式碼審查 +2」，您就可以提交 RFC！
恭喜！您已為專案貢獻了寶貴的工程構件！
決策方式
工程顧問委員會會根據大致共識做出是否接受 RFC 的決定。如果決策涉及由工程顧問委員會成員撰寫的 RFC，這些成員必須迴避決策。
如果工程委員會無法達成粗略的共識，就不會接受 RFC。在決定是否接受 RFC 時，工程委員會會考量下列因素：
- RFC 是否有助於達成專案目標？
- RFC 是否符合專案的價值？
- 所有利害關係人是否適當參與討論？
- 如果有任何利害關係人提出異議，工程委員會是否能充分瞭解這些異議？
工程委員會做出的決定，可以提報給專案的管理機構。
說明文件
本 RFC 可做為 RFC 程序的說明文件。
缺點、替代方案和未知事項
實施這項提案的主要成本，是引入正式決策程序可能會拖慢決策速度。但對於某些類型的決策而言，這項程序可能會過於繁重。
在來源存放區中記錄決策會導致這些決策更難以變更。在某些情況下，這可能會帶來正面影響，但在其他情況下，也可能會帶來負面影響。
「何時使用此程序」一節中的標準會將程序範圍限制在後續情況，藉此減輕這項缺點，但這類範圍設定勢必會出現偽陽性和偽陰性。
解決潛在問題的方法有很多種，舉例來說，我們可以使用以同步會議為中心的決策程序，但這類程序很難擴展到全球開源專案。我們也可以選擇其他決策機制，以便在權威與共識之間取得平衡。
既有技術與參考資料
開放原始碼專案的決策程序有許多先前技術。本提案深受下列現有程序的影響：
IETF RFC 程序。IETF 長期以來成功執行大型決策程序。本文件所述的程序參考了 IETF 程序的許多概念，包括部分術語。
Rust RFC 程序。Rust 社群會執行 RFC 程序，這項程序對於處理類似的軟體工程專案非常有效。本文件所述的程序，是直接以 Rust RFC 程序為模型。
Blink 意圖導入程序。Chromium 專案會針對影響網頁的行為執行決策程序。本文件所述的程序是根據我 (abarth) 在設計和執行該程序一段時間後的經驗所得。
FIDL 微調提案Fuchsia 專案曾直接使用類似的程序決定 FIDL 語言。這項提案之所以存在，是因為決策程序成功。