Selenium 專案治理

使用者

• 推廣專案（例如，在網站上顯示連結並透過口耳相傳提高知名度）
• 從新使用者的角度告知優缺點（例如，將錯誤作為 GitHub issue 提出、提出新功能建議）
• 提供精神支持（一句「謝謝」意義重大）

貢獻者

• 透過為此目的建立的溝通管道來協助其他使用者。

• Issue 分流 GitHub issue。
• 舉辦 Selenium 聚會。
• 組織並協辦 Selenium 會議。

對專案沒有承諾的期望、沒有特定的技能要求，也沒有選拔過程。根據貢獻類型，某些貢獻者可能對 GitHub 儲存庫有一些基本權限（例如，在 issue 分流後關閉 issue）。

貢獻者對原始碼具有唯讀存取權，並透過 pull request 提交變更。貢獻者的 pull request 會由技術領導委員會 (TLC) 成員或提交者審核並合併其貢獻。TLC 成員和提交者與貢獻者合作審核其程式碼並為合併做準備。

隨著貢獻者獲得專案的經驗和熟悉度，他們在社群中的形象和對社群的承諾將會增加。在某個階段，他們可能會發現自己被現有的提交者或 TLC 成員提名為提交者角色。

Issue 分流人員

成為 issue 分流人員的流程

1. 將 GitHub 使用者新增至 selenium-triage GitHub 團隊
2. 邀請加入 Slack 團隊聊天室 (selenium-tlc)
3. 從 SeleniumHQ Twitter 帳號發推文祝賀新的 issue 分流人員

文件撰寫者

成為文件撰寫者的流程

1. 將 GitHub 使用者新增至 selenium-docs-and-site GitHub 團隊
2. 邀請加入 Slack 團隊聊天室 (selenium-docs)
3. 從 SeleniumHQ Twitter 帳號發推文祝賀新的文件撰寫者

翻譯者

成為翻譯者的流程

1. 將 GitHub 使用者新增至 selenium-docs-and-site GitHub 團隊
2. 邀請加入 Slack 團隊聊天室 (selenium-docs)
3. 從 SeleniumHQ Twitter 帳號發推文祝賀新的翻譯者

專案提交者

提交者是社群成員，他們已展現透過持續參與社群，致力於專案的持續開發。提交者被授予他們貢獻的專案 GitHub 儲存庫的 push 存取權。

提交者

• 應先將其對專案程式碼進行重大變更的提案提交到 GitHub issue，並應 ping 所有相關提交者，以便他們在需要時參與討論。
• 提交者之間關於程式碼是否應合併的辯論應在 GitHub pull request 中進行，以保留專案決策歷史記錄。
• 一般而言，任何提交者都可以審核和合併 pull request。提交者應僅合併他們有資格審核的程式碼，這可能需要 ping 另一位對特定程式碼區域具有更大所有權的提交者。
• 可以標記和關閉 issue。

成為提交者

• 必須展現出作為團隊成員參與專案的意願和能力。
• 提交者應尊重每位社群成員，並以包容的精神協同合作。
• 已向一個或多個不同的專案（IDE、Docker-Selenium、Selenium、網站與文件）提交了足夠的實質性貢獻。對於技術貢獻，由於其文件完善且經過測試，因此具有足夠的份量且接受起來毫不費力。通常需要 10 項實質性貢獻才能符合成為提交者候選人的資格，但在某些情況下，貢獻足夠實質性，較少的數量也是可以接受的。

新的提交者可以由任何現有的提交者或 TLC 成員提名。一旦他們被提名，TLC 成員將根據共識尋求流程尋求決策。

重要的是要認識到，擔任提交者角色是一種特權，而不是權利。這種特權必須通過努力才能獲得，一旦獲得，可以由 TLC 成員通過標準 TLC 動議撤銷。然而，在正常情況下，只要提交者願意繼續參與專案，提交者角色就會一直存在。

對專案表現出高於平均水平貢獻的提交者，尤其是在策略方向和長期健康方面，可能會被提名成為 TLC 成員，如下所述。

