治理 - amp.dev - AMP 框架

詞彙表

顧問委員會 (AC)。 由來自 AMP 各個選區（包括使用者、終端使用者和協作者）的代表組成的小組，為技術指導委員會提供建議。
協調人。 治理機構的成員，負責促進基於共識的決策過程，並擔任其他治理機構的代表。
治理機構 顧問委員會、技術指導委員會和工作小組的任何一個。
使用者。 使用 AMP 但尚未（或尚未）為其做出貢獻的開發人員。
終端使用者。 使用 AMP 格式消費內容的人。
技術指導委員會 (TSC)。 一群制定 AMP 技術與產品方向的人員。
工作小組 (WG)。 一群對特定領域有熟悉度和興趣的人員；可能是跨領域的（例如「文件」）或專注於特定領域的（例如「營利」或「效能」）。這些小組由 TSC 正式認可，但也可能非正式組成。

顧問委員會向技術指導委員會提供觀點和建議。此建議不具約束力。

TSC 應由在技術和產品層面為 AMP 做出重大貢獻的成員組成。
TSC 的成員資格沒有時間限制。
TSC 的目標規模為 6-12 名成員，但沒有固定規模。
TSC 一旦成立，將透過基於共識的流程自行設定成員資格。
TSC 的目標應為來自同一雇主的 TSC 成員不超過三分之一。鑑於 TSC 的成員資格要求在 AMP 方面具有公認的技術和/或產品經驗，這在 TSC 成立時可能不可行，但 TSC 應積極朝著這個目標努力。
實體（例如公司）可能會被授予在 TSC 中的席位。在這種情況下，席位可能會附加某些條件（例如維持對專案的承諾資源）。實體可以指定代表該實體在 TSC 中的個人，並可以自行決定更換此人。
TSC 將從其成員中指定一名協調人，以促進基於共識的決策過程。

工作小組是社群中對 AMP 特定領域（例如 UI、執行階段、基礎架構、文件）具有知識/興趣的一部分，並由 TSC 認可。
TSC 定義每個工作小組的職權範圍，其中可能包括對某些 AMP 功能、系統和/或程式碼的責任。工作小組通常在其職權範圍內的領域獨立運作，同時遵守 AMP 的專案指南、願景/使命和技術/產品路線圖。
每個工作小組都由一組對該特定領域具有知識/興趣的協作者 + 其他感興趣的各方組成。
每個工作小組的協調人負責
- 促進工作小組內基於共識的決策。
- 代表工作小組向 TSC 報告。
- 根據需要從工作小組內部選擇指定人員來承擔這些責任。
工作小組內部的決策遵循決策政策，並由協調人或其指定人員促進。

TSC 建立工作小組並指派初始成員。成員應包括一些提交者，但也可能包括其他感興趣的各方。
工作小組可以使用基於共識的方法來新增或移除成員以及更換協調人。
具有共同興趣的群體一起工作而無需正式的工作小組是可以接受且預期的。這些群體可以透過向 TSC 提出提案（包括其目的和擬議的成員資格）來選擇被正式認可為工作小組。
TSC 可以根據需要解散/重組工作小組。

AMP 的顧問委員會、TSC 和工作小組的決策應使用基於共識的方法（類似於 Node.js 使用的方法和 JS Foundation）。
當討論似乎達成共識時，協調人將詢問是否有人對表面上的共識提出異議。成員可以要求投票以最終確定決策，但這應該僅作為最後手段。經小組中其他兩名成員同意，將舉行投票，否則將繼續尋求共識的過程。
當需要投票時
- 投票時間應設定為允許小組成員有合理的時間參加。投票時間應公開宣布。
- 無法在投票時參加的任何人都可以提前登記投票。
- 除了顧問委員會或 TSC 成員資格的變更需要三分之二的投票外，其餘投票將為簡單多數決。
對於在工作小組內做出的決策，應盡一切努力在工作小組內部解決問題；工作小組內部無法解決的問題可以上報給 TSC。
顧問委員會、TSC 和工作小組做出的決策必須公開記錄（除非出於法律或安全原因而無法公開）。
決策應透過非同步溝通管道做出。如果不是這種情況（例如透過視訊會議或面對面會議），則在決策批准之前應允許一段合理的時間提出異議。
如果有新的技術資訊可用，則可以重新審視決策。
顧問委員會、TSC 和工作小組可以舉行電話會議、視訊會議和面對面會議。這些會議應提前充分宣布，並發布議程。應提供一種機制，讓社群可以提出議程項目。

AMP 專案要求所有開啟提取請求的擁有者、協作者和貢獻者，必須接受個人貢獻者授權協議 (CLA) 的條款，或受公司 CLA 的約束，以保護貢獻者和使用者在智慧財產權問題上的權益。
尚未受個人或公司 CLA 約束的 TSC 成員，在加入 TSC 時必須受其約束。
AC 成員並未正式要求受 CLA 約束，但如果他們決定以需要確保 IP 承諾的方式為專案做出貢獻（例如透過貢獻程式碼、文件、規格或設計文件）以保持專案開源和免版稅，則將被要求受 CLA 約束。