| RFC-0017：FTP 程序已終止，長久以來在 RFC Process 上！ | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 停止 FIDL 調整程序，並將其整合至 RFC 程序。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2020-12-14 |
| 審查日期 (年/月) | 2021-02-08 |
摘要
這個 RFC 會停止 FTP 程序、將現有 FTP 折疊到 RFC 中，並修訂 RFC 程序，如下所示：
- 在社交階段中，鼓勵使用比程式碼審查更動態的媒介。
- 需要使用 RFC 範本，並在這個 RFC 範本中納入區域特定部分；
- 讓每個區域制定標準。
- 讓 Fuchsia Eng Council (FEC) 更積極地識別利害關係人。
- 新增 FEC 發起的會議，討論 RFC，並透過特定觸發條件呼叫會議。
- 由作者自行決定提交步驟，具有七個工作天的服務水準協議，由 FEC 提供具公信力的回答。
提振精神
自 2020 年 2 月推出 RFC 程序後，符合 FTP 條件的 FIDL 變更在技術上也需要 RFC。實際上，如果不同 FTP 也未同時經過 RFC 程序時會重複接受或遭到拒絕，這兩個程序的目標都是在達成類似目標，而正式程度和正式程度相近，審查結果也相近。
不過，我們的目標是統一 Fuchsia 針對技術變更執行單一審查程序，因此打算終止 FTP 程序，改用 RFC 程序。
FTP 程序已經兩年甚至半年來大 成功。另外，我們也試著在 RFC 程序中將所學的部分經驗應用到 RFC 程序中。
設計
我們會先調查 FTP 程序和 RFC 程序之間的「差異」，然後建議 RFC 程序的一組「修訂條款」。
最後，我們會說明如何將所有 FTP 折疊為 RFC，以進一步集中管理 Fuchsia 技術決策的所有構件。
這兩個程序之間的差異
Medium
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 Council) 之間可能會有重要資訊不對稱。將與作者召開審查會議的責任改為與授權人員召開會談會增加額外困難，尤其在必須瀏覽專案組織及知道邀請對象時，可能比較不容易上手。
條件
FTP 程序有使用時機的特定條件。
同樣地，RFC 程序在使用時機設有特定條件，稍後也會加入 Zircon 的特殊注意事項。
決策
FTP 程序取決於 Fuchsia FIDL 團隊，而最終決策者是 Fuchsia FIDL 團隊負責人。
RFC 程序仰賴相關利害關係人撤銷核准或拒絕，而 Fuchsia Eng Council (FEC) 則做出最終決定。
這兩種決策方法很類似，尤其是您認為 FIDL 團隊會是所有 RFC 修改 FIDL 的關鍵利害關係人。其中一項重要的差別是，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 範本的特定內容，以供 RFC 接觸 FIDL 區域時使用。
我們建議每個區域都提交其他條件，決定何時應遵循各自的 RFC 區域。如果某個領域有條件，FEC 會確保找到適當的相關人員。當然，這並不是 RFC 程序改變，只要提交 RFC 即可修改程序 (例如，Zircon 會執行的動作)。不過，透過簡化所有領域的標準，我們相信更多領域會明確指出「重要」的領域。除了確保這些區域能以適當的方式循環連線外，記錄變更的相對重要性也是一大優點。
RFC 條件：FTP 專屬。RFC 程序應包含在 FIDL 區域的 FTP-049 中識別的條件。
利害關係人：雖然 RFC 作者應盡最大努力找出利害關係人，但 FEC 也應在判斷利害關係人時扮演積極的角色。RFC 作者應向 FEC 要求識別程序初期的所有利害關係人，以降低提交步驟出現意外狀況的可能性。
參與審核會議：由 FEC 自行斟酌，如果 RFC 會因更多社交模式而受益，應安排為工程審查會議安排時間。導致安排工程審查的部分觸發條件包括：
- 難以識別相關利害關係人。相較於 RFC 收到許多註解、建議、推拒，且作者不清楚如何針對這些意見回饋採取行動，以及該意見表示可能阻礙了 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: A Just Proposal 和 FTP-049: FIDL Tuning Process Evolution)。