| 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 的討論。利害關係人通常會指派代表，通常是技術主管或其他負責一組利害關係人的人員。
工程委員會。工程委員會會協助討論，並最終決定專案是否接受 RFC。
運作方式
本節說明 RFC 流程的每個步驟。
步驟 1：社交
RFC 流程的第一步，是向專案宣傳您的想法。 舉例來說，您可能發現某個問題，認為有解決的必要。其他人是否也遇到這個問題？可能有人已在處理問題，或瞭解問題的背景或脈絡，對您有所幫助。越早發現這項資訊越好。
相較於流程中的其餘步驟，這個步驟相對非正式。本文不會詳細說明如何宣傳您的想法，將技術概念傳達給他人是一項獨立的技能。不過，您可以先與要解決問題相關領域的技術主管討論這個主題。舉例來說，您可能想諮詢 OWNERS 檔案中的人員，瞭解需要修改哪些程式碼集區域才能執行您的想法。
如果不確定如何宣傳想法，請諮詢技術主管。他們通常有更多分享想法的經驗，或許能為你指引正確方向。
範例。這項 RFC 是透過在工程論壇中討論而發布，該論壇是 Google 內部定期舉行的會議，由參與專案的各工程領導人組成。我們也與 FTP 和 CTP 程序的建立者分享了 RFC，他們對這些程序有充分的背景知識和脈絡。
步驟 2：草稿
透過社交活動收集所有背景和脈絡後，即可開始 RFC 程序的正式部分。接下來，請撰寫 RFC 文件初稿。
從機制上來說，RFC 是 //docs/contribute/governance/rfcs 目錄中的 Markdown 檔案。如要建立 RFC，請建立 CL，將檔案新增至該目錄。首先，請複製 RFC 範本。雖然並非必要，但範本會提示您以半結構化方式思考要解決的問題，引導您撰寫高品質的 RFC。
在這個階段，請勿為 RFC 指派號碼。請改用 0000 做為預留位置。舉例來說，檔案名稱應類似於 0000_my_idea.md。RFC 獲得核准或遭到拒絕後，在登陸前會取得編號。
建議。在準備好取得意見回饋前，請考慮將含有 RFC 的 CL 標示為「處理中」。
步驟 3：疊代
建立含有 RFC 初稿的 CL 後，您就可以與適當的利害關係人反覆討論構想。希望您在宣傳構想時，已找出大部分適當的利害關係人，但您很可能在這個階段發現其他利害關係人。
在機制方面，您應將利害關係人新增至 CL 的「審查者」或「副本」欄位，邀請他們提供 RFC 意見回饋，就像一般程式碼審查一樣。利害關係人應在程式碼審查工具中，透過在 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，請參閱下方的「決策方式」一節。
所有利害關係人提供程式碼審查標記後，請傳送電子郵件至 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 語言做出決策。這項提案的誕生，正是因為該決策程序成功運作。