總覽
本文說明 Fuchsia API 委員會，這個團隊負責確保 Fuchsia API Surface 的品質和長期健康狀態。委員會將與 Fuchsia API 的建立和修改者進行建設性合作，協助引導這些 API 的演進。委員會將清楚說明決策內容 (包括基本原理)，並透過貢獻 Fuchsia 的 API 可讀性評量標準，記錄最佳做法。
定義
Fuchsia 系統介面是 Fuchsia 作業系統提供給系統上執行軟體的二進位介面。舉例來說，vDSO 的進入點和系統使用的所有 FIDL 通訊協定，都屬於 Fuchsia 系統介面。
用戶端程式庫是程式庫，撰寫 Fuchsia 軟體的人可能會選擇使用，而不是直接與 Fuchsia 系統介面互動。舉例來說，FDIO 是用戶端程式庫，可在 Fuchsia 系統介面中，透過基礎 fuchsia.io 通訊協定提供類似 POSIX 的抽象化。
Fuchsia IDK 是一系列程式庫、中繼資料和工具，由 Fuchsia 專案提供給為 Fuchsia 撰寫軟體的人員。Fuchsia IDK 包含 Fuchsia 系統介面的定義，以及多個用戶端程式庫。
Fuchsia API Surface 是我們納入 IDK 的構件集合。 包括但不限於 Fuchsia 系統介面、Fuchsia IDK 隨附的用戶端程式庫、IDK 中繼資料，以及核心 Fuchsia 開發人員工具。
Fuchsia 貢獻者參與了 Fuchsia 作業系統的建立，包括 Google 員工和非 Google 員工。
Fuchsia API 設計人員是指建立或修改 Fuchsia API Surface 的人員，包括 Google 員工和非 Google 員工。
終端開發人員會編寫軟體，以使用 Fuchsia API Surface。
使用者是指使用搭載 Fuchsia 作業系統裝置的人。
目標
最終，Fuchsia API 委員會的目標是圍繞 Fuchsia 作業系統，打造健全的軟體生態系統。要打造健全的生態系統，必須兼顧許多考量因素，包括擴大生態系統，以及引導生態系統朝特定結果發展。
值
這個生態系統有許多參與者，他們扮演許多不同的角色。理想情況下，我們應該能夠設計出同時滿足生態系統中所有人員需求的 API，但 API 設計人員經常需要做出取捨。委員會應協助 API 設計人員做出這些決策，同時尊重以下選區優先順序：
- 使用者
- 終端開發人員
- 著作人
- API 設計人員
- 委員會成員
舉例來說，即使無法滿足所有終端開發人員的需求，我們也應設計可保護使用者隱私權的 API。同樣地，即使這些設計會增加 API 實作者的負擔，我們也應設計出更適合終端開發人員的 API。
這些價值觀有助於引導生態系統滿足使用者需求，從長遠來看，這能促進生態系統的健康發展和成長，因為使用者更可能加入並留在符合自身需求的生態系統。
策略遊戲
為達成這些目標，委員會會著重於下列指標：
功能。委員會負責 Fuchsia API 介面的功能。具體來說，功能是指 API 是否符合生態系統參與者的需求。舉例來說，委員會負責確保我們的 API 能妥善保護使用者隱私、協助開發人員完成特定工作，以及讓 Fuchsia 貢獻者隨著時間改善實作項目。
可用性。委員會負責 Fuchsia API Surface 的可用性。舉例來說，委員會應盡量確保 API 中類似概念的表達方式一致，方便開發人員學習。同樣地，委員會應確保我們的 API 備有完善的文件，且介面的語意可從其宣告中直覺瞭解。
系統影響。議會必須對使用 Fuchsia API Surface 造成的系統整體負擔負責，包括預期和非預期的使用情況。舉例來說，使用輪詢的 API 會對系統造成極大負擔，因為這類 API 需要用戶端持續執行，才能監控條件變化。評估系統影響需要大量判斷和經驗，特別是預測 API 的非預期用途。
溝通清晰度。委員會負責向 Fuchsia 貢獻者清楚說明決策和決策背後的理由。這類溝通應清楚說明決策程序，並協助 API 設計人員瞭解如何建立高品質的 API。舉例來說，委員會應為 Fuchsia 的 API 可讀性評量表貢獻心力，記錄最佳做法。
顧客滿意度。委員會負責與 API 設計人員進行建設性合作。委員會應營造環境，讓委員會成員和 API 設計人員攜手合作，改善 Fuchsia API 介面。API 設計人員應將委員會視為提供正面價值，協助他們打造更優質的 API，而非官僚負擔。舉例來說，委員會成員應及時且有禮地回應 API 審查要求。
會員資格
委員會成員由 Fuchsia 貢獻者組成，這些貢獻者展現了：
對 API 品質和長期健康狀態有良好的判斷力，無論是在 Fuchsia 內，或是在過去與其他平台合作時。
API 設計人員 (即協作者) 認為的溝通和協作能力。
成員由專案的各個職能領域指派。
這個委員會由 Fuchsia 工程委員會監督。
委員會設有主席，由 Fuchsia 領導團隊指派，負責促進 Fuchsia 工程委員會的運作。主席的職責如下：
- 安排會議。
- 設定每場會議的議程。
- 評估委員會是否已達成大致共識。
功能領域
| 領域 | Primary | Secondary |
|---|---|---|
| 藍牙 | jamuraa@google.com | silberst@google.com |
| 元件架構 | cgonyeo@google.com | quiche@google.com |
| 開發人員 | wilkinsonclay@google.com | chaselatta@google.com |
| 診斷 | crjohns@google.com | miguelfrde@google.com |
| 驅動程式 | cja@google.com | jocelyndang@google.com |
| Driver SDK | jocelyndang@google.com | surajmalhotra@google.com |
| 體驗 | chaselatta@google.com | ianloic@google.com |
| FIDL | ianloic@google.com | 無 |
| 韌體 | dpursell@google.com | 無 |
| 外部 ABI 相容性 | lindkvist@google.com | qsr@google.com |
| 顯示卡 | costan@google.com | emircan@google.com |
| 身分 | 無 | 無 |
| 核心 | mcgrathr@google.com | rashaeqbal@google.com |
| 媒體 | dalesat@google.com | ypomortsev@google.com |
| 指標 | frousseau@google.com | 無 |
| Netstack | brunodalbo@google.com | 無 |
| Power | mbrunson@google.com | prashanthsw@google.com |
| 產品組裝 | aaronwood@google.com | awolter@google.com |
| 安全性 | 無 | 無 |
| 軟體交付 | galbanum@google.com | etryzelaar@google.com |
| 儲存空間 | csuter@google.com | 無 |
| 測試 | anmittal@google.com | crjohns@google.com |
| 工具鍊 | mcgrathr@google.com | phosek@google.com |
| UI | emircan@google.com | carolineliu@google.com |
| 虛擬化 | 無 | 無 |
| 網頁 | wez@google.com | ianloic@google.com |
| WLAN | silberst@google.com | jamuraa@google.com |
隨著專案發展，職責範圍清單 (以及委員會的組成) 也會隨之演進。職能領域清單由 Fuchsia 領導團隊維護。
委員會在考慮新增區域時，會考量下列事項：
- 涵蓋範圍。這個區域是否已涵蓋在其他區域中，還是有缺口？
- 範圍：這個區域是否夠大，需要指派專責人員？
- 持續需求。之前是否需要將此項目設為區域？
決策程序
如果需要委員會做出決策，決策程序如下。相關區域的議員是主要決策者，但議會整體才是最終決策者。委員會整體會根據主席評估的大致共識做出決策。
主要決策者可以延後決策，此時決策將由委員會做出。如果委員會無法達成大致共識，主席將做出最終決定。
委員會成員可以要求委員會推翻主要決策者的決定。如果委員會無法達成大致共識，主要決策者做出的決定即為最終結果。
Operations
委員會主要有兩項職責：API 審查和 API 校正。
API 審查
對 Fuchsia API Surface 所做的每項變更，都必須經過委員會成員核准。特定功能領域的變更通常應由負責該領域的委員會成員核准，但如果負責的委員會成員無法處理，任何委員會成員都可以核准變更。
修改 Fuchsia API Surface 的每項變更，都必須先獲得 api-council@fuchsia.dev 成員的 API-Review+1，以及一般的 Code-Review+2，才能合併。同一人可以為特定變更提供 API-Review+1 和 Code-Review+2。如要瞭解這項 Gerrit 功能，請參閱「查看標籤」一文。除非變更很小且沒有爭議 (例如文件變更)，否則 API 委員會成員無法自行給予 CL API-Review+1。但我們仍建議由第二位委員會成員進行獨立審查。
如果是小幅 API 變更，尤其是現有 API 的增量修正，通常只要進行程式碼審查，API 審查人員就能給予 API-Review+1。不過，如果是較大的變更，尤其是大幅擴充 API 介面的變更，API 設計人員應撰寫 RFC (請參閱 Fuchsia RFC 範本)，說明 API 的設計，包括用途和範例，以及安全性與隱私權考量。即使是小幅變更，API 審查人員一律可以要求 API 設計人員撰寫 RFC，前提是 API 審查人員認為光靠程式碼審查無法核准變更。
如要將 API 納入 Fuchsia SDK，必須通過兩項考驗：必須有準備好且願意合作的客戶，且 API 必須經過 API 校正。
API 設計人員也應盡早向委員會成員尋求意見回饋。舉例來說，API 設計人員應考慮與委員會成員分享 API 設計文件草案，以便在設計程序初期取得意見。委員會成員應參與這些討論，與 API 設計人員合作，協助設計出最佳 API。API 設計人員也可以在設計程序初期，向全體委員會尋求意見回饋，方法是請主席在即將舉行的 API 校準會議議程中安排時段 (請參閱下一節)。
API 審查人員應與 API 設計人員合作，改善 API RFC，直到 API 審查人員可以放心核准文件為止。核准文件是相關 API 的記錄計畫。不過，修改 API 介面的個別 CL 仍須先獲得 API-Review+1，才能合併。API 設計人員應預期，只要 CL 遵循核准的 API RFC 中規畫的內容，即使是其他委員會成員，也很容易給予 API-Review+1。
API 設計人員或審查人員可以要求主席在即將舉行的 API 校準會議議程中安排時段，將 API RFC 提交給全體委員會 (請參閱下一節)。舉例來說，如果 API 審查員覺得校準程度不足、API 特別複雜或重要，或是審查員因迫在眉睫的期限或其他團隊而感到壓力，就可能會將文件提交給全體委員會。
API 校正
API 委員會將定期召開會議，進行 API 校正。API 校正的目的是在專案中推動 API 審查的一致性，並透過委員會分享最佳做法，提升 API 審查品質。這類會議通常會安排主持人，確保會議內容切題，並讓每位參與者都有機會提供意見。
Fuchsia 貢獻者可以觀察 API 校準會議。觀察這些會議是瞭解 API 介面演進最佳做法的好方法。
查看含有 API 變更的 RFC
在某些情況下，API 變更可能需要 RFC，討論建議的變更。API 校正的第一要務是審查已提交全體委員會的任何 RFC。如有待處理文件，主席會決定委員會處理文件的順序。
撰寫文件的 API 設計師應向委員會說明文件內容，提供必要的背景資訊，讓委員會瞭解相關問題。之後，推薦該文件的人員應主導討論，說明他們希望獲得意見回饋的 API 設計領域。建議委員將意見回饋重點放在這些領域，但也可以針對整份文件提供意見。
查看待辦事項
Fuchsia API 介面包含大量 API，這些 API 是在委員會成立前設計的。委員會將處理積壓的 API 審查工作，最終完成 Fuchsia API Surface 中所有 API 的審查。理想情況下，在 Fuchsia 承諾 API 向後相容之前，委員會將有機會審查整個 Fuchsia API Surface。
主席會選取委員會處理待處理事項的順序，並嘗試平衡審查專案不同領域的 API，以及審查大量累積用戶的 API 的急迫性。
審查 API 時，負責該 API 所在領域的委員會成員 (以下稱為「負責成員」) 會介紹 API，並提供委員會瞭解 API 用途和動機所需的背景資訊。負責成員可以邀請一或多名主題專家，協助提供額外背景資訊和技術細節。理想情況下，負責成員會預先審查 API，並列出建議的修改項目。
次要審查
委員會也會輪流審查專案的功能領域，針對每個領域自上次週期以來的 API 介面變更，進行二次審查。委員會可透過這項活動，針對成員最近的 API 審查提供意見。
主席會選取審查區域的順序，並盡量平衡審查專案中不同區域的 API，以及審查大量變更的 API 的急迫性。
在二次審查期間，API 變更的主要審查委員會成員會介紹變更內容和相關的 API 設計文件，讓委員會瞭解變更的用途和動機。我們也建議 (但非必要) 進行相關變更的 API 設計人員出席會議。
一般來說，委員會應尊重主要 API 審查期間做出的決定，但我們鼓勵委員會成員提供有關如何改善 API 的意見回饋，這對日後的審查作業很有幫助。主要審查人員可能會視 API 的成熟度，決定是否將這些改良項目納入 API。在極少數情況下，委員會可根據決策程序，推翻主要審查人員的決定。
特別銘謝
本文大量參考 Android API Council、Web API OWNERS、W3C 和 IETF 使用的管理結構。特別感謝 Jeff Brown、Dimitri Glazkov、Jeremy Manson、Rebecca Silberstein 和 Greg Simon 分享 API 管理經驗，並對本文初稿提供寶貴意見。