Fuchsia 協作者角色

總覽

本文件定義了促成以下項目的相關角色： Fuchsia 專案。

原則

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

• 資訊公開。我們對於職務和需求公開透明且公開透明。
• 多元包容。Fuchsia 可讓任何人在專案中貢獻內容 我們相信許多開放原始碼的貢獻 就讓福希西亞人受惠
• 責任。如果使用者沒有這項權限，系統可能會撤銷角色和權限 符合相關規定

角色

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

• 成員
• 修訂者
• 擁有者
• 全球核准者

成員

參與專案的人員，只要為程式碼或 說明文件，並同意 Google Developers 的協作者授權協議。

職責

成員有責任根據 Fuchsia 行為準則。

加入會員

如要成為會員，您必須執行下列操作：

• 簽署 Google Developers協作者授權協議。
• 瞭解《Fuchsia 行為準則》。

修訂者

修訂版本是具有寫入權限的人員 Fuchsia 存放區。修訂者可以提交 自己的 Gerrit 變更，或對其他成員進行 Gerrit 變更。

委員會不僅是能夠進行變更的人員 證明自己能與 Fuchsia 社群。協作活動例子包括但不限於 改為：

• 尋找最知識豐富的人員來檢查程式碼變更。
• 提供經過完整測試的優質程式碼。
• 修正程式碼或測試中的錯誤。

成員可以成為有不同貢獻內容的委員會。適用對象 例如，處理文件或工具鍊的人員即可滿足 提供高品質的說明文件或設定，成為委員會 並不符合「傳統」上經過完善測試的程式碼。

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

職責

提交者必須負責下列事項：

• 確認修訂者提交給 Fuchsia 的程式碼是否經過測試 測試用評分量表。
• 確認修訂版本提交到 Fuchsia 的程式碼符合測試 最佳做法

成為委員會

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

• 為專案提供 10 個重要修補程式，展現出 撰寫經過完整測試的優質程式碼
• 獲得已審查您程式碼的現任委員會提名。
• 由已審查您程式碼的其他兩個委員會提供支援。
• 確保沒有遭任何修訂版本封鎖您的提名。

目前的委員會將傳送電子郵件給您，方法是將內含 下列資訊。請勿將提名電子郵件寄給提名者。

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

另外兩個委員會需要接受你的提名。如果 5 個工作日 (美國) 中沒有任何物體 您是委員會如果有任何人或需要更多資訊，委員會會討論並通常 遇到共識 (在 5 個工作日內)。如果問題無法解決，則由 目前的修訂版本。

大功告成！您無須採取其他行動。修訂版本會回到 做出決定

在最糟的情況下，這可能會拖慢兩週的時間。繼續編寫修補程式！即使是極少數的情況 拒絕提名失敗時，推拒說詞通常難以解決，例如「補充修補程式」或 「不夠熟悉這個人的工作內容。」

獲得現有委員會的核准者核准後，Fchsia 社群管理員會將您新增至 Committers@fuchsia.dev 與我們聯絡，並提供有關提交貢獻內容的額外資訊 以外部貢獻者的身分參與

試用工作存取權

如果您提供修補程式，但尚未提供修訂版本，您可能會希望在 直接嘗試伺服器，不要請修訂版本或審查人員為您代勞。

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

• 請您的合作委員會 (例如：經常審查人員) 傳送電子郵件至 Committers@fuchsia.dev 提名你試用工作機會。
• 您必須提供電子郵件地址，並至少簡短說明您希望取得存取權的原因。
• 您也可以一併提供名稱和公司的聯盟關係 (如有)。
• 確實登陸某些修補程式，是非常實用的做法，但並非絕對必要。
• 如果兩個 (美國) 工作日內沒有任何物體，即獲準存取。這可能需要 再過幾天，該設定就會套用至所有系統。

擁有者

擁有者負責管理 Fuchsia 專案中的檔案或目錄， 能全面瞭解子樹狀結構中的程式碼。擁有者已列於 OWNERS 個檔案。擁有者檔案以外的目錄或檔案 擁有者與修訂者俱備相同權限。

建議修訂者將 OWNERS 檔案保持在最新狀態。

職責

除了擔任委員會與成員的責任外，擁有者也 負責下列事項：

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

成為擁有者

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

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

全球核准者

全球核准者是 owner-override@fuchsia.dev 的成員 群組。全域核准者可以在以下位置叫用擁有者覆寫位元： Gerrit 不僅拋棄一項變更的 OWNERS 要求，

