Fuchsia RFC 程序

Fuchsia RFC 程序演變自下列 RFC：

• RFC-0001：Fchsia 評論要求程序
• RFC-0006：Zircon RFC 程序附加條款
• RFC-0067：Fchsia RFC 程序新增項目
• RFC-0017：FTP 程序消失了，很久以前就沒通過 RFC 流程！
• RFC-0122：RFC 相關人員
• RFC-0248：RFC 問題陳述式

本頁整理了上述的 RFC，並擷取目前的程序。

查看過這個程序後，您可以按照這份指南，建立 RFC。

摘要

Fuchsia RFC 程序旨在提供一致且透明的路徑，以便做出適用於整個專案的技術決策。舉例來說，RFC 程序可用來改善專案藍圖和系統架構。

提振精神

RFC 程序可以為整體專案建立一致且透明的路徑，並確保每項決策都參與適當的利害關係人。

設計

本節將說明 RFC 程序的設計。

使用這項程序的時機

RFC 程序可用於對 Fuchsia 的任何變更，因為它的結構化做法、對決策有助益、由 Eng Council 提供提報協助，以及/或是長期的決策記錄。

絕大多數的變更都「不需要」requireRFC 規範。而可透過程式碼審查程序進行變更。貢獻者如果覺得 RFC 程序很實用，可以放心使用 RFC 程序；如果我們對於特定程序不需要或無法增添價值，便可隨時停止。不過，對專案造成廣泛影響的技術決策需要更廣泛的協議，而且必須使用 RFC 程序與專案進行社交互動。

以下類型的變更必須使用 RFC 程序：

• 在日後的開發作業中加入限制。有些決策一旦制定，就會限制系統的未來開發作業。做出這類決定時，我們必須非常謹慎，因為結果日後可能難以修改。

• 設定專案政策。專案政策對整個系統的影響很大，通常會影響整個專案的貢獻者。範例包括：變更支援的語言組合 (影響所有需要偵錯及瞭解系統的使用者)、淘汰廣泛使用的 API，以及變更大量程式碼變更的測試要求。

• 變更系統架構。系統架構說明瞭系統如何搭配整體使用。根據定義，變更系統架構會跨越子系統之間的界線，而且必須向許多相關人員謹慎諮詢。

• 委派決策權：專案往往需要頻繁做出決策，而這類決策對專業技術的幫助也有利。專案並不會透過 RFC 程序做出所有決定，而是將這些決策類別的決策權委派給其他群組或程序。舉例來說，我們通常需要對平台 API 做出決策，進而對日後的開發設下限制，但每次變更平台 API 時一律使用 RFC 程序並不切實際。

• 提報。最後，RFC 程序的透明度和明確性 也能讓這類變更受益如有個別技術主管無法解決的技術方向爭議，可以選擇由其中一方或其他貢獻者將決定提報給 RFC 程序。

除了上述一般注意事項外，還有部分領域宣告了其他條件。請視需要參閱以下文件：

領域	標準 RFC
元件架構	RFC-0098
FIDL	RFC-0049
軟體推送	RFC-0103
Zircon	RFC-0006

其他可能受益於 RFC 程序的變更，包括需要手動或自動大規模變更程式碼集的變更。例如記錄的編寫方式或錯誤路徑的處理方式。與其生活在一致性島上，而是要找到最佳模式，並統一應用到整個程式碼集。

啟動 RFC 程序的時機

我們建議作者只要發現實用的問題陳述，以啟動 RFC 程序即可。此方法應相對精簡，而且作者如果認為發布 RFC 沒有必要，可以選擇結束 RFC 程序。

有些構想可能受益於早期與相關人員討論，瞭解需求，而其他構想則受益於原型能否幫助我們瞭解相關優缺點。

角色和責任

使用者會透過多個角色與 RFC 程序互動：

• RFC 作者RFC Author 是撰寫 RFC 的人。對 Fuchsia 的貢獻者都可以是 RFC 作者。一個 RFC 可能會有一或多個作者。指定 RFC 的作者，具有該 RFC 的程序。

• 工程委員會工程委員會 (FEC) 有助於討論並做出最終決策，以判斷專案是否接受 RFC。

