Fuchsia RFC 程序

Fuchsia RFC 程序，已自以下 RFC 發展而來：

這個頁面會彙整上述 RFC，並擷取目前程序。

瞭解這項程序後，您就可以按照這份指南建立 RFC。

摘要

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

提振精神

RFC 程序會建立一致且透明的路徑，以便制定適用於整個專案的技術決策，並確保每項決策涉及適當的利害關係人。

設計

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

流程的使用時機

RFC 程序可用於任何對於 Fuchsia 的變更，若因為其結構化方法有助於做出決策、從工程顧問進行提報支援和/或長期的決策記錄。

大多數的變更都require 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 Authors。RFC Author 是撰寫 RFC 的人員。對 Fuchsia 的貢獻者都可以是 RFC Author。特定 RFC 可以有一或多位作者。指定 RFC 的作者驅動該 RFC 的程序。

  • 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 意見回饋的利害關係人，但其 +1 或 -1 在 FEC 決定接受或拒絕 RFC 時不會列入考慮。

運作方式

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

步驟 1：找出問題

RFC 程序的第一步是找出問題，並將問題連結至專案。其他人是否注意到這個問題？可能有其他人已在處理這個問題，或是可能已針對此問題提供了一些實用背景或背景資訊。越早發現這項資訊 越能掌握成效

請注意，進行這個步驟前，您不需要修正或正式編寫問題陳述式。最好盡早開始社交互動，以便收到意見回饋，瞭解這個想法是否可行，以及相關方向是否正確。這可能節省作者的時間和精力，以免這個概念無法具體化，或方向是否需要大幅改變。

在這個程序階段，所使用的通訊方法沒有任何限制。雖然 RFC 的正式寫入最終會將形狀視為使用 Gerrit 程式碼變更審查的 Markdown 檔案，但作者仍應使用此階段覺得實用的任何媒介。

退出條件：作者已清楚瞭解他們想要解決的問題，「或是」作者認為這個問題不需要 RFC 程序。

步驟 2：問題陳述

作者應簡單說明要解決的問題。可以是任何適合討論的格式，且應提供足夠資訊，讓讀者判斷哪些 Fuchsia 子系統可能會受到影響。這個問題陳述式應針對目前已知的任何需求，但稍後可能會提供更多。也應清楚指出任何「非目標」，避免範圍降低。

退出條件：作者以電子郵件將問題聲明寄到 Eng Council (FEC)。

步驟 3：指派講師

工程委員會負責指派講師。本講師是 RFC 作者提供的資源，可修正問題敘述並找出相關利害關係人。輔導員也會建議作者，瞭解這個問題是否需要或受益於正式的 RFC 寫入。在某些情況下，講師可能會建議作者在 RFC 程序之外繼續設計及實作。

離開條件：已獲派講師，作者則會收到講師電子郵件通知。

步驟 4：找出利害關係人

在這個階段，RFC 作者應指明此 RFC 的利害關係人。 作者可能會請講師在過程中給予建議。利害關係人名單應隨問題敘述一起寫下。這可能是在 Google 文件中進行，或者作者可以選擇建立具有大部分 RFC 範本的 RFC CL，並填寫其利害關係人章節。

注意：如有需要，作者或講師可視需要在程序的後續流程中新增或移除利害關係人。

離開條件：作者和講師同意一組利害關係人，且相關人員會記錄在 Google 文件或包含 RFC 範本的變更清單中。

步驟 5：社交

在此階段，請找出問題的解決方案，以及每個解決方案的優缺點。與相關人員交流這些解決方案，並採納他們的意見回饋。如果您不確定如何社交，可以向講師或技術部門主管尋求建議。他們通常較擅長社交想法，或許能夠為您提供理想方向。

範例：這個 RFC 的宗旨是在工程論壇上進行討論，這是 Google 定期舉辦的會議，由參與其中的各項工程領袖開會。RFC 還與 FTP 和 CTP 程序的創作者進行社交交流，他們擁有關於這些程序的良好背景和背景資訊。

退出條件：作者認為作者有足夠的資訊可繼續操作。 這是否由作者自行斟酌。如果他們認為達成目標，可以採取下列幾種做法：

  • 設計原型。如果社交化階段提出不同的做法，且權衡取捨，作者可能會選擇建構原型，以更準確地評估這些選項。這種原型有助於進一步社會化。
  • 保留 RFC 程序。如果作者 (可能透過輔導員協助) 認為這個問題不需要 RFC 或受益於 RFC，他們可以繼續透過程式碼審查程序建構解決方案。作者也可以選擇非正式發布設計文件。
  • 書面。前往步驟 6。

