| RFC-0017：FTP 程序已終止，RFC 程序萬歲！ | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 停止 FIDL 調整程序，並將該程序整合至 RFC 程序。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-12-14 |
| 審查日期 (年-月-日) | 2021-02-08 |
摘要
這份 RFC 會停止 FTP 程序、將現有的 FTP 摺疊至 RFC，並修訂 RFC 程序，如下所示：
- 鼓勵在社交階段使用比程式碼審查更具動態性的媒介；
- 要求使用 RFC 範本，並在該範本中加入地區特定部分。
- 正式規定各個區域的條件。
- 讓 Fuchsia Eng Council (FEC) 更積極地參與利益相關者識別作業；
- 新增 FEC 協助會議，討論 RFC，並設定特定觸發條件來要求召開會議。
- 作者可自行決定提交步驟，FEC 的權威答案服務水準協議為七個工作天。
提振精神
2020 年 2 月推出RFC 程序後，如果 FIDL 的變更符合 FTP 標準，則在技術上也需要 RFC。實際上，自此之後，已接受或拒絕的各種 FTP 都沒有重複通過 RFC 程序：兩個程序的目標相似，且形式和審查程度也相近。
不過，我們希望將 Fuchsia 整合為單一審查程序，以便進行技術變更，因此我們打算停止使用 FTP 程序，改用 RFC 程序。
在兩年半的運作期間，FTP 程序已取得成功，我們也希望將一些經驗教訓運用到 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 Eng 委員會) 之間可能存在重要資訊不對稱情形。將安排審查會議的責任交給作者，而非負責推動程序的人員，會帶來額外的障礙，這可能不容易克服，尤其是當需要瀏覽專案組織並瞭解要邀請誰時。
條件
FTP 程序有特定條件，可決定何時應使用這項程序。
同樣地，RFC 程序也針對應使用 RFC 的時間提供特定條件，後來也加入了 Zircon 的特殊考量。
決策
FTP 程序會由 Fuchsia FIDL 團隊做出決策，最終決策者為 Fuchsia FIDL 團隊主管。
RFC 程序需要相關利益相關者表達其核准或拒絕意見，Fuchsia Eng Council (FEC) 則會做出最終決定。
這兩種決策方法相似，特別是考量到 FIDL 團隊會是修改 FIDL 的所有 RFC 的重要利害關係人。其中一個重要的差異是，FTP 程序需要「推送模型」，作者必須將設計提交給 FIDL 團隊。RFC 程序更偏向「拉取模型」，因此 FIDL 團隊有責任主動參與相關設計，以便讓意見獲得重視。
服務水準協議 (SLA)
FTP 程序有特定的服務水準協議，可提供權威性的答案 (「五個工作天」)。這個屬性是在 FTP-049 的迭代階段中特別新增，因為有人提出意見指出：「從 FTP 作者的角度來看，知道 FIDL 團隊何時會就 FTP 做出決定，會是件好事。」
RFC 程序目前沒有服務等級目標。
編號
FTP 程序會在 FTP 啟動時指派序號。
在 RFC 接受或拒絕時，RFC 程序會指派序號。
修訂 RFC 程序
媒介：RFC 程序應在社交階段提供比程式碼審查更具動態性的媒介，例如 Google 文件或其他媒介。可以說，這並未變更 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 在程序初期找出所有利益相關者，以免在提交階段發生意外。
工程審查會議：根據 FEC 的判斷，如果 RFC 可透過更多交流而有所助益，就應安排工程審查會議。導致安排工程審查的觸發事件包括：
- 難以找出相關利害關係人。在這種情況下，RFC 可能會收到許多評論、建議和反對意見，而作者不清楚如何回應這些意見，並且代表核心意見，可能會阻礙 RFC 獲得核准，而輔助意見可能會引起好奇、未來計畫等。
- RFC 作者和利害關係人難以就未解決的項目達成共識。
提交：RFC 提交程序不應限制對話內容是否趨於一致，因為在某些情況下，作者可能難以判斷。RFC 程序應允許作者要求 FEC 進行審查。收到這類要求後，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。
- 所有 FTP 參照項目，包括 Markdown 和程式碼註解中的參照項目。
- FIDL 治理部分。
- RFC 程序摘要頁面。
缺點、替代方案和未知事項
在同一個技術專案中保留兩個大致相同的正式程序會造成混淆。我們不認為維持現狀是可行的替代方案。
您可以針對上述 RFC 程序的每項修正案進行評估。我們認為這些變更都能帶來正面效益。
既有技術與參考資料
本 RFC 將 RFC 程序與 FTP 程序整合，也就是 FTP-001：簡單的提案和 FTP-049：FDil 調整程序演進。