新增提交者的流程

1. 將 GitHub 使用者新增至相關的 GitHub 團隊
   • selenium-committers 用於主要的 Selenium 儲存庫
   • selenium-ide 用於主要的 Selenium IDE 儲存庫
   • selenium-docs-and-site 用於網站和文件儲存庫
   • selenium-docker 用於 Docker-Selenium 儲存庫
2. 邀請加入 Slack 團隊聊天室 (selenium-committers)
3. 從 SeleniumHQ Twitter 帳號發推文祝賀新的提交者

要查看目前的提交者列表，請點擊此處。

技術領導委員會 (TLC)

Selenium 專案的技術決策和藍圖由技術領導委員會 (TLC) 管轄，該委員會負責專案的高階技術指導。

• 技術方向
• 儲存庫託管

• 貢獻政策（與專案領導委員會 (PLC) 共享）

TLC 席位沒有時間限制。TLC 沒有固定規模。TLC 的規模應足以確保充分涵蓋重要的專業知識領域，並兼顧有效率地做出決策的能力。

TLC 可以通過標準 TLC 動議向 TLC 新增其他成員。

TLC 成員可以通過自願辭職，或通過標準 TLC 或 PLC 動議從 TLC 中除名。

TLC 成員中，與同一雇主有關聯的人數不得超過 1/3。如果 TLC 成員的除名或辭職，或 TLC 成員的就業變更，導致超過 1/3 的 TLC 成員與同一雇主有關聯，則必須立即通過與超額代表雇主有關聯的一名或多名 TLC 成員的辭職或除名來補救這種情況。

TLC 成員除了提交者的職責外，還有額外的職責。這些職責確保專案以順暢的方式具有技術可行性和永續性。TLC 成員應審核程式碼貢獻、批准本文檔的變更，並管理專案輸出中的著作權。

• 在審核和批准變更後，可以合併已接受 issue 的 pull request，而無需 ping 可能對受影響的程式碼區域具有更大所有權的其他提交者，前提是審核和接受 pull request 不需要深入了解受影響的程式碼區域。
• 將程式碼直接 push 到儲存庫，或在必要時，在收集到他們認為必要的意見回饋後，建立並合併他們自己的 pull request。
• 每月討論一次技術狀態和專案藍圖。

• 以樂於助人和協作的方式與社群合作。
• 對其他人的提交給予了良好的意見回饋，並展現出對專案程式碼品質標準的整體理解。
• 承諾長期成為社群的一份子。
• 已在不同的專案（IDE、Docker-Selenium、Selenium、網站與文件）中提交至少 20 個實質性 pull request 或 push 至少 20 個實質性 commit。

提交者由現有的 TLC 成員邀請成為 TLC 成員。提名將導致討論，然後由 TLC 做出決定。

新增 TLC 成員的流程

1. 將 GitHub 使用者新增至 Selenium TLC 團隊
2. 將 GitHub 使用者設定為 SeleniumHQ 組織的「擁有者」角色
3. 邀請加入 Slack TLC 聊天室 (selenium-tlc)
4. 將 TLC 成員新增至不同的套件發佈組織
   • NPM
   • SonarType (maven)
   • pypi.org
   • rubygems.org
   • nuget.org
5. 從 SeleniumHQ Twitter 帳號發推文祝賀新的 TLC 成員

要查看目前的 TLC 成員列表，請點擊此處。

專案領導委員會 (PLC)

專案的整體延續性和未來由專案領導委員會 (PLC) 監督，該委員會充當 Selenium 專案與軟體自由保護協會 (SFC) 之間的橋樑。

由於 Selenium 專案有很多不同的方面，PLC 希望反映的不僅僅是編寫程式碼的人員。PLC 以不同的方式參與，例如專案花錢、簽訂法律協議或必須與律師打交道時。通常，PLC 會與社群其他成員討論該主題，然後進行投票。

標準 PLC 席位沒有時間限制。PLC 中一次只能有一人與任何特定雇主有關聯。PLC 成員人數應始終為奇數，以便永遠不會出現平票，理想的最小人數為 5 人。PLC 成員也應該是社群的活躍成員。

