Fuchsia 協作者角色

總覽

本文定義與貢獻 Fuchsia 專案相關聯的角色。

原則

Fuchsia 專案中的角色應體現下列原則：

  • 資訊公開。我們會公開說明職責和要求。
  • 包容性。無論雇主為何，任何人都能為 Fuchsia 專案貢獻心力。我們認為，多元的開放原始碼社群貢獻是改善 Fuchsia 的關鍵。
  • 責任。如果使用者不再符合資格，系統可能會撤銷其角色和權限。

角色

以下是與 Fuchsia 專案相關聯的貢獻者角色：

成員

凡是提供程式碼或文件修補程式，並同意 Google Developers 的《貢獻者授權協議》，即為專案貢獻者。

職責

成員有責任遵守 Fuchsia 行為準則。

成為成員

如要成為會員，請完成下列步驟：

修訂者

提交者是指具備 Fuchsia 存放區寫入權限的人員。提交者可以提交自己的 Gerrit 變更，也可以提交任何其他成員的 Gerrit 變更。

提交者不僅要能進行變更，還必須展現與其他 Fuchsia 社群成員有效協作的能力。協作活動包括但不限於：

  • 尋找最瞭解情況的人員來審查程式碼變更。
  • 貢獻經過充分測試的高品質程式碼。
  • 修正程式碼或測試中的錯誤。

成員可以透過不同類型的貢獻成為提交者。舉例來說，從事文件或工具鍊工作的人員，可以透過提供高品質文件或設定變更，達到成為提交者的條件，這類貢獻不符合「傳統」的經過充分測試的程式碼標準。

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

職責

提交者負責下列事項：

  • 確保提交給 Fuchsia 的程式碼已根據可測試性評量標準進行測試。
  • 確保提交給 Fuchsia 的程式碼遵循測試最佳做法。

成為修訂者

如要成為提交者，請完成下列步驟：

  • 為專案提供 10 個非微不足道的修補程式，展現撰寫高品質且經過充分測試的程式碼能力。
  • 由審查過您程式碼的現任提交者提名。
  • 獲得另外兩位審查過您程式碼的提交者支援。
  • 確認提名未遭到任何提交者封鎖。

現任修訂者會傳送電子郵件至 committers@fuchsia.dev，內含下列資訊，提名您為修訂者。請勿在提名電子郵件中將副本傳送給被提名人。

  • 您的全名。
  • 你的電子郵件地址。
  • 說明您應成為提交者的原因。
  • 內嵌修訂版本連結清單 (約前 10 個)，其中包含您的修補程式。

另外兩位提交者必須附議你的提名。如果沒有人在 5 個工作天內 (美國) 提出異議，您就是提交者。如有任何人反對或想瞭解更多資訊，提交者會進行討論，通常會在 5 個工作天內達成共識。如果無法解決問題，現任提交者會進行投票。

大功告成！您無須採取任何行動，提交者做出決定後，我們會再通知你。

最糟的情況是，這項程序可能會拖延兩週。請繼續撰寫修補程式！即使在極少數的提名失敗案例中，反對意見通常也很容易解決，例如「需要更多修補程式」或「不夠多人熟悉此人的工作」。

獲得現有提交者核准後，Fuchsia 社群管理員會將你新增至 committers@fuchsia.dev，並提供其他資訊，說明如何以外部貢獻者身分提交貢獻。

嘗試存取工作

如果您是貢獻修補程式，但還不是提交者，您可能希望能夠直接在試用伺服器上執行工作，而不是要求提交者或審查者為您執行。

如要取得試用工作存取權，請按照下列步驟操作：

  • 請與您合作的提交者 (例如經常審查者) 傳送電子郵件至 committers@fuchsia.dev，提名您取得試用工作存取權。
  • 你必須提供電子郵件地址，並簡短說明想取得存取權的原因。
  • 請一併提供姓名和公司隸屬關係 (如有)。
  • 如果已有一些修補程式上線，會很有幫助，但並非絕對必要。
  • 如果沒有人在兩 (美國) 個工作天內提出異議，您就會獲得存取權。授權可能需要幾天才能傳播至所有系統。

擁有者

擁有者負責 Fuchsia 專案中的檔案或目錄，並對該子樹狀結構中的程式碼有全面瞭解。擁有者會列在 OWNERS 檔案中。如果目錄或檔案超出擁有者的職責範圍，該擁有者會具備與修訂者相同的權限。

建議提交者隨時更新 OWNERS 檔案。

職責

除了修訂者和成員的責任外，擁有者還須負責下列事項：

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

成為擁有者

如要成為擁有者，請完成下列步驟：

  • 成為修訂者。
  • 對受影響的子樹提交大量非微不足道的變更。
  • 提供優質評論和程式碼設計意見回饋。
  • 及時提供程式碼審查。
  • 自行提名或由其他提交者提名。
    • 如要自行提名，請提交 Gerrit 變更，將自己新增至所需存放區的 OWNERS 檔案。現任擁有者會評估您的變更，並接受或拒絕您的要求。

全球核准者

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

雖然全域核准者有權為大規模變更提供擁有者覆寫 +1，但我們不期望全域核准者對整個 Fuchsia 程式碼集有全面瞭解。預期全域核准主要用於系統性、大致上是機械式，且影響大部分程式碼集的變更。如果需要緊急變更來穩定樹狀結構，例如停用測試的 CL，或是無法自動核准的複雜還原作業，也適合採用全域核准。