全球核准者仍可提供擁有者覆寫 +1 的權限 並不需要因應大規模的變動 對整個 Fuchsia 程式碼集的詳盡知識。這是正常情況 全球核准主要用於全球變更 對教師而言主要是系統化的機械運算 程式碼集如果企業未確認 必須立即變更才能穩定樹狀結構，例如使用 CL 來停用 測試或複雜還原程序

Fuchsia Engineering Council 計畫的成員目前在全球範圍內 和少數審查者以及負責時區的審查人員 沒有 FEC 成員會遇到下列情況的修訂版本 建議程式碼擁有者無法提供評論涵蓋範圍，建議先從這裡著手 傳送變更，更新本機 OWNERS 檔案，或新增 包括特定類型檔案 (例如 **/BUILD.gn 或 **/*.md。倘若這種情況已證明不足 修訂者應傳送電子郵件至擁有者覆寫@fuchsia.dev 進行討論 問題。

職責

除了成員、委員會和負責人的責任外，全球 核准者有責任的工作如下：

• 使用 Gerrit 中的擁有者覆寫 +1。
• 針對大規模變更即時提供審查。

程式碼審查動作

您可以提供的程式碼審查動作類型，視您在內部的角色而定 Fuchsia 專案。

啟動 CQ 模擬測試

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

評分程式碼審查

程式碼審查

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

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

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

提交已核准的變更內容

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

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

角色矩陣

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

角色	建立變更	程式碼-審查其他委員會做出的變更	提供程式碼審查 +2	提供 CQ+1 (CQ 模擬測試)	提交已核准的顧客資證明變更申請	新增或移除擁有者
成員	是	否	否	否	否	否
修訂者	是	是	否	是	是	否
擁有者 (不在主樹狀結構外)	是	是	否	是	是	否
擁有者 (在子樹狀結構中)	是	是	是	是	是	是
全球核准者	是	是	是	是	是	是

改變的流程

下圖說明變更發生後的大致階段。 。

特殊角色

Fuchsia 存放區中的區域可能有獨特需求 定義各自的角色和責任 。

API 審查者

API 審查人員必須對品質和長期關係負責 健康狀態 Fuchsia API 介面 ，直接在 Google Cloud 控制台實際操作。 API 審查人員統整形成 API 議會。

凡是修改 Fuchsia API 介面的變更，都必須收到「API-Review+1」。 。Code-Review+2。

進一步瞭解 API 審查人員的責任以及 API 方式 委員會負責營運，請參閱 API Council Charter。

API 審查者成員資格

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

• 成為修訂者。
• 展現 API 品質和長期健康狀態的良好判斷依據。
• 由 Fuchsia 專案的功能領域指派，如 API Council Charter 所示。

工程委員會成員

Fuchsia Eng Council 是一群負責任 AI 技術的 為 Fuchsia 提供堅實的技術願景。工程委員會主要是 運作環境為委任和計分、通訊工程標準 然後在整個社群中檢視並評分 專案貢獻者的具體工程提案。

工程委員會會員

工程委員會沒有預定人數。但 為了提供一致的技術願景，議會很少接受教育 成員。工程委員會成員擔任 專案。詳情請參閱「會員資格」一文 。

撤銷權限

當貢獻者不再符合要求時，他們的角色和 也可撤銷相應的權限

情境

使用者撤銷權限的情境示例，包括但不限於： 包括：

• 並非依據《Fuchsia 行為準則》。
• 委員會反覆忽略程式碼中的可測試性最佳做法 評論。
• 擁有者禁止使用者要求審查程式碼。
• 擁有者未回應審查要求。

程序

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

• 擁有者推薦了 community-managers@fuchsia.dev， 撤銷他人的角色，並具體說明原因。撤銷擁有者角色 必須由同一子樹狀結構的擁有者核准 或更高級別。
  • 擁有者不再主動撤銷擁有權時，經常會撤銷擁有權 提供給其他使用者的檔案或目錄

撤銷「修訂版本」角色是相當罕見的操作，而且需要經過 管理機構。您應邀請社群管理員參與 撤銷修訂版本角色。

常見問題

Fuchsia 成員對於 程式碼審查：

• 誰可以提供程式碼審查 +1？
  • 所有委員會、擁有者和全球核准者。程式碼審查 +1 代表 「我看起來不錯」，但單獨 +1 無法提交。 按下 +2 按鈕即可由他人核准變更。如要進一步瞭解 查看標籤定義，請參閱「Gerrit Code Review - Review Labels」一文。
• Fuchsia 原始碼的特定部分是否有不同的規定？
  • 可以。例如，API 變更具有特殊規定，如下所述： Fuchsia API Council Charter。
• 我需要 API 審查 +1 嗎？
  • 影響 Fuchsia API 介面的變更需要 API-Review +1， 程式碼審查工具只會在需要時顯示「API 審查」標記。