Fuchsia 協作者角色

總覽

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

原則

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

• 資訊公開我們會公開說明角色和相關規定。
• 包容性：Fuchsia 允許任何人為專案做出貢獻，不論他們的雇主為何。我們認為，多元開放原始碼社群的貢獻對於改善 Fuchsia 至關重要。
• 責任。如果使用者不再符合規定，您可以撤銷其角色和權限。

角色

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

• 成員
• Committer
• 擁有者
• 全球核准者

成員

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

職責

成員必須遵守 Fuchsia 行為準則。

成為會員

如要成為會員，您必須完成下列步驟：

• 簽署 Google 開發人員的貢獻者授權協議。
• 確認您已瞭解 Fuchsia 行為準則。

修訂者

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

提交者不僅可以進行變更，也必須證明自己能夠與 Fuchsia 社群的其他成員有效合作。協作活動的例子包括但不限於：

• 尋找最具備知識的人員來審查程式碼變更。
• 提供經過充分測試的高品質程式碼。
• 修正程式碼或測試中的錯誤。

成員可以透過不同類型的貢獻成為 Committer。舉例來說，如果您負責撰寫文件或工具鍊，只要貢獻高品質的文件或設定變更，即可符合成為提交者的要求，但這類變更並未達到「傳統」測試良好程式碼的標準。

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

職責

提交者負責下列事項：

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

成為提交者

如要成為提交者，您必須完成下列步驟：

• 為專案提供 10 個非簡單的修補程式，展現您有能力編寫高品質且經過充分測試的程式碼。
• 由已審查您的程式碼的現任提交者提名。
• 獲得其他兩位已審查程式碼的提交者支持。
• 確認提名並未遭任何提交者封鎖。

現任提交者可透過電子郵件將您提名為提交者，並在郵件中附上以下資訊。請勿在提名電子郵件中副本給提名對象。

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

其他兩位提名者必須附議。如果在 5 個工作天 (美國時間) 內沒有人提出異議，您就會成為提交者。如果有人反對或想要更多資訊，則提交者會討論，並通常在 5 個工作天內達成共識。如果問題無法解決，現有提交者會進行投票。

大功告成！你不需要採取進一步行動。一旦做出決定，承諾人就會與您聯絡。

最糟的情況是，這可能會拖延兩週。請繼續撰寫修補程式！即使在極少數的情況下，如果提名失敗，通常只要解決「需要更多修補程式」或「沒有足夠的人熟悉這個人的成果」等問題，就能夠解決異議。

一旦獲得現有提交者核准，Fuchsia 社群管理員就會將您加入 committers@fuchsia.dev，並提供一些額外資訊，說明如何以外部貢獻者身分提交貢獻內容。

試用工作存取功能

如果您是修補程式貢獻者，但尚未成為提交者，您可能希望能夠直接在 Try 伺服器上執行工作，而非要求提交者或審查者代為執行。

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

• 請與您合作的提交者 (例如常見的審查者) 傳送電子郵件至 committers@fuchsia.dev，推薦您試用工作存取權。
• 您必須提供電子郵件地址，並簡要說明您為何需要存取權。
• 建議您一併提供姓名和公司關係 (如有)。
• 已完成部分修補程式會非常有幫助，但並非絕對必要。
• 如果在兩個 (美國) 工作天內沒有人提出異議，我們就會核准您存取資料。授權可能需要再過幾天才能傳播到所有系統。

擁有者

擁有者負責 Fuchsia 專案中的檔案或目錄，並對該子樹中的程式碼有全面的瞭解。OWNERS 檔案會列出擁有者。如果目錄或檔案不在擁有者負責範圍內，該擁有者就會擁有與提交者相同的權限。

我們建議提交者保持 OWNERS 檔案的最新狀態。

職責

除了承擔承諾人和成員的責任外，擁有者還須負責下列事項：

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

成為擁有者

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

• 成為承諾人。
• 針對受影響的子樹提交大量非瑣碎的變更。
• 提供優質評論和程式碼設計意見回饋。
• 及時提供程式碼審查。
• 自行提名或由其他提交者提名。
  • 如要自行提名，請提交 Gerrit 變更，將自己加入所需存放區的 OWNERS 檔案。目前的擁有者會評估您的變更，並接受或拒絕您的要求。

全球核准者

全球核准者是 owners-override@fuchsia.dev 群組的成員。全域核准者可以在 Gerrit 中叫用「Owners-override」位元，免除變更的 OWNERS 規定。