目前，Fuchsia 工程委員會成員是全球核准者，另外還有少數審查者，負責涵蓋沒有 FEC 成員的時區。如果現有程式碼擁有者無法提供審查涵蓋範圍，建議提交者先傳送變更來更新本機 OWNERS 檔案，或新增頂層的檔案規則，涵蓋特定類型的檔案，例如 **/BUILD.gn 或 **/*.md。如果這樣仍不夠，提交者應傳送電子郵件至 owners-override@fuchsia.dev，討論這個問題。

職責

除了成員、修訂者和擁有者的責任外，全球核准者還負責以下事項：

  • 在 Gerrit 中，使用 Owners-override +1 核准 Fuchsia 程式碼集的大規模變更。
  • 及時審查大規模變更。

程式碼審查動作

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

啟動 CQ 模擬測試

CQ Dry Run 會根據 Commit Queue 中的可用測試，執行變更。 提交者、擁有者和全域核准者可以啟動 CQ 試執行。

為程式碼審查評分

程式碼審查

提出程式碼審查要求後，審查人員可以為您的變更評分。

審查員可以為您的變更加上 -2、-1、0、+1 或 +2 的分數。如要進一步瞭解審查標籤定義，請參閱「Gerrit Code Review - Review Labels」。

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

提交核准的變更

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

提交變更後，變更會移至提交佇列 (CQ)。提交佇列會驗證、提交變更，並將變更合併至主要分支版本。

角色矩陣

下表彙整了各 Fuchsia 貢獻者角色可執行的動作。

角色 建立變更 審查其他提交者的變更 提供 Code-Review +2 提供 CQ+1 (CQ 模擬測試) 將核准的變更提交至 CQ 新增或移除擁有者
成員 是 否 否 否 否 否
修訂者 是 是 否 是 是 否
擁有者 (外部擁有的子樹狀結構) 是 是 否 是 是 否
擁有者 (位於自己的子樹狀結構中) 是 是 是 是 是 是
全球核准者 是 是 是 是 是 是

變更的生命週期

下圖顯示變更推送至 Gerrit 後，會經歷哪些高階階段。

圖表：推送至 Gerrit 後，變更核准程序的高階階段。

專用角色

除了上述詳細說明的內容外，Fuchsia 存放區中的區域可能會有自己的獨特需求，定義自己的角色和職責組合。

API 審查員

API 審查員負責 Fuchsia API 介面的品質和長期健康狀態。 <0xAPI 審查員共同組成 API 委員會。

凡是修改 Fuchsia API Surface 的變更，除了通常的 Code-Review+2 之外，還必須獲得 API Council 成員的 API-Review+1。

如要進一步瞭解 API 審查員的職責和 API 委員會的運作方式，請參閱 API 委員會章程。

API 審查員會員資格

如要成為 API 審查員，請執行下列操作：

  • 成為修訂者。
  • 展現對 API 品質和長期健康狀態的良好判斷力。
  • 根據 API 委員會章程，由 Fuchsia 專案的功能領域指派。

英格蘭議會議員

Fuchsia 工程委員會是由一小群資深技術領導者組成，負責為 Fuchsia 提供一致的技術願景。工程委員會主要透過授權和批准運作，在整個社群中傳達工程標準、價值觀和目標，然後審查並批准專案貢獻者的具體工程提案。

英格蘭委員會成員

工程委員會的人數沒有預先設定上限。不過，為了提供連貫的技術願景，委員會成員人數不多。Eng Council 成員由專案管理機構指派。詳情請參閱 Fuchsia 工程委員會章程中的「成員資格」。

撤銷權限

如果貢獻者不再符合規定，系統可能會撤銷其角色和相應權限。

Scenarios

以下是可能導致權限遭撤銷的情境範例：

  • 未遵守 Fuchsia 程式碼行為準則。
  • 提交者在程式碼審查中，一再忽略可測試性最佳做法。
  • 擁有者阻止使用者要求程式碼審查。
  • 業主未回應審查要求。

程序

如要撤銷個人在 Fuchsia 專案中的角色，請按照下列步驟操作：

  • 擁有者向 community-managers@fuchsia.dev 建議撤銷某人的角色，並說明理由。如要撤銷擁有者角色，必須由同一子樹狀結構或更上層的擁有者核准。
    • 如果擁有者不再積極參與相關檔案或目錄的作業，系統通常會撤銷擁有權。

撤銷提交者角色是罕見的動作，需要經過管理機構核准。撤銷提交者角色時，應請社群管理員參與。

常見問題

身為 Fuchsia 成員，您可能對要求程式碼審查有以下疑問：

  • 誰可以提供「程式碼審查 +1」？
    • 所有提交者、擁有者和全域核准者。程式碼審查 +1 表示「我認為沒問題」，但單獨 +1 無法提交。其他人必須以 +2 核准變更。如要進一步瞭解審查標籤定義，請參閱「Gerrit Code Review - Review Labels」。
  • Fuchsia 原始碼的特定部分是否可以有不同的需求？
  • 我是否需要 API-Review +1？
    • 影響 Fuchsia API 介面的變更需要 API-Review +1，且程式碼審查工具只會在需要時顯示 API-Review 旗標。