• 講師。FEC 指定透過 RFC 程序將 RFC 所指派的人員。目前這個人通常是 FEC 成員。講師會建議作者，也可能做為提報項目，確保相關人員在時間軸上能提供意見回饋。

• 利害關係人利害關係人是有權決定專案是否接受特定 RFC 的人。利害關係人通常是 Fuchsia 的貢獻者，但部分 RFC 可能會有 Fuchsia 專案以外的利害關係人。例如，利益相關者可能參與其他使用 Fuchsia 的專案，或受到 Fuchsia 異動的影響。利害關係人不一定每次都能直接參與有關 RFC 的討論。利害關係人通常是由某人「代表」，通常是技術主管或負責一群利益相關者的其他人。

• 審查者：當 FEC 決定接受或拒絕 RFC 時，系統會將 +1 或 -1 的利害關係人納入考量。(雖然 +2 是程式碼 CL 的「核准」，但我們傾向審查人員 +1 或 -1，表示他們對這類項目表示支持或缺少這類意見，並在取得核准後轉介 +2)。

• 諮詢。對 RFC 所給予的意見應有，但 FEC 決定接受或拒絕 RFC 時，不會考慮 +1 或 -1 的利害關係人。

運作方式

本節說明 RFC 程序中的每個步驟。

步驟 1：找出問題

RFC 程序的第一步是找出問題，並向專案傳達該問題。是否有其他人注意到這個問題？可能有其他人在處理這個問題，或是具備與問題相關的背景或背景資訊。越早發現這項資訊越好

請注意，開始這個步驟之前，不需要改善或正式撰寫問題陳述式。建議您盡早開始社交互動，以便收到有關想法是否可行以及方向是否正確的回饋。這樣或許就能為作者省下時間和精力，因為提案未具體化，或是方向需要大幅變更。

在此程序階段使用的通訊方法沒有限制。雖然 RFC 的正式寫入最終會將形狀視為使用 Gerrit 程式碼變更審查的標記檔案，但作者應使用他們在這個階段認為有用的媒介。

結束條件：作者清楚瞭解要解決的問題，「或是」作者判定這個問題不需要 RFC 程序。

步驟 2：問題陳述

作者應寫一段簡短的說明，說明要解決的問題。這些資料可以是任何有助於討論的格式，並提供充足資訊，以便讀者判斷哪些 Fuchsia 子系統可能受到影響。這個問題陳述式應該具體指出這個階段已知的任何需求，但稍後可能會發現更多要求。而且所有「非目標」也應清楚明確，以避免範圍衝突。

結束條件：作者透過電子郵件將問題陳述式傳送給 Eng Council (FEC)。

步驟 3：指派講師

工程委員會負責指派輔導員。這位講師是 RFC 作者的資源，可協助 RFC 作者修正問題陳述並找出相關利害關係人。講師也可能會建議作者，說明這個問題是否需要或將受益於正式的 RFC 書面。在某些情況下，講師可能會建議作者不要按照 RFC 程序以外的方式設計及實作。

測試結束條件：指派講師後，作者會收到電子郵件通知。

步驟 4：利害關係人發現

在這個階段，RFC 作者應找出與此 RFC 相關的利害關係人。作者可以請講師針對這項程序提出建議。利害關係人清單應連同問題陳述一起寫下。這可能會在 Google 文件中進行，或者作者可以選擇使用大部分 RFC 範本建立 RFC CL 範本，並填寫利害關係人部分。

注意：如有需要，作者或講師可能會在後續流程中新增或移除相關人員。

結束條件：撰寫者和講師同意了一組利害關係人，而利害關係人會記錄在 Google 文件或符合 RFC 範本的異動清單中。

步驟 5：社交

在這個階段，找出問題的解決方案，以及各種解決方案的優缺點。與利害關係人交流這些解決方案，並採納其意見回饋。如果您不確定如何交流想法，不妨請講師或技術主管尋求建議。他們往往具有更豐富的社交想法，或許也能指您一個正確方向。

範例：這個 RFC 是透過 Eng 論壇進行討論而交流，這是 Google 內部與參與這項專案中不同工程主管的定期會談。RFC 還與 FTP 和 CTP 程序的建立者進行社交互動，這些程序的背景和背景資訊充足。

測試結束條件：表示作者有足夠的資訊可以繼續進行。(由作者自行斟酌)。如果他們覺得這可以完成 他們可以採取以下幾種做法：

