Fuchsia 協作者角色

總覽

本文件定義了為 Fuchsia 專案提供內容的相關角色。

原則

Fuchsia 專案中的角色旨在體現以下原則：

• 資訊公開。我們會公開說明職務和要求的相關事宜。
• 多元包容：Fuchsia 讓任何人都能參與專案，不受僱主影響。我們相信，來自不同開放原始碼社群的貢獻對於改善 Fuchsia 至關重要。
• 責任。如果某人不再符合需求，則可撤銷角色和權限。

角色

以下是與 Fuchsia 專案相關聯的協作者角色：

• 成員
• 修訂者
• 負責人
• 全球核准者

成員

任何參與專案的人員，均提供程式碼或說明文件的修補程式，並同意 Google Developers 的貢獻者授權協議。

責任感

成員有責任依據《Fuchsia Code of Conduct》採取行動。

加入會員

你必須符合下列條件才能成為會員：

• 簽署 Google Developers 的《貢獻者授權協議》。
• 同意《Fuchsia Code of Conduct》。

修訂者

修訂者是擁有 Fuchsia 存放區寫入權限的人員。修訂者可以從其他成員提交自己的 Gerrit 變更或 Gerrit 變更。

「Committer」不僅是能夠變更內容的人，也能展現與 Fuchsia 社群成員有效協作的能力。協作活動範例包括但不限於：

• 尋求最瞭解相關人員檢查程式碼變更情形。
• 提供通過優質測試的優質程式碼。
• 修正程式碼或測試中的錯誤。

成員可以成為具有不同貢獻的委員會。例如，負責說明文件或工具鍊的員工可以提供高品質的說明文件或設定變更，進而符合成為修訂者的需求，這類變更不符合通過完整測試程式碼的「傳統」列。

如要提交 Gerrit 變更，修訂者必須是受影響檔案的擁有者，或獲得受影響檔案擁有者的核准。

責任感

修訂者負責以下事項：

• 確保由修訂者提交至 Fuchsia 的程式碼會根據可測試性評分量表進行測試。
• 確保修訂者提交至 Fuchsia 的程式碼遵循測試最佳做法。

成為經營者

如要成為修訂者，您必須執行下列操作：

• 為專案提供 10 個重要修補程式，展現自己有能力編寫通過良好測試的優質程式碼。
• 由已審查程式碼的目前修訂者提名。
• 使用其他已審查程式碼的另外兩個修訂者提供支援。
• 確保所有修訂者未封鎖您的提名。

目前的委員會提名您，方法是傳送電子郵件至 Committers@fuchsia.dev 提及，並在信中附上以下資訊。請勿傳送副本給入圍者的電子郵件。

• 您的全名。
• 你的電子郵件地址。
• 說明您為何應成為修訂者。
• 含有修補程式的修訂版本連結清單 (約前 10 名)。

您還需要另外兩家核准者擔任提名。如果 5 個工作日 (美國) 內沒有任何物件，表示您已成為修訂者。如有任何人有異議或想瞭解更多資訊，委員會在 5 個工作日內會討論並通常會尋求共識。如果問題仍未解決，則會在目前的承諾使用計畫進行投票。

大功告成！您無須採取其他行動。核准者會在做出決定後回覆你。

最糟的情況是，這個過程可能需要長達兩週。繼續編寫修補程式！即使提名失敗的罕見情況下，推拒通常是輕鬆解決的，如「更多修補程式」或「沒有足夠人熟悉這個人的工作」。

取得現有修訂者的核准後，Fuchsia 社群管理員就會將您新增至 committers@fuchsia.dev，並詢問關於以外部貢獻者身分提交貢獻的其他資訊。

試用工作存取權

如果您只是要提供修補程式，但尚未 (尚未成為修訂者)，您可能會希望可以直接在嘗試伺服器上執行工作，而不是要求修訂者或審查人員代您執行工作。

取得嘗試工作存取權的程序如下：

• 要求合作的委員會 (例如，經常審查人員) 傳送電子郵件至 committers@fuchsia.dev 推薦您試用工作存取權。
• 您必須提供電子郵件地址，並至少說明您想要存取的原因。
• 建議您一併提供名稱及公司聯盟 (如果有的話)。
• 發布一些修補程式會很有幫助，但這並非絕對必要。
• 如果在兩個工作日 (美國) 的工作日內沒有任何物件，你就能取得存取權限。授權可能需要幾天的時間才會套用到所有系統。

擁有者

擁有者負責 Fuchsia 專案中的檔案或目錄，並具備該子樹狀結構中程式碼的完整知識。擁有者會列在 OWNERS 檔案中。針對不在擁有者責任的目錄或檔案，該擁有者俱備與修訂者相同的權限。

我們建議簽署人將 OWNERS 檔案保持在最新狀態。

責任感

除了修訂者和成員的責任之外，擁有者還負責執行下列作業：

• 指派其他擁有者。
• 核准或移除其他擁有者。
• 提供優質評論及設計意見回饋。
• 核准子樹狀結構中的程式碼變更。

成為擁有者

如要成為擁有者，你必須採取下列行動：

• 成為修訂者。
• 針對受影響的子樹狀結構提交大量重大變更。
• 提供優質審查和程式碼設計意見回饋。
• 及時提供程式碼審查。
• 自行提名或由其他修訂者提名。
  • 如要自行提名，請提交 Gerrit 變更，並將自己新增至所需存放區的 OWNERS 檔案中。目前的擁有者將評估您的變更，並選擇接受或拒絕要求。

全球核准者

全域核准者是 Owner-override@fuchsia.dev 群組的成員。全域核准者可在 Gerrit 中叫用擁有者覆寫位元，免除變更的 OWNERS 要求。

