總覽
本文件旨在介紹 Fuchsia API 委員會，也就是由一群人組成 為 Fuchsia API 的品質和長期健康狀態負責 表面。委員會將與創作新人 以及修改 Fuchsia API，引導這些 API 的演進。議會 將清楚呈現決策，包括基本理由 記錄這些最佳做法，以提升 Fuchsia 的 API 可讀性 使用評分量表
定義
Fuchsia 系統介面是 Fuchsia 的二進位介面 對系統執行的軟體顯示作業系統舉例來說， 進入 vDSO，以及系統使用的所有 FIDL 通訊協定 是 Fuchsia 系統介面的一部分。
用戶端程式庫是使用者編寫 Fuchsia 軟體的程式庫。 選擇使用，而不是直接與 Fuchsia 系統互動 介面。舉例來說，FDIO 是一個提供類似 POSIX 的用戶端程式庫 Fuchsia 系統中基礎 fuchsia.io 通訊協定的抽象概念 介面。
Fuchsia IDK 是 Fuchsia 的一組程式庫、中繼資料和工具。 。除此之外 Fuchsia IDK 包含 Fuchsia 系統介面的定義，以及 用戶端程式庫數量
Fuchsia API 介面是指我們納入 IDK 的一系列構件。 這包括但不限於 Fuchsia 系統介面 Fuchsia IDK 中包含的用戶端程式庫、IDK 中繼資料，以及 Fuchsia 開發人員工具。
Fuchsia 貢獻者是指參與建立 Fuchsia 作業的使用者 包括 Google 員工和非職場員工
Fuchsia API 設計人員是指建立或修改 Fuchsia API 介面的人員。 包括與 Google 工作及未使用 Google 工作的人
開發人員是指編寫使用 Fuchsia API 軟體的人員 表面。
使用者是指使用搭載 Fuchsia 作業系統的裝置的使用者。
目標
最終，Fuchsia API 委員會的最終目標是促進健康 軟體生態系統促進健康 生態系統需要平衡許多疑慮，包括拓展生態系統及 引導生態系統達成特定成果
值
生態系統中有許多人擔任各種不同的角色。最理想的情況是 能夠設計出符合生態系統中所有人需求的 API 但往往會呼叫 API 設計人員，以決定 需要權衡取捨委員會應能協助 API 設計人員做出上述決定 於尊重下列選區優先順序的情況下：
- 使用者
- 開發人員
- 著作人
- API 設計人員
- 議會成員
舉例來說，即使在 無法滿足開發人員的所有渴望同樣地，我們 即使 API 的設計 對實作 API 的人員減輕負擔。
這些值可協助引導生態系統滿足使用者需求， 維護生態系統的健康與成長，因為使用者 的使用者更有可能加入並繼續參與符合需求的生態系統。
策略遊戲
為達成這些目標，議會著重於以下指標：
功能：議會負責處理 Fuchsia API 介面。具體來說，功能是指 滿足生態系統參與者的需求例如，議會 負責 API 保護使用者隱私的措施 API 可協助開發人員完成特定工作，以及我們的 API Fuchsia 貢獻者逐漸改善實作內容。
可用性：議會對於 Fuchsia API 的可用性負責 表面。舉例來說，議會應盡力維持 類似概念，都讓我們的 API 更容易理解 以便開發人員瞭解同樣地，議會必須確保 API 介面敘述都明確，且介面語意 宣告。
系統影響。議會負責系統的 因使用 Fuchsia API 介面而產生的整體流量，包括 非預期或非預期的用途舉例來說，使用輪詢的 API 會 系統承受巨大負擔，因為他們需要用戶端執行 持續監控條件的變化評估系統影響 需要大量的判斷和經驗，尤其是 預測 API 的意外用途
確保溝通清楚。議會負責 向 Fuchsia 傳達決策背後的理由 貢獻者。本通訊應公開 決策過程，而且能協助 API 設計人員瞭解 建立優質 API舉例來說，議會 確實改善 Fuchsia 的 API 可讀性評分量表。
客戶滿意度：議會負責協作 與 API 設計人員合作議會可以營造一個環境 委員會成員與 API 設計人員攜手合作 Fuchsia API 介面執行這些作業。API 設計人員應看到委員會提供 正面價值，協助他們打造更出色的 API，而不是官僚體系 負擔。例如，議會成員應立即回覆 尊重 API 審查要求
會員資格
議會由 Fuchsia 貢獻者組成，他們具備以下特點：
無論是 API 的品質還是長期健康狀態， Fuchsia 或過去與其他平台合作的情形。
從 API 設計人員的角度來看，強大的通訊和協作技能 (即協作者)。
成員由專案的各個功能領域指派。
議會由福夏大會負責監管。
委員會有一位由 Fuchsia 主管任命的椅子， 促進福希西亞恩格議會的營運。椅子上有 責任：
- 排定會議時間。
- 設定每場會議的議程，
- 評估議會是否達到粗略共識。
功能領域
| 領域 | Primary | Secondary |
|---|---|---|
| 藍牙 | jamuraa@google.com | silberst@google.com |
| 元件架構 | geb@google.com | dgilhooley@google.com |
| 開發人員 | wilkinsonclay@google.com | chaselatta@google.com |
| 診斷 | crjohns@google.com | miguelfrde@google.com |
| 車手 | cja@google.com | jocelyndang@google.com |
| 驅動程式 SDK | jocelyndang@google.com | cja@google.com |
| 體驗 | chaselatta@google.com | ianloic@google.com |
| FIDL | ianloic@google.com | 無 |
| Firmware | dpursell@google.com | 無 |
| 外國 ABI 相容性 | lindkvist@google.com | qsr@google.com |
| 顯示卡 | jbauman@google.com | emircan@google.com |
| HCI | neelsa@google.com | emircan@google.com |
| 身分識別 | 無 | 無 |
| Kernel | cpu@google.com | abarth@google.com |
| 媒體業 | dalesat@google.com | ypomortsev@google.com |
| 指標 | frousseau@google.com | 無 |
| Netstack | brunodalbo@google.com | 無 |
| 電源 | mbrunson@google.com | prashanthsw@google.com |
| 產品組裝 | aaronwood@google.com | awolter@google.com |
| 安全性 | 無 | 無 |
| 工作階段 | quiche@google.com | neelsa@google.com |
| 軟體推送 | galbanum@google.com | etryzelaar@google.com |
| 儲存空間 | csuter@google.com | 無 |
| 測試 | anmittal@google.com | crjohns@google.com |
| 工具鍊 | mcgrathr@google.com | 無 |
| 查看系統 | emircan@google.com | neelsa@google.com |
| 虛擬化 | 無 | 無 |
| 網頁 | wez@google.com | ianloic@google.com |
| WLAN | silberst@google.com | jamuraa@google.com |
隨著專案不斷推陳出新 會隨之更新。功能區域清單會保留 由 Fuchsia 主管階層提供。
新增區域時，議會會考量以下因素：
- 涵蓋率：這個區域是否已屬於其他區域，或是 發生什麼狀況？
- 範圍：這個領域是否足夠大，可以保證合格的受害人員？
- 持續性需求。過去是否曾在某個區域拍攝？
決策程序
如果議員被要求做出決定，其決策程序會是 後面。相關區域的議員是主要決策者 決定者，但整體委員會只有最終決策者。議會 左右輪椅評估的結果，都是以「粗略的共識」為依據。
主要決策者可以「延遲」決策，在此情況下，委員會 做出決定如果議員未能達到粗略的共識， 主席會決定最終決定
議員可以要求議會過度規則主要決策 製作者。如果議員未能達到粗略的共識，則會 主要決策者的立場
Operations
委員會有兩大功能：API 審查和 API 校正。
API 審查
每次變更 Fuchsia API 途徑時，都必須取得議會成員的核准。 在特定功能領域做出變更通常應經過 該區域負責，但任何議會成員都可以核准 如果負責理會成員不可用，請變更電子郵件地址。
合併之前，每次修改 Fuchsia API 介面的變更都必須 接收來自以下社群的成員的 API-Review+1 api-council@fuchsia.dev Code-Review+2.同一人可以同時提供 API-Review+1 和 Code-Review+2 特定變更的流量如需相關說明，請參閱「查看標籤」一文。 此功能。API 委員會成員無法授予自己的 CL API-Review+1，除非這些變更 (例如 說明文件變更)。即便如此，另一名議會成員的獨立評論也一樣 建議。
如果是小幅 API 變更 (尤其是對現有 API 的漸進式修正)， 程式碼審查通常足以讓 API 審查人員 API-審查+1.但需要進行大型變更時，尤其是擴充 API 的變更 明顯地，API 設計人員應編寫 RFC (請參閱 Fuchsia RFC 範本)，說明 API 的設計，包括使用 案例和範例，以及安全性和隱私權注意事項。API 審查人員隨時可以要求 API 設計人員編寫 RFC，即使 API 審查人員對於核准變更不放心 完全仰賴程式碼審查機制
要加入 Fuchsia SDK 中，API 必須清楚兩個步驟： 且該 API 必須通過 API 驗證 校正。
此外，我們也鼓勵 API 設計人員盡早向委員會成員徵求意見回饋。 舉例來說，API 設計人員應考慮分享處理中的 API 設計 與議會成員的文件，以便在設計流程中及早收集意見。議會 成員應參與這些討論，以尋求與 API 合作的目標 這些設計精密的 APIAPI 設計人員也可以 從整個議會初期的設計流程中，向輪椅使用者要求插槽 的議題 (請參閱下一節)。
API 審查人員應與 API 設計人員合作，以改善 API RFC， 讓 API 審查人員放心核准文件。一個 做為相關 API 的記錄計畫。不過 修改 API 介面的個別 CL 仍需接受 API-Review+1 再進行合併API 設計人員應預期遵循計畫的 CL 您在核准的 API RFC 中提及的 RFC 應該很容易審查 API-Review+1 其他委員會成員的貢獻
API 設計人員或審查人員可以提出要求，將 API RFC 參照到完整委員會 我們即將舉行 API 校正講座的議程中，特定時段的椅子 (請參閱 請參閱下一節)。舉例來說，API 審查人員可能會將說明文件 如果 API 審查人員無法充分校正， API 特別複雜或重要，或是審查人員認為 期限或其他團隊
API 校正
API 委員會會定期進行 API 校正。模型的用途 API 校正是為了提升整個專案的 API 審查一致性， ，在各 Google 平台之間 議會這些會議通常會安排講師，讓會議保持開啟 主題，協助確保每位參與者都有機會提供意見。
Fuchsia 協作者可觀察 API 校正會議。觀看這些會議，是瞭解如何改善 API 介面的最佳做法的好方法。
查看含有 API 變更的 RFC
在某些情況下，變更 API 可能需要與 RFC 討論提議的 並輸入變更內容API 校正的首要任務，就是檢查任何 有些人已經被介紹過完整委員會如果有多份待處理的文件 主席會選擇議員透過 文件。
撰寫文件的 API 設計人員應提供相關文件 向客戶提出必要的背景資訊，以瞭解所面臨的問題。 之後，推薦本文件的人員應帶領 以及希望在 API 設計上獲得意見回饋的領域議會成員是 鼓勵各位將重心放在這些領域上，但可以自由 針對文件整體的意見回饋。
查看待處理工作
Fuchsia API 介麵包含大量專為 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 擁有者、W3C 及 IETF特別感謝 Jeff Brown、Dimitri Glazkov、Jeremy Manson、Rebecca Silberstein 和 Greg Simon： 分享自己使用 API 管理機制的經驗，並依據他們的詳盡意見回饋 。