• 原型：如果社交階段出現不同的做法，但權衡不明確，作者可能會選擇建立原型，進一步評估這些選項。這種原型有助於進一步社交。
• 保留 RFC 程序。如果作者 (可能在講師的協助下) 認定這個問題不需要或受益於 RFC，則可繼續使用程式碼審查程序建構解決方案。作者也可以選擇非正式地發布設計文件。
• 寫下來。繼續執行步驟 6。

步驟 6：草稿和疊代

作者透過社交收集了所有背景和背景資訊後，就能開始著手 RFC 程序的正式部分。下一步是撰寫 RFC 文件本身的草稿。早期草稿和意見回饋可能會在 Markdown 之外 (例如 Google 文件) 中進行。不過，如果此程序稍後有正式的 RFC 寫入，則強烈建議您以標記中更動態的媒介，從較動態媒介轉移至 RFC 寫入中的相關背景資訊。舉例來說，來回對話可能會導致系統新增其他「考慮的替代項目」。

作者準備就緒後，應建立 CL，將檔案加入 //docs/contribute/governance/rfcs 目錄，從 RFC 範本的副本開始。

屬於 RFC 的任何其他檔案 (例如圖表) 都可以新增至 resources 目錄的子資料夾底下，資料夾名稱與 RFC 本身相同。範例：//docs/contribute/governance/rfcs/resources/<RFC_name>/diagram.png。

請放心，在這個階段中將數字指派給 RFC。請改用 NNNN 做為預留位置。例如，檔案名稱的格式應為 NNNN_my_idea.md。RFC 會在到達前不久收到電話號碼。

提示：如要瞭解如何在 RFC 上擬定草稿及疊代作業，請參閱 RFC 最佳做法文件。

建議。建議將包含 RFC 的 CL 標示為「處理中」，直到準備好取得意見回饋為止。

作者應邀請利害關係人提供 RFC 意見，方式如下：在 CL 的「審查人員」(適用於需要 +1 的相關人員) 或「副本」欄位 (適用於「諮詢」的相關人員) 中，依據一般程式碼審查的方式邀請利益相關者提供 RFC。此外，作者也可以透過電子郵件將 CL 傳送至 eng-council-discuss@fuchsia.dev 以徵求其他意見回饋。利益相關者應在程式碼審查工具中留下對 RFC 的註解，以提供回饋。

審查人員應在五個工作天內回應審查要求及追蹤後續留言。作者和審查人員應使用 Gerrit 的「注意力集」功能追蹤需要回覆的對象。如果回應所需時間超出此 (例如需要建構原型)，請務必在 CL 註解中指明。

如果討論內容對程式碼審查工具來說太複雜，或是處理時間超出預期，請考慮安排時間與相關利益相關者進行會議，以便提高討論效率。會議結束後，您必須在 CL 註解中張貼會議摘要，讓未參加會議的使用者瞭解會議中的討論內容。

如果作者在討論期間遇到任何問題或延遲，講師可以幫忙解決。以下列舉幾個討論期間的常見問題：

• 討論過程是否嚴重或不具實質效益。比起文字型溝通，面對面會談通常更有效率。
• 利害關係人過度吃驚 (填充人) 或排擠討論 (無回應)。有時候，利害關係人不喜歡這些提案，卻沒有對這些延遲的策略抱持堅定的技術論點和度假村，這或許是出乎意料的。
• 許多人都會收到許多評論、建議和反對意見，因此我不確定哪些留言是來自相關相關人員。這類意見回饋通常與核心問題無關，不會封鎖系統接受的 RFC。
• 這些討論只花了很久的時間，無法收縮。

如果討論內容產生爭議，或您不易取得利害關係人的意見回饋，請通知講師。講師可以協助推動討論，例如提供額外的討論架構，或將討論移至其他論壇，例如同步會議或工程審查。無論討論如何進行，所有非 CL 討論的結果都必須擷取在 CL 中，而我們通常會以 CL 註解的形式發布討論摘要。

意見回饋包括非相關人士的留言。作者應視情況回應這些註解，但進行「Last Call」階段並不需要進行設定。如果留言中指出立場者是誰，FEC 可以協助解決這個問題。