步驟 6：草擬及疊代

一旦作者收集到能夠透過社群媒體取得的所有背景和背景資訊，就可以開始執行 RFC 程序的正式階段。下一步是編寫 RFC 文件本身的草稿。早期草稿和意見回饋可能會發生在 Markdown 之外 (例如在 Google 文件中)。不過，如果這個程序稍後有正式的 RFC 寫入，我們強烈建議將相關背景資訊從更動態的媒介轉移至 Markdown 中的 RFC 寫入。舉例來說，來回的對話可能會新增其他「考量到替代項目」的項目。

作者準備就緒時，應從 RFC 範本開始建立 CL，將檔案新增至 //docs/contribute/governance/rfcs 目錄。

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

在這個階段中，請不要擔心如何將數字指派給 RFC，請改用 NNNN 做為預留位置。例如，檔案名稱應類似於 NNNN_my_idea.md。RFC 會在到達前不久取得號碼。

提示：如需 RFC 的草擬及疊代相關建議，請參閱 RFC 最佳做法文件。

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

作者應邀請相關人員針對 RFC 提供意見，方法是將他們加入 CL 中的「審查人員」(適用於需要 +1 的相關人員) 或「CC」欄位 (適用於「顧問」利害關係人)，就像一般的程式碼審查一樣。此外，作者可以透過電子郵件將其 CL 傳送至 eng-council-discuss@fuchsia.dev，徵求其他意見回饋。利益相關者應在程式碼審查工具中留下 RFC 註解來提供意見回饋。

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

如果討論對程式碼審查工具而言太過複雜，或是花費的時間超出預期，請考慮安排與相關相關人員開會，以便提升討論效率。會議結束後，您必須在 CL 註解中張貼會議摘要，讓未參與會議的使用者瞭解會議期間討論的內容。

如果作者在討論期間遇到任何問題或延誤，講師可協助解決問題。以下是這些討論中常見的問題：

  • 討論內容沒有意義或沒有幫助。相較於文字式的通訊，面對面會議通常更能有效率地重新進行討論。
  • 利害關係人過度搞怪 (填補者)，或者造成討論 (非回應)。有時利害關係人不喜歡提案，但沒有明確的技術論點和手段，也許更是不自意地說，這些偏誤的說服力。
  • 收到許多人的意見、建議和拒絕，但不確定哪些評論是由相關人士提出。這類意見中通常與核心問題無關，而且不會阻擋 RFC。
  • 討論時間太長。

如果討論內容沒有問題，或是您收不到相關人員的意見回饋，請通知您的講師。講師可以協助繼續討論，例如提供額外的架構參與討論，或將討論移至其他論壇，例如同步會議或工程評論。無論討論如何進行，所有排除的 CL 討論結果都必須擷取到 CL，通常以 CL 註解的形式張貼討論摘要。

意見回饋可能包含非利害關係人的意見。作者應視情況回覆這些註解，但設定後不一定要移至「Last Call」階段。如果意見指向反對誰是利害關係人，FEC 就能協助解決。

如果問題不再與其相關，或者作者和利害關係人同意問題並不會保證 RFC，作者可在此階段撤銷 RFC。在這種情況下，作者應將包含 RFC 的 CL 標示為放棄。如果情況改變，作者或其他人員隨時可以恢復您的 RFC。取回由他人建立的 RFC 時，您應從頭開始啟動 RFC 程序，但您可以將已繪製的 RFC 當做起點，而不是使用 TEMPLATE.md。請與原始作者討論，確認他們是否希望繼續將名稱與 RFC 中的新入權相關。

給審查人員的注意事項：RFC 程序的用意是鼓勵各種觀點和充滿活力的討論。在公開論壇中提交負面意見通常並不容易。如有需要，審查人員可以向待開發客戶、同業人員或 Eng Council 尋求協助。

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

離開條件：RFC CL 將送交審查，要求意見回饋再納入 RFC CL OR RFC 中。

步驟 7：上次通話時間

