Fuchsia RFC 程序

Fuchsia RFC 程序已由以下 RFC 所發展：

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

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

摘要

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

提振精神

在 RFC 流程之前，Fchsia 專案沒有正式的程序，可用於制定適用於整個專案的技術決策。就目前的規模而言，這種非正式做法會導致不同人對於專案目的地和系統的整合方式，擁有不同且有時不一致的觀點。在針對整個專案製定技術決策時，我們可以透過建立一致且透明的路徑，讓所有相關人員都能安心瞭解專案的技術方向。

設計

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

使用程序的時機

RFC 程序可用於任何對 Fuchsia 的異動，前提是其結構化做法有助於制定決策，以及其長期的決策記錄。

大多數的變更都不需要require RFC。不過，您可以使用程式碼審查程序來進行變更。然而，技術決策會對整個專案造成廣泛影響，因而需要更廣泛的協議，而且必須透過 RFC 程序與專案交流。

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

  • 為日後的開發作業新增限制。有些決策一旦制定，就會對系統的未來發展造成阻礙。我們必須謹慎做出這些決定，因為日後可能難以修改。

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

  • 變更系統架構。系統架構說明瞭系統如何融入整個系統。根據定義改變系統架構，子系統之間的邊界會跨越子系統，而且需要與許多相關人員謹慎進行協商。

  • 委派決策權。有時專案需要頻繁做出決策，而這些決策會因專業專業知識而受益。專案可以將這些決策類別的決策授權委派給其他群組或程序，而不是透過 RFC 程序做出所有決定。例如，我們通常需要對平台 API 做出決策，因為平台 API 會對未來的開發增加限制，但對每個平台 API 的每一個變更都使用 RFC 程序並不實際。

  • 提報。最後，內容異動容易受到 RFC 程序的透明化及清晰易懂。如果對技術方向有歧異，且個別技術領袖無法解決，則由一位不同意的一方或其他貢獻者將決定提報至 RFC 程序。

除了上述一般注意事項之外，部分區域也宣告了其他條件。如有需要，請參考以下文件：

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

其他對 RFC 程序有益的變更，則是需要手動或自動大規模變更程式碼集的變更。例如記錄寫入方式或錯誤路徑的處理方式。目標不是跟在一致性的島嶼上，而是要找出最佳模式，並統一套用到整個程式碼集。

角色與責任

