總覽
本文說明 Fuchsia API Council，這是一群負責 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 介面的人員，包括 Google 員工和非 Google 員工。
終端開發人員是指編寫軟體來使用 Fuchsia API Surface 的人員。
使用者是指使用搭載 Fuchsia 作業系統裝置的人。
目標
Fuchsia API Council 的最終目標，是圍繞 Fuchsia 作業系統，打造健全的軟體生態系統。為了培養健康的生態系統，必須平衡多項考量，包括發展生態系統，以及引導生態系統朝特定成果發展。
值
這個生態系統有許多參與者，扮演著許多不同的角色。在理想情況下，我們能設計出同時滿足生態系統中所有人需求的 API，但 API 設計師往往必須做出涉及權衡取捨的決策。委員會應協助 API 設計人員做出這些決策，並遵循下列優先順序：
- 使用者
- 終端開發人員
- 著作人
- API 設計人員
- 理事會成員
舉例來說，我們應設計保護使用者隱私的 API，即使這會犧牲部分開發人員的需求。同樣地，我們也應該設計更適合終端開發人員的 API，即使這些設計會對實作 API 的人員造成較大負擔。
這些價值觀有助於引導生態系統滿足使用者需求，進而促進生態系統的長期健康和成長，因為使用者更有可能加入並留在符合其需求的生態系統中。
策略遊戲
為達成這些目標，理事會著重於下列指標：
功能。委員會負責 Fuchsia API 介面的功能。具體來說，功能是指 API 是否能滿足生態系統參與者的需求。舉例來說，委員會負責確保 API 能妥善保護使用者隱私、協助終端開發人員完成特定工作，以及讓 Fuchsia 貢獻者能持續改善實作方式。
可用性：理事會負責確保 Fuchsia API Surface 的可用性。舉例來說，委員會應努力確保 API 中類似概念的表達方式一致，讓終端開發人員更容易學習 API。同樣地，委員會應確保 API 具有完善的文件，且介面的語意從宣告中就能直觀理解。
系統影響。委員會負責處理因使用 Fuchsia API Surface 而對整個系統造成的負擔，包括預期和非預期的使用。舉例來說，使用輪詢的 API 會對系統造成沉重負擔，因為用戶端必須持續執行，才能監控條件變化。評估系統影響需要大量的判斷和經驗，尤其是預測 API 的非預期用途。
溝通清晰度：理事會負責向 Fuchsia 貢獻者清楚說明決策和決策背後的理由。這類溝通應確保決策過程公開透明，並協助 API 設計人員瞭解如何建立優質 API。舉例來說，理事會應透過 Fuchsia 的 API 可讀性評分標準，記錄最佳做法。
顧客滿意度：委員會負責與 API 設計師合作，委員會應營造一個環境，讓委員會成員和 API 設計師合作，改善 Fuchsia API 介面。API 設計師應將委員會視為提供正面價值的組織，協助他們打造更優質的 API，而非官僚負擔。舉例來說，委員會成員應及時且尊重地回應 API 審查要求。
會員資格
理事會成員為 Fuchsia 貢獻者，他們展現了：
對 Fuchsia 內或過去與其他平台合作的 API 品質和長期健康狀況有良好判斷力。
API 設計師 (即協作者) 認為，具備良好的溝通和協作能力。
成員由專案的各個職能領域指派。
委員會由 Fuchsia 工程委員會監督。
委員會設有主席，由 Fuchsia 領導團隊任命，負責推動 Fuchsia Eng 委員會的運作。主席的職責如下：
- 安排會議。
- 設定每場會議的議程。
- 評估理事會是否已達成大致共識。
功能區域
| 領域 | Primary | Secondary |
|---|---|---|
| 藍牙 | jamuraa@google.com | silberst@google.com |
| 元件架構 | cgonyeo@google.com | quiche@google.com |
| 開發人員 | wilkinsonclay@google.com | chaselatta@google.com |
| 診斷 | crjohns@google.com | 無 |
| Driver SDK | jocelyndang@google.com | surajmalhotra@google.com |
| 驅動程式 | cja@google.com | puneetha@google.com |
| 體驗 | chaselatta@google.com | ianloic@google.com |
| FIDL | ianloic@google.com | hjfreyer@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 | 無 |
| 指標 | frousseau@google.com | 無 |
| Netstack | brunodalbo@google.com | martinjeffrey@google.com |
| Power | mbrunson@google.com | prashanthsw@google.com |
| 產品組裝 | aaronwood@google.com | diserovich@google.com |
| 安全性 | 無 | 無 |
| 軟體推送 | galbanum@google.com | etryzelaar@google.com |
| 儲存空間 | csuter@google.com | jfsulliv@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 | mnck@google.com | silberst@google.com |
隨著專案發展，功能領域清單 (以及理事會的組成) 也會隨之演變。職能領域清單由 Fuchsia 領導團隊維護。
在考慮是否新增區域時，委員會會考量以下因素：
- 涵蓋率：這個區域是否已由其他區域涵蓋，還是有缺口？
- 範圍。這個領域是否大到需要專人負責？
- 持續需求。之前是否曾需要將此設為區域？
決策程序
如果需要委員會做出決策，決策程序如下。相關區域的議會成員是主要決策者，但整個議會才是最終決策者。委員會整體會根據主席評估的大致共識做出決策。
主要決策者可以延後決策，在這種情況下，委員會將做出決策。如果委員會無法達成大致共識，則由主席做出最終決定。
理事會成員可以要求理事會駁回主要決策者的決定。如果委員會無法達成大致共識，則以主要決策者的決定為準。
Operations
委員會主要有兩項職責：API 審查和 API 校正。
API 審查
對 Fuchsia API 介面所做的每項變更，都必須經過委員會成員核准。特定功能領域的變更通常應由負責該領域的委員會成員核准，但如果負責的委員會成員無法核准，任何委員會成員都可以核准變更。
在合併之前，除了通常的 Code-Review+2 之外，每個修改 Fuchsia API Surface 的變更都必須收到 api-council@fuchsia.dev 成員的 API-Review+1。同一個人可以為特定變更提供 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 審查人員不願意僅透過程式碼審查核准變更，也可以要求撰寫 RFC。
如要納入 Fuchsia SDK，API 必須通過兩項考驗：必須有準備就緒且有意願的客戶，且 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 Surface 包含大量在委員會成立前設計的 API。委員會將處理待審查的 API，最終審查 Fuchsia API Surface 中的每個 API。理想情況下，在 Fuchsia 承諾 API 的回溯相容性之前，委員會將有機會審查整個 Fuchsia API 介面。
主席會選擇委員會處理待辦事項的順序，並試著在審查專案中不同領域的 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 治理經驗，並對本文件的早期草稿提供寶貴意見。