總覽
本文件介紹 Fuchsia API 委員會。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 介面是包含 IDK 中的構件集合。包括但不限於 Fuchsia 系統介面、Fussia IDK 中包含的用戶端程式庫、IDK 中繼資料，以及 Fauchsia 核心開發人員工具。
「Fuchsia 貢獻者」是指負責建立 Fuchsia 作業系統的人員，包括 Google 和沒有工作經驗的人員。
Fuchsia API 設計人員是建立或修改 Fuchsia API 介面的人員，包括 Google 員工和未工作的使用者。
「終端開發人員」是指編寫軟體使用 Fuchsia API 介面的人員。
使用者是指搭載 Fuchsia 作業系統的裝置。
目標
最終，Fushisia API 委員會的最終目標是要在 Fuchsia 作業系統周圍打造健康的軟體生態系統。要打造健全的生態系統，必須在許多方面取得平衡，包括擴展生態系統，以及引導生態系統達成特定結果。
值
這個生態系統有許多參與者，他們扮演著不同的角色。在理想情況下，我們可以設計能同時滿足生態系統中所有人需求的 API，但經常呼籲 API 設計人員做出取捨。議會應協助 API 設計人員以下列消費者優先順序的方式做出這些決定：
- 使用者
- 開發人員
- 著作人
- API 設計人員
- 議會成員
舉例來說，我們應設計能保護使用者隱私的 API，即使快點無法滿足開發人員的所有需求也一樣。同樣地，即使 API 的設計會對實作 API 的人員減輕負擔，仍應設計出更適合最終開發人員的 API。
這些值可引導生態系統滿足使用者需求，長期下來促進生態系統的健全狀態與成長，因為使用者更有可能加入符合自身需求的生態系統，並持續留在這個生態系統中。
策略遊戲
為了達成這些目標，委員會必須關注以下指標：
功能。議會負責 Fuchsia API 介面的功能。具體來說，功能是指 API 是否符合生態系統參與者的需求。舉例來說，議會負責 API 保護使用者隱私的完善程度、API 協助開發人員完成特定工作的成效，以及我們的 API 如何讓 Fauchsia 貢獻者逐步改善實作成果。
可用性：議會負責 Fuchsia API 介面的可用性。舉例來說，委員會應致力確保在我們的 API 中表達類似概念的一致性，讓 API 能夠更輕鬆地讓終端開發人員學習。同樣地，委員會必須確保 API 記錄詳盡，且介面的語意可從宣告中符合直覺。
對系統的影響：對於透過使用 Fuchsia API 介面造成的整體負擔，議會須負責，包括預期與非預期用途。舉例來說，使用輪詢的 API 會對系統造成大量負擔，因為這類 API 要求用戶端必須持續執行，才能監控條件的變化。評估系統的影響需要大量的判斷與經驗，特別是預測 API 的非預期用途時更是如此。
清楚溝通：議會負責向 Fuchsia 貢獻者清楚傳達決策及其背後的理由。這項通訊應公開決策程序的相關資訊，並協助 API 設計人員瞭解如何建立高品質的 API。舉例來說，議會應透過貢獻 Fuchsia 的 API 可讀性評分量表來記錄最佳做法。
客戶滿意度：議會負責與 API 設計人員進行建設合作。議會應打造一個環境，讓議會成員和 API 設計人員共同合作改善 Fuchsia API 介面。API 設計人員應將委員會視為提供正面價值，協助他們製作更優質的 API，而非負擔官延負擔。舉例來說，議會成員應及時回覆，並尊重 API 審查要求。
會員資格
這個委員會是由 Fuchsia 貢獻者組成，並曾展現出以下成果：
對 API 品質和長期健康狀態的良好判斷標準，無論是在烏克蘭或其他平台的過去工作中。
API 設計人員 (即協作者) 觀察到的強大溝通和協作技巧。
成員則是由專案的每個功能領域負責。
該議會由Fuchsia Eng Council 負責主持。
議會擁有由 Fuchsia 領導人員任命的椅子，並且負責協助 Fuchsia Eng 委員會的運作。椅子的職責如下：
- 安排會議。
- 設定每場會議的議程。
- 評估議會是否已達到共識。
業務區域
| 領域 | Primary | Secondary |
|---|---|---|
| 藍牙 | jamuraa@google.com | silberst@google.com |
| 元件架構 | geb@google.com | ypomortsev@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 | cja@google.com |
| 體驗 | chaselatta@google.com | ianloic@google.com |
| FIDL | ianloic@google.com | none。 |
| 韌體 | dpursell@google.com | none。 |
| 外幣 ABI 相容性 | lindkvist@google.com | qsr@google.com |
| 圖形 | jbauman@google.com | dalesat@google.com |
| HCI | quiche@google.com | neelsa@google.com |
| 身分識別 | none。 | |
| 核心 | cpu@google.com | abarth@google.com |
| 媒體 | dalesat@google.com | none。 |
| 指標 | camrdale@google.com | none。 |
| 網路堆疊 | brunodalbo@google.com | none。 |
| 電源 | mbrunson@google.com | none。 |
| 產品組裝 | aaronwood@google.com | awolter@google.com |
| 安全性 | none。 | |
| 工作階段 | ypomortsev@google.com | none。 |
| 軟體推送 | kevinwells@google.com | etryzelaar@google.com |
| 儲存空間 | csuter@google.com | none。 |
| 測試 | crjohns@google.com | none。 |
| 工具鍊 | mcgrathr@google.com | none。 |
| 查看系統 | neelsa@google.com | quiche@google.com |
| 虛擬化 | none。 | |
| 網頁 | wez@google.com | ianloic@google.com |
| WLAN | silberst@google.com | jamuraa@google.com |
隨著專案不斷演進，功能領域 (以及委員會組成) 的清單也會隨之改變。功能區域清單是由 Fuchsia 的領導階層負責維護
在考慮新增區域時，議會會考量下列因素：
- 覆蓋範圍。是否有其他區域涵蓋這個區域？還是存在落差？
- 範圍。這個領域是否夠大，可承受專責人員？
- 持續需求之前是否有此地區存在？
決策程序
若根據裁判做出決定，決策流程如下。相關區域的委員會成員是「主要決策者」，但總裁者是「最終決策者」。議員整體會根據共識進行決策，由椅子進行評估。
主要決策者可以「延後」決策，在這種情況下，委員會會做出決定。如果議會未能達成概略共識，則輪椅會做出最終決定。
議會成員可以要求議員覆寫主要決策者。如果議會未能達成概略共識，則主要決策者的決策即屬實。
Operations
議會有兩個主要功能：API 審查和 API 校正。
API 審查
每次變更 Fuchsia API Surface 時，都必須取得議會成員的核准。 特定職能領域的變更通常應由負責該區域的委員會成員核准，但如果該地區成員沒有負責任的委員會成員，則可以核准變更。
在合併之前，每個修改 Fuchsia API Surface 的變更除了平常的 Code-Review+2 外，也必須接收來自 api-council@fuchsia.dev 成員的 API-Review+1。同一人可以針對特定變更提供 API-Review+1 和 Code-Review+2。如需這項 Gerrit 功能的說明文件，請參閱「審查標籤」。API 委員會的成員無法提供自己的 CLs API-Review+1，除非變更項目是輕微且不具爭議性 (例如文件變更)。即便如此，我們也鼓勵第二名議員接受獨立評論。
對於小規模的 API 變更 (尤其是現有 API 的漸進式改善)，程式碼審查通常就足以讓 API 審查人員變更 API-Review+1。但是，如果是較大的變更 (尤其是會大幅展開 API 介面的變更)，API 設計人員應撰寫 RFC (請參閱 Fuchsia RFC 範本)，說明 API 的設計 (包括用途和範例)，以及安全性和隱私權注意事項。即使 API 審查者不想單純透過程式碼審查來核准變更，API 審查人員也可以一律要求 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 設計人員應預期遵循計畫在核准的 API RFC 中，遵循計畫的 CL 應該能夠輕易審查 API-Review+1，即使是來自其他委員會成員亦然。
API 設計人員或審查人員可以向完整議程要求議程中的 API RFC，為接下來的 API 校正工作階段要求議程 (請參閱下一節)。舉例來說，如果 API 審查人員覺得校準不足、API 特別複雜或重要，或者審查者覺得即將截止期限或其他團隊導致審查人員感到壓力，則 API 審查人員可能會將一份文件交由完整委員會。
API 校正
API 委員會會定期比對 API 校正。API 校正的目的是提升整個專案的 API 審查一致性，並透過交叉輪詢最佳做法在整個委員會內進行 API 審查，提升 API 審查的品質。這些會議通常設有「講師」，負責保持會議的主題，並確保每位與會者都有機會提供意見。
Fuchsia 協作者可以觀察 API 校準會議。觀察這些會議有助於瞭解改善 API 介面的最佳做法。
使用 API 變更查看 RFC
在某些情況下，API 變更可能需要 RFC 討論提議的變更。API 校正的第一個優先事項是審查所有提及完整議程的 RFC。如果有多個待處理文件，主席則會選擇議會處理文件的順序。
撰寫文件的 API 設計人員應展示文件，向委員會提供必要的背景資訊，藉此瞭解所面臨的問題。之後，推薦文件的人員應帶領討論 API 設計的領域，以尋求意見。我們建議委員會成員將針對這些領域提供意見，但也可以針對整份文件自由提供意見回饋。
查看待處理工作
Fuchsia API 介麵包含大量的 API，是在議會成立前所設計。議會將處理該待處理 API 審查作業，最終將到達 Fuchsia API 介面中的每個 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 委員會、Web API OWNERS、W3C 和 IETF 所使用的管理架構。特別感謝 Jeff Brown、Dmitri Glazkov、Jeremy Manson、Rebecca Silberstein 和 Greg Simon ，他們將分享您對 API 管理經驗的體驗，以及在本文件的早期草稿中發表面貌的意見回饋。