如果問題不再相關，或作者和利益相關者同意問題並不構成 RFC，作者可在此時撤銷 RFC。在這種情況下，作者應將包含 RFC 的 CL 標示為已放棄。如果情況改變，作者或其他人可在日後重新運用您的 RFC。應對其他人建立的 RFC 時，您應該從頭開始執行 RFC 程序，但您可以使用具有繪製 RFC 做為起點，而非 TEMPLATE.md。請與原始作者討論，判斷他們是否要繼續將自己的名稱與 RFC 的新進化方式建立關聯。

審查人員注意事項：RFC 程序的用意是鼓勵各種觀點和活力積極討論。在公開論壇中發表負面意見往往並不容易如有需要，審查員可以 聯絡其主管、同儕或工程委員會尋求協助

建議。如果您對 RFC，請考慮設定 Gerrit 程式碼審查工具，以便在 CL 修改 //docs/contribute/governance/rfcs 目錄時傳送電子郵件通知您。

測試條件：RFC CL 已開放審查，因此已撤下意見回饋並納入 RFC CL OR RFC。

步驟 7：上次通話

RFC 上的討論正在對話後，作者必須請求講師將 RFC 狀態移至「上次呼叫」。輔導員會在追蹤工具中將 RFC 標示為「上次呼叫」，這會產生自動傳送至 eng-council-discuss@fuchsia.dev 的電子郵件，並對 CL 加註以徵求最終意見回饋，再前往決策步驟。接下來的 7 天內，RFC 將會開放

一般而言，審查員會使用 +1 號進行簽核，講師會以 +2 號標示。如果受僱的利益相關者想表達對 RFC 的熱愛，也可使用 +1 或 +2 簽核 (雖然這並非硬性規定)。

希望反對 RFC 的利益相關者可將 Code-Review 標記設為 -1 或 -2，具體取決於他們認為 RFC 不應進行下一階段的程度。將 Code-Review 標記設為 -1 或 -2 時，利害關係人必須說明拒絕原因，最好能夠讓對方清楚瞭解推拒說詞，而不必閱讀整個推拒說詞前的討論。

利害關係人將 Code-Review 標記設為 -1 或 -2，不一定會導致專案無法接受 RFC。如要進一步瞭解專案如何決定是否接受 RFC，請參閱下方的「決策方式」一節。

所有利害關係人都確認了程式碼審查標記之後，請傳送電子郵件至 eng-council@fuchsia.dev，提醒工程委員會決定是否接受您的 RFC。

測試條件：所有相關人員提供的意見回饋；已回答所有意見回饋。

步驟 8：提交

如果專案決定接受您的 RFC，工程委員會的成員會在您的 CL 上加註說明 RFC 已被接受，並指派 RFC 編號 (通常是系列中的下一個可用數字)。如有任何 -1 或 -2 程式碼審查標記，工程委員會會透過總結推拒說詞並說明 RFC 一直以來推辭的原因，以明確清除每個標記。工程委員會會表明是否需要在 RFC 中記錄任何其他資訊，例如說明其他做法或進行取捨的理由。

如果專案決定拒絕您的 RFC，工程委員會的成員會在您的 CL 上加註，說明 RFC 已遭拒，並提供拒絕的原因並指派 RFC 號碼。遭拒的 RFC 是相當實用的工程構件Eng Council 會與 RFC 作者合作，找出標示為已遭拒並納入理由的 RFC 版本。

在極少數的情況下，如果工程委員會找到一或多個未解決的項目，RFC 可能就會回到 draft 階段。工程委員會會要求作者解決與相關利害關係人找到的開放項目，然後再提出其他審查 RFC 要求。

您應該透過 RFC 標題和檔案名稱中的指派編號上傳新的 RFC 修補程式集。如果 RFC 已獲核准且需要執行，請確認問題追蹤工具中列出了問題，並在 RFC 標頭中附上該問題的連結。

工程委員會之後會標記您的 CL 程式碼審查 +2，屆時您就能收到 RFC！

恭喜！你為專案提供了一個寶貴的工程構件！

測試條件：指派 RFC 編號；納入任何適用的理由、取捨和工程委員會意見回饋；已合併 RFC。

保留中

