| RFC-0049：FIDL 調整程序演進 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 為了實現 FTP 處理程序的各種演進，我們先將評論從決策拆分中劃分，加入作者撤銷 FTP 的方法、針對需要 FTP 的需求提供相關準則，最後再說明提交 FIDL 的其他方式。 |
| 作者 | |
| 提交日期 (年/月) | 2019-11-20 |
| 審查日期 (年/月) | 2019-12-19 |
摘要
我們提議了多項 FTP 程序的演進：
- 最重要的是根據審查結果劃分評論；
- 加入作者撤銷 FTP 的方式。
- 提供需要 FTP 的指南，最後再寫出
- 說明其他捐款方式。
提振精神
我們在一年多前推出了 FIDL 調整程序。由所有帳戶共同推動這個流程，成功改善了構成作品的三個動機和目標：仔細思考設計限制；每項決策背後的思維是公開、記錄和公開。最後，這個流程提供了一個論壇，讓大家討論想法 (有時是很長)，同時提供結案。
淨結果一直是變化的速度，並有一戰手冊需要反覆調整。截至目前為止，您已提交 48 項提案 (配音為「FTP」)，其中 25 項已接受，其中 9 項提案遭到拒絕 (所有提案皆有正確記錄拒絕原因)。
然而，除了諸多事，仍有改進空間。具體而言，我們會考量以下因素：
- 如何查看 FTP？
- 何時可以撤銷 FTP？
- 哪些變更需要 FTP？
- 還有哪些方式可以促進 FIDL 的設計與演進？
設計
檢閱 FTP
相關程序目前未依照 FTP 的審查方式進行，並注意：「提案會由 Fuchsia FIDL 團隊成員 (非正式稱為 Luthers) 的成員審查，以及任何適合參與或委任的人員。」
最常見的 FTP 論壇則是面對面會議。會議首先由 FTP 作者展示他們的設計。會議講師 (通常是今天的 FIDL 負責人) 將處理設計文件中的註解，一開始可能是針對應該討論的「開放項目」建立快速議程。
與「工程審核程序」不同的是，在會議期間解決待解決的項目 (需要做筆記，之後整合至 FTP)，而 FIDL 負責人會決定接受或拒絕 FTP。
既然會議在會議結束前就做出決定，以及 FIDL 負責人將扮演講師和決策者的雙重角色，就會造成阻礙：FTP 會議期間遇到一定的衝擊、參與者有發聲的壓力、最後一刻的信封設計決策，進而催化快速修訂的 FTP。
為解決這個品質不佳的動態，我們修正了「審查」步驟，並加入明確的「決策」步驟。部分語言會從工程流程借用。「審查」步驟變更如下：
目前 FTP 和所有尚未解決的註釋都會受到審查。
提案會由 Fuchsia FIDL 團隊的成員審查 (由 fuchsia.git 存放區中的 OWNERS 檔案定義，非正式稱為「luthiers」) 團隊，以及任何他們認為適合在程序中納入或委派的人。舉例來說，這些專家可能會加入特定語言專家，為該語言的繫結做出決定。如有必要，可以提報爭議性決策，如同其他 Fuchsia 的技術決策一樣。
[ADD] 審查作業通常是在一或多場「FTP 見面會」會議期間進行。如有需要，也可使用非同步通訊進行。
FTP 會議會由展示設計的作者開始舉行。講師接著會檢視 FTP 中的註解，要求在文件中加註的使用者展示自己的意見回饋。
[ADD] 講師和簡報者的理想與眾不同。講師的目標，是確保設計的各個層面都獲得妥善處理，同時確保會議順利進行。在理想情況下，講師並未從結果中採取特定措施，以免觀眾誤以為是偏見，且簡報者也會隱瞞自己正在呈現的設計。
[新增] 我們不一定要在會議期間關閉每項意見回饋，或是討論每則留言 (例如同一根本問題收到大量留言或討論好幾則留言)。因此，講師應做出最佳化調整，為簡報者提供各式各樣的意見，而不是引導學生進行結論。待處理的開放問題可能會在進一步審查階段或決策期間解決。
審查作業最終可能會產生三種結果。
首先，有些問題或意見需要做決定。在這種情況下，FTP 會移回「註解」階段。
其次，提案可能會遭拒，審查人員會提供原因說明。
第三，可能已接受優惠。
「審查」步驟之後會新增「決策」步驟：
請在五 (5) 個工作天內，由擁有者檔案定義的 Fuchsia FIDL 團隊成員，最終決策者是 Fuchsia FIDL 團隊負責人，決定審查的結果。
上述決策最終有三種結果。
首先，有些問題或意見需要做決定。在這種情況下，FTP 會移回「註解」階段。
其次，提案可能會遭拒，審查人員會提供原因說明。
第三，可能已接受優惠。
做決策的場地通常會以會議的形式呈現。這類會議也可以是電子郵件執行緒，或是在審查會議期間進行。
撤回 FTP
有時候，FTP 的作者可能會想撤銷自己的 FTP。
「註解」步驟之後會新增「撤回」步驟：
釋出的 FTP 是儲存工程構想的寶貴記錄。當作者撤銷 FTP 時，必須在 FTP 中加入解除原因。系統會將 FTP 複製到所有 FTP 的公開記錄，以發布海報。
解除原因由 FTP 作者撰寫，可能與 Fuchsia FIDL 團隊成員合作。
說明理由應以下列兩種做法之一做為行動依據。
作者在 FTP 程序中學到了哪些知識，進而提出替代設計呢？
如何取代已撤銷的 FTP？
要求 FTP 的條件
我們明白並非所有的「FIDL」變更都需要 FTP。沒有人預期在 fidlc 中有小幅重構設計文件。而在光譜的另一端，導入新的訊息版面配置或變更傳輸格式則絕對需要 FTP。
對於需使用 FTP 而升遷的門檻，我們有什麼看法？ 我們遵循的一般規則如下：
符合下列任一情況時，「必須」執行 FTP 程序：
解決方案空間十分龐大，也就是說，變更只是其他許多不錯的解決方案之一，在設計上並不容易。
變更將產生極大影響，即此變更大幅修改 FIDL 的行為，進而對 FIDL 的多或所有使用者造成風險；
變更的範圍較大，也就是說，這項變更涵蓋了足夠的 FIDL 元素，因此需要仔細留意，才能判斷此變更是否會造成重大影響。
舉例來說，如要變更以下區域，可能需要 FTP：
- FIDL 管理
- 設計原則
- 語言文法
- 輸入系統
- 通訊協定語意
- 電匯格式
- 繫結規格
以下是 FTP 範例及這些改變的部分：
RFC-0047：資料表：
類型系統) 推出了表示類似資料的新方式，首先使用信封。
有線格式) 全新的表格和信封線格式。
繫結規格) 適用於繫結的一些 API 建議。RFC-0023：通訊協定的組成模型：
語言文法) 使用通訊協定語法取代介面語法。
通訊協定語意) 明確表達通訊協定組合的語意，包括不含「is-a」關係。
繫結規格) 禁止繫結，利用多態性
模型組合。RFC-0027：用多少付多少：
設計原則) 制定了新的設計原則。
FIDL 管理) 針對新引進的設計原則明確呼叫
，也就是 FTP 流程的一部分。RFC-0024：強制性來源相容性：
FIDL 管理) 已修改 FTP 範本，新增來源
相容性的摘要。 繫結規格) 針對
繫結的「自行出資」來源相容性需求。RFC-0049：FIDL 調整程序演進技術，即這項變更：
FIDL 管理計畫旨在為 FTP 程序提供額外指引，
並找出為 FIDL 提供的其他方式。
另請注意，以下也舉例說明較不造成 FTP 的變化：
建立新的 FIDL 繫結 (例如 LLCPP 繫結)：
FIDL 旨在支援多種互動的實作。
您應該建立新的繫結，且這項操作不需要來自 Fuchsia FIDL 團隊
進行突襲即可。明確參照列舉成員1：
在支援變更my.library.MY_ENUM_MEMBER之前，並由明確的語法my.library.MyEnum.MY_ENUM_MEMBER取代。儘管語言文法有所變更，此變更只是針對先前存在的功能修正錯誤。假設程式庫同時有列舉成員CLASHING_NAME和常數CLASHING_NAME，參照兩者不明確，而fidlc則採用入侵類型解析規則來打破關係。成員的限定範圍規則並未變更，成員的範圍限定在宣告中，fidlc和所有繫結都會遵循該規則。導入意圖：延緩類型建構後原始到平鋪轉換：
在重新建構類型系統時，沒有完成可觀察的變更。這是重構工作。實作意圖：變更「訊息」的表示方式：雖然 JSON IR 受到這項變更的影響，但這項簡報變更帶來了先前需要由繫結 (標頭形狀) 隱含的特定概念。同樣地，不會有可觀察的變更，而且不會影響程式碼結構 (在
fidlc及繫結中) 之外。
提供給 FIDL (非 FTP)
Fuchsia FIDL 團隊的目標是「促進 FIDL 的合作與包容性」，並特別確保「Fuchsia 團隊感覺能接收到大概邊緣資訊，且非 FIDL 團隊成員會適當引導並給予協助，或以合理理由提前拒絕。」
編寫 RFC 通常需要投注大量心力，並具備解決方案空間，以便正確證明與其他替代選項相關的特定設計選擇。FTP 程序也相當繁重，且有時可能會降低。因此，FTP 程序本身並不有助於達成協同合作目標。
其他貢獻方式包括：
在 Fuchsia FIDL 團隊聊天室中討論應用實例和問題。團隊成員的所有成員密切關注對話，而這個論壇中的執行緒經常會導緻小規模的變化，或是優先順序變動。
參與 Fuchsia API 審查。這個階段的關鍵在於觀察具體用途，以及評估各種 FIDL 功能在支援這些功能的組合方面的成效。推動了多項演進，主要是因為識別一種 API 設計模式，這些模式可藉由調整功能或新功能來補足。
向 Fuchsia FIDL 團隊回報錯誤。
描述問題陳述，並與大規模的 Fuchsia FIDL 團隊及 Fuchsia 團隊合作，探索可能的解決方案。
描述可能的解決方案，並與大規模的 Fuchsia FIDL 團隊及 Fuchsia 團隊合作進行評估。
原型設計替代方法。
以「20%-er」的身分加入 FIDL 團隊，並處理已指派的 FIDL 團隊。
這些方法都可能導致擷取脆弱的問題陳述式、直接變更 FIDL 或轉換成 FTP。
導入策略
更新 FIDL 調整提案頁面。向廣泛傳達這項變更進行審查時，請務必遵循新的變動內容。
人體工學
沒有影響。
說明文件與範例
查看導入策略。
回溯相容性
沒有影響。
效能
沒有影響。
安全性
沒有影響。
測試
沒有影響。
缺點、替代方案和未知
雖然修改程序的方法有很多種，但我們相信提出的變更只是普通的疊代，且預期可帶來淨利益。我們預期未來的程序會有所改進。
先前的圖片和參考資料
很多。其中一項是 Fuchsia 採用的「工程評論」程序。