雖然全域核准者有權針對大規模變更提供「擁有者覆寫 +1」權限，但不應具備整個 Fuchsia 程式碼集的完整知識。預期全域核准功能主要用於變更為系統性、機械性且影響大部分程式碼庫的情況。如果需要進行緊急變更來穩定樹狀結構，例如 CL 用於停用測試或無法自動核准的複雜還原，則全球核准也許是適當的做法。

目前，Fuchsia Engineering Council 成員是全球核准者，以及少數審查人員，負責處理沒有 FEC 成員的時區。如果提交者遇到現有程式碼擁有者無法提供審查涵蓋率的情況，建議先傳送變更來更新本機 OWNERS 檔案，或是新增頂層的個別檔案規則，以涵蓋特定類型的檔案，例如 **/BUILD.gn 或 **/*.md。如果這項做法不足以解決問題，提交者應傳送電子郵件至 owners-override@fuchsia.dev，討論這個問題。

職責

除了成員、提交者和擁有者的責任外，全球核准者還須負責下列事項：

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

程式碼審查動作

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

啟動 CQ 模擬測試

CQ 模擬執行作業會針對提交佇列中的可用測試執行變更。提交者、擁有者和全球核准者可以啟動 CQ 模擬測試。

程式碼審查分數

程式碼審查

您提出程式碼審查要求後，審查人員就能評分您的變更內容。

審查員可以為變更標示分數，分數為 -2、-1、0、+1 或 +2。如要進一步瞭解審查標籤定義，請參閱「Gerrit 程式碼審查 - 審查標籤」。

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

提交核准的變更

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

提交變更後，系統會將變更移至「提交佇列」(CQ)。提交佇列會驗證、提交及合併主要分支版本的變更。

角色矩陣

下表列出各 Fuchsia 貢獻者角色可執行的動作。

角色	建立變更	對其他提交者的變更進行程式碼審查	提供程式碼審查 +2	提供 CQ+1 (CQ 的模擬執行)	將核准的變更提交至 CQ	新增或移除擁有者
成員	是	否	否	否	否	否
修訂者	是	是	否	是	是	否
擁有者 (位於擁有子樹外)	是	是	否	是	是	否
擁有者 (在自己的子樹中)	是	是	是	是	是	是
全球核准者	是	是	是	是	是	是

變更的生命週期

下圖顯示在變更推送至 Gerrit 後，會發生哪些高階階段。

專業角色

除了上述要求外，Fuchsia 存放區中的各個區域可能會有各自的特殊需求，定義各自的角色和職責。

API 審查員

API 審查員負責審查 API 的品質和長期健康狀態。 API 審查員會共同組成 API 委員會。

除了一般 Code-Review+2 外，任何修改 Fuchsia API 途徑的變更都必須接受 API 委員會成員的 API-Review+1。

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

API Reviewer 會員

如要成為 API 審查員，您必須完成下列事項：

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

技術顧問委員會成員

Fuchsia 工程委員會是一小群由資深技術領導人組成的團隊，負責為 Fuchsia 提供一致的技術願景。工程委員會主要透過委派和核准的方式運作，向社群傳達工程標準、價值和目標，然後審查及核准來自專案貢獻者的具體工程提案。

英格蘭理事會會員

工程委員會成員人數沒有預先設定的限制。不過，為了提供一致的技術願景，委員會成員人數不多。工程委員會成員是由專案管理機構任命。詳情請參閱 Fuchsia Eng Council Charter 中的「成員資格」。

撤銷權限

如果貢獻者不再符合規定，我們可以撤銷他們的角色和對應權限。

情境

導致權限遭到撤銷的情境示例包括但不限於：

• 未依據 Fuchsia 行為準則行事。
• 提交者在程式碼審查中一再忽略可測試性最佳做法。
• 擁有者不鼓勵使用者要求程式碼審查。
• 業主未回應審查要求。

程序

在 Fuchsia 專案中撤銷個人角色的程序包括下列步驟：

• 版主向 community-managers@fuchsia.dev 提出建議，要求撤銷某人的角色，並說明原因。如要撤銷擁有者角色，必須由同一個子樹或更高層級的擁有者核准。
  • 當擁有者不再積極為相關檔案或目錄做出貢獻時，系統通常會撤銷擁有權。

撤銷提交者角色的情況應該很少發生，且需要管理機構核准。社群管理員應參與撤銷提交者角色的程序。

常見問題

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

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