雖然全域核准者可提供擁有者覆寫 +1 給大規模變更，但全球核准者並不能充分掌握整個 Fuchsia 程式碼集的專業知識。一般而言，大部分的變更會用於系統性變更，主要是機械性，且會影響極大的程式碼集。

目前，Fuchsia Engineering Council 的成員均俱全球影響力，另外還有少數審查人員會負擔沒有 FEC 成員的時區。如果修訂器遇到現有程式碼擁有者無法提供審查涵蓋範圍的情況，我們會建議先傳送變更來更新本機 OWNERS 檔案，或新增適用於特定檔案類型的頂層規則，例如 **/BUILD.gn 或 **/*.md。如果不確定性不足，則修訂版本應傳送電子郵件至 Owner-override@fuchsia.dev 討論問題。

責任感

除了成員、修訂者和擁有者的責任之外，全球核准者還負責執行下列作業：

• 在 Gerrit 中使用擁有者覆寫 +1 核准 Fuchsia 程式碼集內的大規模變更。
• 針對大規模的變動適時提供審查。

程式碼審查動作

您可提供的程式碼審查動作類型，取決於您在 Fuchsia 專案中的角色。

啟動 CQ 模擬執行作業

CQ 模擬測試會針對修訂版本佇列中可用的測試執行變更。核准者、擁有者和全球核准者可以啟動 CQ 模擬測試。

評分程式碼

程式碼審查

您提出程式碼審查申請後，審查人員就能為您的變更評分。

審查人員可使用 -2、-1、0、+1 或 +2 來為您的變更加上標籤。如要進一步瞭解如何查看標籤定義，請參閱「Gerrit Code Review - 審查標籤」。

修訂者、擁有者和全域核准者可以為程式碼審查評分，但只有全域核准者或存放區擁有者可以提供 +2。

提交已核准的變更

您需要程式碼審查標籤 +2 才能提交變更。程式碼審查標籤 +2 分數只能由存放區擁有者或全域核准者套用。

提交變更之後，變更會移至修訂版本佇列 (CQ)。修訂版本佇列會驗證、修訂及合併主要分支版本的變更。

角色矩陣

下表摘要說明每個 Fuchsia 貢獻者角色可執行的動作。

角色	建立變更	查看其他修訂者變更的程式碼	提供程式碼審查 +2	提供 CQ+1 (CQ 模擬測試)	提交已獲準的 CQ 變更	新增或移除擁有者
成員	是	否	否	否	否	否
修訂者	是	是	否	是	是	否
擁有者 (非自有的子樹狀結構)	是	是	否	是	是	否
擁有者 (位於子樹狀結構)	是	是	是	是	是	是
全球核准者	是	是	是	是	是	是

改變的流程

下圖說明在推送至 Gerrit 後，變更的大致階段。

專業角色

Fuchsia 存放區中的區域可能有獨特需求，除了上文詳述的角色和職責組合外，也可能有不同的角色和責任。

API 審查者

API 審查人員共同構成 API 委員會。

任何會修改 Fuchsia API 途徑的變更，都必須收到 API 委員會成員提供的 API-Review+1，除了一般的程式碼審查+2。

如要進一步瞭解 API 審查人員的責任以及 API 委員會的運作方式，請參閱 API 委員會憲章。

API 審查者成員資格

如要成為 API 審查者，您必須執行下列操作：

• 成為修訂者。
• 針對 API 品質和長期健康狀態做出良好的判斷。
• 根據 API 委員會頒獎典禮，由 Fuchsia 專案的職務領域負責。

工程委員會成員

Fuchsia Eng Council 是一群資深技術部門主管，負責為 Fuchsia 實現一致的技術願景。工程委員會主要是透過委任和統整、在整個社群傳達工程標準、價值和目標，然後審查及統整來自專案貢獻者的具體工程提案。

Eng Council 會員

恩格議會沒有預定人數。但為了提供一致的技術願景，委員會人數較少。工程委員會成員是由專案的主管機關指派。詳情請查看 Fuchsia Eng Council Charter 的會員資格。

撤銷權限

協作者不再符合要求時，即可撤銷其角色和對應的權限。

情境

撤銷權限的情境範例包括但不限於以下：

• 未遵守《Fuchsia 行為準則》的規定。
• 修訂者在程式碼審查中屢次忽略可測試性的最佳做法。
• 擁有者會勸阻使用者要求審查程式碼。
• 擁有者未回應審查要求。

程序

在 Fuchsia 專案中，撤銷個人角色的程序涉及下列步驟：

• 擁有者向 community-managers@fuchsia.dev 提出建議，藉此撤銷某人的角色並說明原因。如要撤銷擁有者角色，必須由該子樹狀結構或更高層級的擁有者核准。
  • 如果擁有者不再主動授予關聯檔案或目錄，擁有權通常會撤銷。

撤銷「修訂者」角色應該是很罕見的動作，且必須獲得政府機關核准。社群管理員應參與撤銷「委員會」角色的程序。

常見問題

身為 Fuchsia 成員，對於要求程式碼審查，您可能會遇到下列問題：

• 誰可以提供程式碼審查 +1？
  • 所有核准者、擁有者和全域核准者。程式碼審查 +1 代表「看起來不錯」，但光是 +1 就會無法提交。有人必須以 +2 核准變更。如要進一步瞭解如何查看標籤定義，請參閱 Gerrit 程式碼審查 - 審查標籤。
• Fuchsia 原始碼中某些部分是否有不同的規定？
  • 需要。舉例來說，API 變更具有特殊需求條件，如同 Fuchsia API 理事會憲章中所述。
• 是否需要 API 審查 +1？
  • 影響 Fuchsia API 介面的變更需要 API 審查 +1，而程式碼審查工具只會在需要時顯示 API 審查標記。