| RFC-0001：Fuchsia 要求註解 (RFC) 程序 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 制定適用於整項專案的技術決策的程序。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2020-02-20 |
| 審查日期 (年/月) | 2020-02-27 |
摘要
Fuchsia RFC 程序旨在提供一致且公開透明的路徑，以便做出適用於整個專案的技術決策。舉例來說，RFC 程序可用於改進專案藍圖和系統架構。
提振精神
目前，Fchsia 專案沒有製定適用於整個專案的技術決策的正式程序。就目前的規模而言，這種非正式做法會導致不同人對於專案目的地和系統的整合方式，擁有不同且有時不一致的觀點。在針對整個專案製定技術決策時，我們可以透過建立一致且透明的路徑，讓所有相關人員都能安心瞭解專案的技術方向。
設計
本節將說明 RFC 程序的設計。
使用程序的時機
絕大多數的 Fuchsia 變更都不需要 RFC。不過，您可以透過程式碼審查程序進行變更。然而，技術決策會對整個專案造成廣泛影響，因而需要更廣泛的協議，而且必須透過 RFC 程序與專案交流。
下列類型的變更必須使用 RFC 程序：
變更專案藍圖。專案藍圖說明會對系統造成廣泛影響的變更，經常接觸系統的大部分部分，或在子系統之間跨越界限。
為日後的開發作業新增限制。有些決策一旦制定，就會對系統的未來發展造成阻礙。我們必須謹慎做出這些決定，因為日後可能難以修改。
建立專案政策。專案政策對整個系統產生廣泛的影響，通常會影響整個專案的貢獻者。例如，變更支援的語言組合會影響所有需要偵錯及瞭解系統的使用者，即使並非所有人都使用新語言也一樣。
變更系統架構。系統架構說明瞭系統如何融入整個系統。根據定義改變系統架構，子系統之間的邊界會跨越子系統，而且需要與許多相關人員謹慎進行協商。
委派決策權。有時專案需要頻繁做出決策，而這些決策會因專業專業知識而受益。專案可以將這些決策類別的決策授權委派給其他群組或程序，而不是透過 RFC 程序做出所有決定。例如，我們通常需要對平台 API 做出決策，因為平台 API 會對未來的開發增加限制，但對每個平台 API 的每一個變更都使用 RFC 程序並不實際。
提報。最後，內容異動容易受到 RFC 程序的透明化及清晰易懂。如果對技術方向有歧異，且個別技術領袖無法解決，則由一位不同意的一方或其他貢獻者將決定提報至 RFC 程序。
RFC 程序也可以用於其他種類的變更，透過結構化方法的決策和耐用的決策記錄而受益。
角色與責任
使用者可以在多個角色中與 RFC 程序互動：
RFC Authors。RFC Author 是撰寫 RFC 的人員。凡是為 Fuchsia 貢獻者都能擔任 RFC 作者。指定的 RFC 可以有一或多位作者。特定 RFC 的作者驅動該 RFC 的程序。
相關人員。相關人員是指負責判斷專案是否接受指定的 RFC。利害關係人通常是 Fuchsia 貢獻者，但部分 RFC 可能會有 Fuchsia 專案以外的相關人員。舉例來說，利害關係人可能會參與其他使用 Fuchsia 的專案，或是受 Fuchsia 異動影響。相關人員不一定都會直接參與 RFC 相關討論。利害關係人通常是由某人「代表」，通常是技術主管或負責一組利害關係人的人員。
Eng Council：Eng Council 可促進討論並做出最終決定，是專案是否接受 RFC。
運作方式
本節將說明 RFC 程序中的每個步驟。
步驟 1：社交
RFC 程序的第一步，就是透過專案分享您的想法。 例如，您可能發現了您認為必須解決的問題。其他人是否注意到這個問題？可能有其他人正在設法處理這個問題，或是提供一些相關背景或背景資訊，有助您解決問題。越早發現這項資訊 就越好
與程序中其餘步驟相比，這個步驟相對來說較為正式。本文並未針對如何社交您的想法提供嚴謹的說明。與他人交流技術想法本身是不夠的。
不過，一個很好的開始，就是在討論與嘗試解決的問題相關的技術主管時，提出討論主題。舉例來說，您可能會想諮詢 OWNERS 檔案中的人員，瞭解程式碼集的部分需要修改才能執行想法。
如果不確定如何社交您的想法，請考慮向技術主管尋求建議。他們通常有更深入的交流經驗，或許能協助您找到最佳方向。
範例。在 Eng 論壇中，您可以與 Google 內部成員討論參與專案的不同工程部門主管，討論這個 RFC 的社交用途。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 標示為「工作中」，直到您準備好提供意見回饋為止。
步驟 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 程式碼審查工具，在 CL 修改
//docs/contribute/governance/rfcs目錄時寄電子郵件 > 通知。
步驟 4：核准
RFC 上的疊代作業開始後，即可進入核准階段，在此階段，相關人員會將 Code-Review 標記設為 +1 或 +2，在 RFC 上簽核。一般而言，需要核准 CL (亦即 RFC 必須完成簽核) 的相關人員應使用 +2 進行簽核，而不需要核准的相關人員可以使用 +1 簽核，但如果相關人員想表達其信任，則可以使用 +2 進行簽署。
相關人員如果希望對 RFC 提出異議，可以將 Code-Review 標記設為 -1 或 -2，具體取決於他們對於 RFC 不應前進的程度。將 Code-Review 標記設為 -1 或 -2 時，利害關係人必須說明推拒原因，最好讓對方清楚瞭解原因，不必閱讀問題前的整段討論。
利害關係人將 Code-Review 標記設為 -1 或 -2 不一定會導致專案無法接受 RFC。如要進一步瞭解專案如何決定是否接受 RFC，請參閱下方的「決策方式」一節。
所有相關人員都使用 Code-Review 標記完成評分後，請傳送電子郵件到 eng-council@fuchsia.dev，提示 Eng Council (工程委員會) 判斷是否要接受您的 RFC。
步驟 5：提交
若專案決定接受 RFC，Eng Council 的成員會為您的 CL 加註，指出接受 RFC 並會指派 RFC 編號，通常是系列中下一個可用的編號。如果有任何 -1 或 -2 Code-Review 標記，Eng Council 會總結客戶推拒說辭，並描述 RFC 往後的推拒原因，都會明確清除每個標記。
若專案決定拒絕您的 RFC，Eng Council 的成員會為您的 CL 加註，說明 RFC 遭到拒絕，並提供拒絕理由。拒絕的 RFC 是寶貴的工程構件。Eng Council 會與 RFC 作者合作，輸出標示為遭拒的 RFC 版本並納入原因。
您應該在 RFC 的標題和檔案名稱中，上傳含有指定編號的新 RFC 修補程式集。如果您的 RFC 已獲核准且需要實作，請確定您有在 Issue Tracker 中回報問題，並在 RFC 標頭中加入該問題的連結。
接著，Eng Council (Eng Council) 會標記您的 CL Code-Review +2，代表您的 RFC！
恭喜！您在專案中貢獻了寶貴的工程構件！
決策方式
是否接受 RFC 是由工程委員會 (Eng Council) 決定是否接受 RFC，並互相大致共識。如果決定涉及 RFC 將 Eng Council 成員為作者，這些成員必須拒絕自己做出決定。
若 Eng Council 無法達成大概的共識，我們不接受 RFC。在決定是否要接受 RFC 時，Eng Council 會考量下列因素：
- RFC 會推動專案目標嗎？
- RFC 會不會堅持專案的值？
- 所有利害關係人是否都能在討論中適當地呈現？
- 如有任何利害關係人反對，工程委員會是否能完整瞭解這些推拒說詞？
工程委員會所做的決策可提報給專案的主管機關。
說明文件
這份 RFC 可做為 RFC 程序的說明文件。
缺點、替代方案和未知
實作本提案的主要成本是，導入正式決策程序可能會拖慢決策速度。該程序可能比某些決策所需花費的更多。
來源存放區中的記錄決策，會導致這些決策更難以變更。在某些情境下，這種效果可能會增加，但在其他情況下也有可能會造成負面影響。
「使用程序的時機」一節中的條件會嘗試將程序範圍限制在連續的情況，藉此緩解這項缺點，但此類限定範圍會繫結至偽陽性和偽陰性。
目前有許多可能的替代策略可用來解決基礎問題。例如，我們能採用以同步會議為中心的決策程序，但這種程序很難擴展至全球的開放原始碼專案。我們也可以選取不同的決策機制，平衡更多的共識或更有權力。
先前的圖片和參考資料
開放原始碼專案的決策程序有一些先進的技巧，本提案會受到下列現有程序的影響：
IETF RFC 程序。IETF 已長時間執行成功的大規模決策程序。本文件所描述的程序有許多想法，其中包括 IETF 程序的想法，其中包括一些術語。
Rust RFC 程序。Rust 社群會執行 RFC 程序，在為一些類似的軟體工程專案做出決策時非常有效。本文件所述的程序在 Rust RFC 程序之後會以完全直接的建模方式建立。
Blink 意圖導入程序。Chromium 專案會針對影響網頁的行為執行決策程序。本文件中描述的程序，都是根據我的 (abarth) 經驗，協助設計及執行該程序一段時間。
FIDL 調整提案。Fuchsia 專案透過類似的程序直接制定 FIDL 語言。這個提案之所以存在，是因為該決策程序是成功的。