當 RFC 上的討論開始收斂後，作者必須請導師將 RFC 的狀態移至上次呼叫。講師會在追蹤工具中將 RFC 標示為上次呼叫，然後自動產生電子郵件至 eng-council-discuss@fuchsia.dev，並對 CL 提出評論，要求所有最終的意見回饋再進入決策步驟。RFC 會在接下來 7 天內開放收到意見回饋。

一般而言，審查人員會以 +1 表示簽核，講師則會以 +2 表示登出。如果受諮詢的利害關係人想要表達對 RFC 的熱情，也可以使用 +1 或 +2 登出。

想要物件遵循 RFC 的相關人員可以根據使用者對 RFC 向前的感受，將 Code-Review 標記設為 -1 或 -2。將 Code-Review 標記設為 -1 或 -2 時，利害關係人必須說明拒絕原因，最好的方式是讓某人清楚瞭解推拒原因，而不需要完整閱讀先前推拒的論述。

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

所有利害關係人都使用程式碼審查旗標後，請傳送電子郵件至 eng-council@fuchsia.dev，提示 Eng Council 決定是否接受您的 RFC。

結案標準：所有相關人員的意見回饋；所有意見皆獲得解答。

步驟 8：提交

若專案決定接受 RFC，Eng Council 的成員會對您的 CL 加註，表示已接受 RFC 並指派 RFC 編號 (通常為系列中的下一個可用數字)。如有任何 -1 或 -2 Code-Review 標記，Eng Council 會總結推拒說辭，並說明 RFC 向前邁進的原因，明確清除每個標記。Eng Council 會說明是否需要在 RFC 中記錄任何其他資訊，例如改用其他方法的理由或優缺點。

若專案決定拒絕您的 RFC，Eng Council 的成員會在您的 CL 上發表評論，指出 RFC 遭拒，並提供拒絕理由並說明 RFC 編號。遭拒的 RFC 是相當實用的工程構件。英國委員會將與 RFC 作者合作，制定標示為已拒絕並納入合理原因的 RFC 版本。

在極少數的情況下，如果工程委員會識別出一或多個未解析的開啟項目，RFC 可能會移回「草稿」階段。針對與相關利害關係人識別的開放項目，Eng Council 將要求作者解決與 RFC 有關的待處理項目。

您應上傳包含指派的號碼的新 RFC 修補集，包括 RFC 標題和檔案名稱中的修補程式集。如果您的 RFC 已獲核准且需要實作，請確認您已在 Issue Tracker 中提交問題，並在 RFC 標頭中附上該問題的連結。

接著，Eng Council 會標記您的 CL Code-Review +2，您就可以導向 RFC！

恭喜！您向專案貢獻了一項寶貴的工程構件！

離開條件：獲派 RFC 編號；結合任何適用理由、權衡取捨與 Eng Council 的意見回饋；已合併 RFC。

保留中

如果您目前還不想將 RFC 往前邁進 (例如優先事項已轉移過)，或是 RFC 試圖解決的問題已不敷使用，您可以將 RFC 移至「待定」狀態。當 RFC 處於「待定」狀態時，利益相關者應該不會提供意見回饋，FEC 也不會主動協助處理進度。

如果當月 RFC 的 CL 沒有顯示進度，RFC 機器人會傳送電子郵件給您和講師，討論是否要將 RFC 移至「待定」狀態，或是如何使 RFC 前進。在理想情況下，如果遇到難題或延遲的情況，應該先將情況提報給客服人員，但這次對話也是能夠發現這些問題的好時機。

您隨時可以與講師聯絡，告知對方您打算恢復使用 RFC，藉此將 RFC 從「待定」狀態移出。如果您需要新協助人員，請與 FEC 的任何成員聯絡，他們可以為您指派新的臉部護理人員。屆時，您的 RFC 會移回「草稿」階段。

離開條件：RFC Author 指出其有意恢復在其 RFC 上的現有工作；RFC Author 上對 RFC 的講師評論，指出 RFC 已不再處於保留狀態。

Google 如何做出決策

是否接受 RFC 是由 Eng Council 的決定，會彼此進行共識。如果決策涉及將 Eng Council 成員設為作者的 RFC，這些成員必須駁回裁決。

如果工程委員會無法達成概略共識，就不會接受 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 專案會針對影響網頁的行為執行決策程序。本文件所述的程序，是我 (快樂) 協助設計及執行該程序一段時間的經驗。

  • FIDL 調整提案。Fuchsia 專案採用類似的程序，並能直接決定 FIDL 語言。這項提案的存在，是因為該決策程序的成功。