| RFC-0017：FTP 程序已死，RFC 程序萬歲！ | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 停止 FIDL 調整程序，並整合至 RFC 程序。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-12-14 |
| 審查日期 (年-月-日) | 2021-02-08 |
摘要
這項 RFC 終止了 FTP 程序、將現有 FTP 併入 RFC，並修訂了 RFC 程序，如下所示：
- 在社交階段，鼓勵使用比程式碼審查更動態的媒介；
- 要求使用 RFC 範本，並將特定領域的部分納入此 RFC 範本；
- 正式確認各領域的條件；
- 讓 Fuchsia 工程委員會 (FEC) 更積極地參與利害關係人識別作業；
- 新增 FEC 主持的會議，討論 RFC，並設定觸發會議的特定條件；
- 作者可自行決定是否提交，FEC 會在 7 個工作天內提供權威解答。
提振精神
2020 年 2 月推出 RFC 程序後，凡是符合 FTP 條件的 FIDL 變更，技術上都需要 RFC。事實上，自此接受或拒絕的各種 FTP 並未重複進行 RFC 程序：這兩個程序都以類似目標為目標，且形式和審查的正式程度相似。
不過，我們希望統一技術變更的審查程序，因此打算停用 FTP 程序，改用 RFC 程序。
在 FTP 流程運作的兩年半期間，a success，我們也希望將從中學到的經驗帶入 RFC 流程。
設計
我們會先調查 FTP 程序和 RFC 程序之間的差異，然後提出一組 RFC 程序修正內容。
最後，我們說明如何將所有 FTP 併入 RFC，進一步集中管理 Fuchsia 技術決策的所有構件。
這兩個程序的差異
中
FTP 流程並未規定媒介，作者可自由選擇最適合的媒介，但必須遵守範本規定。在實務上，所有 FTP 都是以 Google 文件的形式開始，直到獲得核准或遭到拒絕為止。此時，這些文件會轉換為 Markdown 文件，並提交至 Fuchsia 來源樹狀結構。最後的編輯和潤飾通常是在轉換期間完成。
RFC 程序規定必須使用 Gerrit 變更 (又稱 CL) 做為媒介，並要求使用後續的變更修補程式集進行疊代，同時邀請利害關係人擔任變更審查員。
作者認為，在 Google 文件中輕鬆加上註解、提出編輯建議或進行變更，有助於進行良性的技術討論。許多 RFC 實際上是在社交化階段，從 Google 文件開始撰寫，因此草稿更接近最終文件。如果選擇透過 Gerrit 以外的媒介進行宣傳，請務必避免任意限制目標對象。舉例來說，Google 文件應設為「可供所有人存取」。
Template
FTP 程序嚴格要求使用 FTP 範本，並要求填寫所有部分，即使只是明確說明「不適用」也一樣。
由於 FTP 範本專為 FIDL 設計，因此會提出專為這個領域量身打造的探查問題。為因應新需求，FTP 範本會隨著時間演進。舉例來說，RFC-0024：強制原始碼相容性中新增了原始碼相容性影響的特定附註。這個更嚴格的格式和特定問題，有助於 FTP 作者和審查人員確保設計完整。
審查
FTP 程序通常會在一或多場實體會議中審查提案。雖然也可以使用非同步審查機制 (例如 Gerrit 變更的註解)，但這並非常態，而是例外情況。
RFC 程序鼓勵採用非同步審查機制，如果討論內容過於複雜，建議作者安排會議。
這裡的重要區別在於，FTP 審查會議是由 Fuchsia FIDL 團隊主辦和安排，而 RFC 程序則要求作者安排會議。作者和流程推動者 (FIDL 團隊、Fuchsia 工程委員會) 之間可能存在重要資訊不對稱。如果將籌備審查會議的責任交給作者，而非流程負責人，就會增加額外障礙，尤其是在需要瞭解專案機構並知道要邀請誰時，可能難以克服。
條件
FTP 程序有特定條件，必須符合條件才能使用。
同樣地，RFC 程序有特定使用條件，且後來還加入了 Zircon 的特殊考量。
決策
FTP 程序仰賴 Fuchsia FIDL 團隊做出決策，最終決策者為 Fuchsia FIDL 團隊領導人。
RFC 流程仰賴相關利害關係人表示核准或拒絕，並由 Fuchsia 工程委員會 (FEC) 做出最終決定。
這兩種決策方法類似，特別是考慮到 FIDL 團隊會是所有修改 FIDL 的 RFC 的主要利害關係人。其中一項重要差異是，FTP 程序需要「推送模型」，作者必須將設計提交給 FIDL 團隊。RFC 程序比較偏向「提取模型」，FIDL 團隊有責任主動參與相關設計，爭取發聲機會。
服務水準協議 (SLA)
FTP 程序有特定的服務等級協議，可提供權威答案 (「五個工作天」)。這是特別在 FTP-049 的疊代階段中新增，有人留言表示「從 FTP 作者的角度來看，最好能知道 FIDL 團隊何時會對 FTP 做出決定」。
目前 RFC 程序沒有服務水準協議。
編號
啟動 FTP 時，FTP 程序會指派序號。
RFC 流程會在接受或拒絕 RFC 時，指派序號。
提案請求 (RFC) 程序修訂
中等：在社交階段，RFC 程序應提供比程式碼審查更動態的媒介，例如 Google 文件或其他媒介。可以說，這項異動並未變更 RFC 程序，因為 RFC 程序只規定在程序的正式部分使用 Gerrit 變更，但在 RFC 的社交階段承認並鼓勵使用其他媒介，或許可以消除困惑。
RFC 程序也應大力鼓勵將動態媒體中的相關脈絡帶入 RFC 撰寫內容。舉例來說，來回對話可能會導致系統新增額外的「考慮的替代方案」項目。
範本：RFC 程序應要求使用範本。每個領域可能都有相關的探查問題或應納入提案的部分。
範本：FTP 專用 RFC 範本應擴增，納入 FTP 範本的特定內容，供觸及 FIDL 領域的 RFC 使用。
RFC 條件：建議各領域提交額外條件，說明應遵循各自領域 RFC 的時機。如果某個領域有相關標準，FEC 會確保適當的利害關係人參與其中。可以說，這並非 RFC 程序的變更，因為只要提交 RFC 即可修正程序，例如 Zircon 的做法。不過，我們認為簡化所有領域的標準存在，將有助於更多領域明確指出對他們而言「重要」的事項。除了確保這些領域適當參與外，這項做法還能記錄變更的相對重要性。
RFC 準則：FTP 專屬 RFC 程序應包含 FTP-049 中針對 FIDL 領域所列的準則。
利害關係人：雖然 RFC 作者應盡力找出利害關係人，但 FEC 也應積極參與利害關係人的判斷。RFC 作者應在程序初期向 FEC 要求找出所有利害關係人，以降低在提交步驟中發生意外的可能性。
工程審查會議：如果 RFC 需要更多宣傳，FEC 會安排工程審查會議。以下是安排工程審查的一些觸發條件：
- 難以找出相關利害關係人。RFC 可能會收到許多意見、建議和反對意見，而作者不清楚該如何處理這些意見回饋，以及哪些是可能導致 RFC 無法通過的核心意見回饋，哪些是可能出於好奇或與未來計畫相關的輔助意見回饋。
- RFC 作者和利害關係人難以就未解決的問題達成共識。
提交：RFC 程序應允許作者要求 FEC 進行審查，而不是在對話匯集時限制提交 RFC，因為在某些情況下，作者可能難以識別。如果提出這類要求，FEC 必須在七 (7) 個工作天內，向作者提供正式回覆。答案是：
- 核准或
- 拒絕，或
- 未解決的待處理事項：FEC 發現一或多個未解決的待處理事項，並要求作者與相關利害關係人解決這些事項，之後才能再次要求審查 RFC。
將 FTP 摺疊成 RFC
在機制上，如要將 FTP 併入 RFC，我們將採取下列做法：
請按照現有 RFC，將所有 FTP 重新編號為連續編號。舉例來說，撰寫本文時，FTP-001 會成為 RFC-0017。
更新每個 FTP 撰寫內容，將 RFC 編號顯示為主要標題，同時保留先前的 FTP 編號。記錄舊編號很重要，因為許多 Git 提交或錯誤都會依編號參照 FTP。
基於參考原因，我們會想保留 FTP 程序的存在痕跡 (例如本 RFC 中的許多連結)。
日後，已轉換為 RFC 的 FTP 應以 RFC 編號 (而非歷史 FTP 編號) 參照。
實作
請保持冷靜，並按照程序操作。
效能、安全性、隱私權和測試注意事項
這項提案預期會對效能、安全性、隱私權和測試考量因素產生正面影響。
說明文件
我們需要更新：
- 所有 FTP。
- Markdown 和程式碼註解中的所有 FTP 參照。
- FIDL 管理專區。
- RFC 程序摘要頁面。
缺點、替代方案和未知事項
在同一個技術專案中保留兩個大致相同的正式程序，會造成混淆。我們不認為維持現狀是替代方案。
上述提案的 RFC 程序修正內容可分別評估。我們相信這些異動都能帶來正面效益。
既有技術和參考資料
本 RFC 會將 RFC 程序與 FTP 程序 (即 FTP-001：適當提案和 FTP-049：FIDL 調整程序演進) 合併。