此外，TLC 可以進行投票，任命其成員之一擔任活躍的 PLC 成員。此人不受上述雇主限制的約束，但任命會在六個月結束時自動失效。PLC 中的 TLC 成員將使用他們的投票權來傳達 TLC 的意願。這可能需要該成員從 TLC 成員處進行投票，以建立共識，然後將共識代理到 PLC。如果在投票期間出現平票，TLC 代表的投票將決定勝負。

• 現有的 PLC 成員卸任並建議某人（或某些人）來接替他們。
• 成為提交者或貢獻者。
• 承諾長期成為社群的一份子。

• 現有的 PLC 會諮詢 TLC 和活躍的提交者，他們將根據共識尋求流程尋求是否新增這些人員的決策。

• 在事先與他們討論這個想法之前，永遠不會公開建議任何人（以確保他們對此感到滿意）。

• 專案治理和流程（包括本政策）。
• 貢獻政策（與 TLC 共享）。
• 預算和法律相關問題。

PLC 也應每月討論一次專案的整體狀態以及任何待處理或即將到來的議題。

PLC 成員可以通過自願辭職，或通過標準 PLC 動議從 PLC 中除名。

新增 PLC 成員的流程

1. 邀請加入 Slack PLC 聊天室 (selenium-plc)
2. 從 SeleniumHQ Twitter 帳號發推文祝賀新的 PLC 成員

要查看目前的 PLC 成員列表，請點擊此處。

溝通管道

專案維護各種管道，以提供資訊、支援開發並促進團隊成員之間的溝通。在這些管道中進行的所有類型的溝通都必須嚴格遵守專案的行為準則。

• Twitter 帳號 @seleniumhq：用於傳達和推廣圍繞專案或專案相關主題的新聞。

• 聊天室：供所有 Selenium 使用者尋求關於使用專案問題的幫助和支援的聊天室。

• Slack ：鏡像 IRC 聊天室，也供所有 Selenium 使用者尋求關於使用專案問題的幫助和支援。

• 專案提交者頻道，上述 Slack 頻道中的 selenium-committers：專案提交者團隊成員用於討論貢獻和組織其他協作工作的私人頻道。
• TLC 頻道，上述 Slack 頻道中的 selenium-tlc：TLC 成員用於討論技術規劃和技術專案藍圖的私人頻道。
• PLC 頻道，上述 Slack 頻道中的 selenium-plc：PLC 成員用於整體專案規劃、藍圖和相關議題的私人頻道。

共識尋求流程

PLC 和 TLC 遵循共識尋求決策模型。

當議程項目似乎已達成共識時，主持人將詢問「是否有人反對？」作為對共識的最終異議徵詢。

如果議程項目無法達成共識，PLC/TLC 成員可以呼籲進行結束投票或投票將關於該 issue 的進一步討論延遲到下次會議。投票的呼籲必須獲得 TSC 多數票的批准，否則討論將繼續。簡單多數票獲勝。

贊助

Selenium 專案是軟體自由保護協會的成員，軟體自由保護協會是一個 501(c)3 非營利組織。保護協會允許我們與其他專案（例如 Inkscape、Samba 和 Wine）集中組織資源，以減少與建立我們自己的專用法律實體相關的管理費用。

請在https://selenium.dev.org.tw/sponsor/查看更多詳細資訊

商業和社群驅動的專案

Selenium 專案提供的工具的廣泛使用，創造了大量的商業服務和開放原始碼/社群驅動的專案。Selenium 專案啟用並鼓勵任何人啟動任何類型的專案或服務，其目標是簡化和推廣 Selenium 在社群中的使用。

然而，由於 Selenium 專案的開放原始碼、社群和非營利性質，Selenium 專案在其網站上僅會提及基於 Selenium 或 WebDriver 的同性質專案，贊助者頁面除外。如果商業工具或專案希望在 Selenium 網站上被提及，請參閱本文檔的贊助章節。

提出與治理相關的 Issue