使用者可以在多個角色中與 RFC 程序互動：

  • RFC Authors。RFC Author 是撰寫 RFC 的人員。凡是為 Fuchsia 貢獻者都能擔任 RFC 作者。指定的 RFC 可以有一或多位作者。特定 RFC 的作者驅動該 RFC 的程序。

  • Eng Council：Eng Council (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 程式碼變更來審查的 Markdown 檔案，但在社交階段使用比程式碼審查更動態的媒介 (例如 Google 文件或其他項目)，或許會有幫助。假使選擇其他媒介進行社交，我們強烈建議將較動態媒介的相關內容轉移至 RFC 寫入。例如，來回對話可能會增加其他「考慮的替代項目」。

與程序中其餘步驟相比，這個步驟相對來說較為正式。本文並未針對如何社交您的想法提供嚴謹的說明。與他人交流技術想法本身是不夠的。 不過，一個很好的開始，就是在討論與嘗試解決的問題相關的技術主管時，提出討論主題。舉例來說，您可能會想諮詢 OWNERS 檔案中的人員，瞭解程式碼集的部分需要修改才能執行想法。

在這個階段中，RFC 作者應開始找出這個 RFC 的利害關係人。

如果不確定如何社交您的想法，請考慮向技術主管尋求建議。他們通常有更深入的交流經驗，或許能協助您找到最佳方向。

範例。在 Eng 論壇中，您可以與 Google 內部成員討論參與專案的不同工程部門主管，討論這個 RFC 的社交用途。RFC 也與 FTP 和 CTP 程序的製作者合作，對這些程序有良好的背景和背景資訊。

離開條件：未指定。這取決於作者是否可自行斟酌。 這個步驟可以幫助作者精準掌握目標和可能的解決方案。 如果使用者認為已達成這個目標，就可以繼續進行下一個步驟。

步驟 2：草稿

收集到所有背景與背景資訊後，即可透過社交功能來開始執行正式的 RFC 程序。下一步是撰寫 RFC 文件本身的第一個草稿。

實際上，RFC 是 //docs/contribute/governance/rfcs 目錄中的 Markdown 檔案。如要建立 RFC，您必須建立 CL，將檔案新增至該目錄。您必須先複製 RFC 範本。這個範本的目的是協助您思考要以半結構化方式解決問題的問題，進而編寫高品質的 RFC。

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

在這個階段，您不必煩惱將數字指派給 RFC，請改用 NNNN 做為預留位置。例如，檔案名稱應像 NNNN_my_idea.md 類似格式。RFC 會在抵達目的地不久前取得一個數字。

RFC 作者應在諮詢 RFC 區域的專家時，建議一組初始相關人士。利害關係人一開始可能會留空或不完整。如果有任何歧義，客戶應諮詢 FEC，以協助找出利害關係人。

提示：如需關於 RFC 草稿與疊代作業的建議，請參閱 RFC 最佳做法文件。

建議。建議將包含 RFC 的 CL 標示為「工作中」，直到您準備好提供意見回饋為止。

上傳 CL 就足以獲得指派給 RFC 的講師。FEC 會監控新的 RFC CL 做為信號，找出新 RFC 的合適協助者。

建立含有 RFC 第一個草稿的 CL 後，您就可以和適當的相關人員一起疊代您的構想。希望您在社交提案的過程中已找到了最適當的利害關係人，但您很有可能在這個階段發掘其他相關人員。RFC 作者應向 FEC 要求識別程序初期的所有利害關係人，以降低提交步驟出現意外狀況的可能性。

原則上，您應該邀請相關人員對 RFC 提供意見回饋，方法是將對方新增至 CL 的「審查者」(適用於需要 +1 的相關人員) 或「CC」欄位 (適用於「諮詢」的利害關係人)，就像進行一般程式碼審查一樣。此外，您也可以將 CL 傳送電子郵件至 eng-council-discuss@fuchsia.dev 尋求其他意見回饋。相關人員應在程式碼審查工具中，針對您的 RFC 留下註解，以提供您的意見回饋。

任何人都可以對 RFC CL 評論 (包括自己在內) 提議其他利害關係人，但不一定每次都會接受這些提案。如果協議涉及廣泛協議，RFC 作者應新增利害關係人。美國聯邦選舉委員會 (FEC) 也可能會要求作者新增利害關係人。

利害關係人可選擇「選擇退出」並要求移除，或將評論委任給相關領域的其他專家。FEC 可要求移除利害關係人，或從「審查者」移至「受管」。

如果討論對程式碼審查工具而言太過複雜，或處理時間超出預期，您可以考慮與相關相關人員安排會議，以便更有效率地進行討論。會議結束後，您必須在 CL 留言中張貼會議摘要，讓非會議參與者瞭解會議期間討論的內容。

如果您在討論期間遇到任何問題或延遲情形，請告知您的講師。以下是這些討論期間的常見問題：

  • 討論會成為內容主題或沒有幫助的討論。與文字通訊相較，面對面會議通常可以更有效率地回歸討論議題。
  • 利害關係人過度擬真 (灌木叢) 或攤位討論 (無回應)。有時利害關係人不喜歡提案，但並沒有明確的技術論點和渡假村，這些爭執導致這些延遲。
  • 您收到許多來自許多人的意見、建議和推拒說辭，並不確定哪些評論來自相關相關人員。這類意見回饋通常與核心問題無關，不會阻礙接受 RFC。
  • 大家都花太多時間集中討論。

如果討論內容有爭議，或是無法順利取得利害關係人的意見回饋，請通知講師。講師可以協助推動討論，例如提供額外的討論結構，或將討論移至其他論壇，例如同步會議或工程審查。無論討論如何繼續，任何非 CL 討論的結果都必須在 CL 記錄中記錄，通常以 CL 註解的形式張貼討論摘要。

意見回饋可能包含非利害關係人的留言。作者應視情況回應這些註解，但不必設定註解就能移至「上次通話」階段。如果註解指出「誰是利害關係人」，FEC 可以協助解決這個問題。

如要撤銷 RFC，您可以將含有 RFC 的 CL 標示為已放棄。您或其他人隨時可以在情況改變時取回 RFC。如果重新處理其他人建立的 RFC，建議從頭開始執行 RFC 程序，但您可以將撤銷的 RFC 做為起點使用，而不要使用 TEMPLATE.md。請與原始作者聯絡，確認他們是否希望繼續將姓名與 RFC 的新組成相關。

給審查人員的注意事項：RFC 程序的用意是鼓勵各種觀點並熱烈進行討論。通常在公開論壇中提出負面意見回饋可能並不容易。如有需要，審查人員可以聯絡自己的待開發客戶、同儕或工程委員會，協助他們制定意見回饋，以便在 CL 中有效送達。

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

退場標準：經 Eng Council 識別並核准的所有相關人員；徵詢及整合意見。

步驟 3：上次通話

一旦 RFC 上的討論結束，作者必須要求講師將 RFC 的狀態移至「上次呼叫」。負責人會在追蹤工具中將 RFC 標示為最終呼叫，以便自動產生電子郵件至 eng-council-discuss@fuchsia.dev，並會在 CL 中加註，在進入決策步驟前徵求最終意見回饋。RFC 會在接下來 7 天內開放提供意見。

審查人員通常會使用 +1 號進行署名，講師需要按下 +2 號進行簽署。如果受諮詢的利害關係人想表達對 RFC 的熱忱，也可以按下 +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。

退出標準：所有利害關係人提供的意見回饋；所有意見均已回答。

步驟 4：提交

若專案決定接受 RFC，Eng Council 的成員會為您的 CL 加註，指出接受 RFC 並會指派 RFC 編號，通常是系列中下一個可用的編號。如果有任何 -1 或 -2 Code-Review 標記，Eng Council 會總結客戶推拒說辭，並描述 RFC 往後的推拒原因，都會明確清除每個標記。工程委員會會指示是否需要在 RFC 中記錄任何其他資訊，例如採取其他做法或取捨的理由。

若專案決定拒絕您的 RFC，Eng Council 的成員會為您的 CL 加註，指出 RFC 遭到拒絕，提供拒絕理由並指派 RFC 編號。遭拒的 RFC 是有價值的工程構件。工程委員會會與 RFC 作者合作，輸出標示為已拒絕的 RFC 版本並納入理由。

在極少數的情況下，如果工程委員會發現一或多個未解決的開放項目，RFC 可能會移回「draft」階段。工程委員會會要求作者解決相關利害關係人所識別的開放項目，之後才會核准其他對 RFC 的審查要求。

您應該在 RFC 的標題和檔案名稱中，上傳含有指定編號的新 RFC 修補程式集。如果您的 RFC 已獲核准且需要實作，請確定您有在 Issue Tracker 中回報問題，並在 RFC 標頭中加入該問題的連結。

接著，Eng Council (Eng Council) 會標記您的 CL Code-Review +2，代表您的 RFC！

恭喜！您在專案中貢獻了寶貴的工程構件！

離開條件：指派的 RFC 號碼；納入任何適用的理由、取捨和 Eng Council 意見回饋；已合併 RFC。

保留中

如果您目前不感興趣，例如因為優先順序已改變，或 RFC 目標解決的問題已無法解決，因此不想要繼續推動 RFC 處理，您可將 RFC 移至On Hold 狀態。當 RFC 處於保留狀態時，利害關係人應該不會提供意見回饋，且 FEC 不會主動協助處理進度。

如果一個月內，RFC 的 CL 進度皆未呈現，RFC 機器人將傳送電子郵件給您和您，請他們討論是否要將 RFC 移至「On Hold」狀態，或如何移動 RFC。在理想情況下，如果您遇到困難或延遲的情況，應在此之前將問題提報給講師，但這也是找出這些問題的好時機。

您隨時可以與轉接器聯絡，告知他們您打算繼續處理 RFC，藉此將 RFC 從「待定」狀態移出。若您需要新的協助，請聯絡 FEC 的任何成員，他們可以為您指派新的連結器。此時，您的 RFC 將移回「draft」階段。

離開條件：RFC Author 表示希望在 RFC 上恢復運作；如果是 RFC 的 CL 註解，表示 RFC 不再處於保留狀態。

決策方式

是否接受 RFC 是由工程委員會 (Eng Council) 決定是否接受 RFC，並互相大致共識。如果決定涉及 RFC 將 Eng Council 成員為作者，這些成員必須拒絕自己做出決定。

若 Eng Council 無法達成大概的共識，我們不接受 RFC。在決定是否要接受 RFC 時，Eng Council 會考量下列因素：

  • 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 程序之後會以完全直接的建模方式建立。

  • Blink 意圖導入程序。Chromium 專案會針對影響網頁的行為執行決策程序。本文件中描述的程序，都是根據我的 (abarth) 經驗，協助設計及執行該程序一段時間。

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