如果您目前不想讓 RFC 進展，例如因為優先順序已改變，或 RFC 嘗試解決的問題不再那麼重要，則可將您的 RFC 移至「保留中」狀態。當 RFC 處於「待處理」狀態時，利害關係人不應提供意見回饋，FEC 也不會主動協助處理進度。

如果一個月的 RFC 沒有任何顯示進度，RFC 機器人就會傳送電子郵件給您和講師，協助您討論是否要將 RFC 移至「待處理」狀態，或是如何推進 RFC。在理想情況下，如果遇到資料差異或延遲情形，您應在此時間之前將這種情況提報給協調人員，但這段對話也非常適合用來找出這些問題。

您可以隨時將 RFC 移出「待處理」狀態，方法是聯絡受害人員，告知對方您打算在 RFC 上繼續處理工作。如果需要新的輔導員，請聯絡聯邦選舉委員會的任何成員，由他們為您指派一名新副師。這時 RFC 會回到 draft 階段。

結束條件：RFC Author 表示希望在 RFC 上恢復執行中的工作；對 RFC 的 CL 發表了註解，表示 RFC 已不再處於保留狀態。

如何做出決策

工程委員會會決定是否要接受 RFC，會彼此大致達成共識。如果決策涉及的 RFC 中，有 Eng Council 成員為作者，這些成員必須對決策者予以拒絕。

如果工程委員會無法達到概略共識，就不會接受 RFC。在決定是否接受 RFC 時，工程委員會會考量下列因素：

• RFC 是否推動專案目標？
• RFC 是否堅持專案價值？
• 是否在討論中適當地代表所有相關利害關係人？
• 如果有任何利害關係人反對，工程委員會能否完全瞭解推拒說詞？

工程委員會的決策可提報給專案的管理機關。

RFC 修訂程序

如果符合下列條件，則可修改現有的 RFC：

• 說明已核准的內容。
• 機械修訂條款，例如更新連結、說明文件、使用方式等
• 之後發現設計有任何改善或微幅變動，例如在實作期間加以改善。

對於設計方面的變更，請點出最初的設計目標，以及原因和變更方式。

如果設計有重大變更，請提交新的 RFC。

• 在新版 RFC 中，請參照原始 RFC，並明確指出標題中的變更類型，例如附加條款。
• 如果原始 RFC 中的設計已淘汰，請修改原始 RFC 以呼叫此方法，並參照新的 RFC。
• 如果多個 RFC 對同一區域進行了變更，請建立新的 RFC 編譯現有 RFC。請一併修改現有的 RFC，以參照新的 RFC。

如果 RFC 程序正在更新，請一併更新 RFC 程序頁面。

說明文件

這個 RFC 可做為 RFC 程序的說明文件。

缺點、替代方案與不明

實作本提案的主要成本，是導入正式的決策程序可能會拖慢決策速度。此程序可能會比某些類型的決策更費時。

原始碼存放區中的記錄決策會使這些決策更難變更。在某些情境下，這個效果可能會是正面的，但在其他情況下，也有可能是負面影響。

「何時應使用程序」一節中的條件嘗試藉由將流程範圍限定為並行情況，來緩解這項缺點，但這類範圍的界定會具有偽陽性和偽陰性。

要解決基礎問題有很多可能的替代策略。舉例來說，我們可以採用以同步會議為中心的決策程序，但這樣的流程很難擴充至全球的開放原始碼專案。我們也能選用不同的決策機制，在各方方面均衡取得共識或更公平的做法。

既有藝術品和參考資料

針對開放原始碼專案的決策過程，有大量的過往知識。此提案受到下列現有程序影響：

• IETF RFC 程序IETF 已執行大規模的大規模決策程序。本文件所述的程序會從 IETF 程序取得多個概念，包括部分術語。

• Rust RFC 程序。Rust 社群執行的是 RFC 程序，這對一些類似的軟體工程專案相當有效。本文件所述的程序是在 Rust RFC 程序完成後的公平地建立模型。

• 閃爍意圖實作程序。Chromium 專案會執行決策程序，指出影響網頁的行為。本文所述的程序是以我 (一手) 設計及執行該程序一段時間的經驗為依據。

• FIDL 調整提案。Fuchsia 專案透過類似的程序直接決定 FIDL 語言。這樣的提案之所以存在，是因為決策過程成功。