治理
ESLint 是一個開源專案，依賴社群的貢獻。任何人都可以隨時透過提交程式碼、參與討論、提出建議或任何他們認為合適的其他貢獻來貢獻專案。本文件說明各種貢獻者如何在 ESLint 專案中工作。
角色與職責
使用者
使用者是社群成員，他們對專案有需求。任何人都可以成為使用者；沒有特殊要求。常見的使用者貢獻包括宣傳專案（例如，在網站上顯示連結並透過口耳相傳提高知名度）、從新使用者的角度告知開發人員優缺點，或提供精神上的支持（一句「謝謝」作用很大）。
繼續參與專案及其社群的使用者通常會越來越投入。此類使用者可能會發現自己成為貢獻者，如下一節所述。
貢獻者
貢獻者是社群成員，他們以具體方式為專案做出貢獻，最常見的形式是程式碼和/或文件。任何人都可以成為貢獻者，貢獻的形式有很多種。沒有對專案的承諾期望、沒有特定的技能要求，也沒有選擇過程。
貢獻者擁有原始程式碼的唯讀權限，因此透過 Pull Request 提交變更。貢獻者的 Pull Request 會由 TSC 成員審查並合併。TSC 成員和提交者會與貢獻者合作審查他們的程式碼並為合併做準備。
隨著貢獻者對專案的經驗和熟悉度增加，他們在社群中的形象以及對社群的承諾也會增加。在某個階段，他們可能會發現自己被現有的網站團隊成員或提交者提名為網站團隊成員或提交者。
網站團隊成員
網站團隊成員是社群成員，他們透過持續參與社群，展現他們致力於持續維護 eslint.org。網站團隊成員擁有 eslint.org GitHub 儲存庫的推送權限，並且必須遵守專案的貢獻指南。
網站團隊成員
- 預計每週至少花費一小時分類問題並審查 Pull Request。
- 預計每週總共至少花費兩小時在 ESLint 上。
- 可以針對他們花費在 ESLint 上的時間，以每小時 50 美元的費率開發票。
- 預計每個工作日（不包括假期和其他休假時間）查看
#teamDiscord 頻道，以獲取團隊更新。 - 預計在原始程式碼儲存庫的公開分支上工作，並從該分支提交 Pull Request 到 master 分支。
- 預計在不再需要時刪除其公開分支。
- 必須針對所有變更提交 Pull Request。
- 他們的工作在被接受到儲存庫之前，由審閱者和 TSC 成員審查。
- 可以標記和關閉與網站相關的問題（請參閱管理問題）
- 可以合併一些 Pull Request（請參閱審查 Pull Request）
- 可以隨時休假，並預計在請假超過幾天時，在
#teamDiscord 頻道中發文。
成為網站團隊成員的條件
- 必須展現出願意和有能力以團隊成員的身份參與 eslint.org 的維護。通常，潛在的網站團隊成員需要證明他們了解網站的結構，以及它如何融入更大的 ESLint 專案的目標和策略。
- 網站團隊成員應尊重每一位社群成員，並本著包容的精神進行協作。
- 已提交至少 10 個與網站相關的 Pull Request。什麼是與網站相關的 Pull Request？對
eslint.org儲存庫或eslint儲存庫中的docs目錄所做的，並且因為文件完善和經過測試，因此幾乎不需要花費力氣接受的 Pull Request。
新的網站團隊成員可以由任何現有的網站團隊成員或提交者提名。一旦被提名，將由 TSC 成員進行投票。
務必認知到，網站團隊的成員資格是一種特權，而不是權利。這種特權必須經過努力才能獲得，一旦獲得，TSC 成員可以透過標準的 TSC 動議將其撤銷。然而，在正常情況下，網站團隊成員會持續任職，只要他們希望繼續參與專案即可。
提交者
提交者是社群成員，他們透過持續參與社群，展現他們致力於持續開發專案。提交者擁有專案 GitHub 儲存庫的推送權限，並且必須遵守專案的貢獻指南。
提交者
- 預計每週至少花費一小時分類問題並審查 Pull Request。
- 預計每週總共至少花費兩小時在 ESLint 上。
- 可以針對他們花費在 ESLint 上的時間，以每小時 50 美元的費率開發票。
- 預計每個工作日（不包括假期和其他休假時間）查看
#teamDiscord 頻道，以獲取團隊更新。 - 預計在原始程式碼儲存庫的公開分支上工作，並從該分支提交 Pull Request 到 master 分支。
- 預計在不再需要時刪除其公開分支。
- 預計針對 分類看板 中「需要回饋」欄中的問題提供回饋。
- 預計每月處理至少一個他們沒有建立的 分類看板 中「準備實作」欄中的問題。
- 必須針對所有變更提交 Pull Request。
- 他們的工作在被接受到儲存庫之前，由 TSC 成員審查。
- 可以標記和關閉問題（請參閱管理問題）
- 可以合併一些 Pull Request（請參閱審查 Pull Request）
- 可以隨時休假，並預計在請假超過幾天時，在
#teamDiscord 頻道中發文。
成為提交者的條件
- 必須展現出願意和有能力以團隊成員的身份參與專案。通常，潛在的提交者需要證明他們了解並與專案、其目標和策略保持一致。
- 提交者應尊重每一位社群成員，並本著包容的精神進行協作。
- 已提交至少 10 個合格的 Pull Request。什麼是合格的 Pull Request？具有重要技術份量，並且因為文件完善和經過測試，因此幾乎不需要花費力氣接受的 Pull Request。
新的提交者可以由任何現有的提交者提名。一旦被提名，將由 TSC 成員進行投票。
務必認知到，提交者資格是一種特權，而不是權利。這種特權必須經過努力才能獲得，一旦獲得，TSC 成員可以透過標準的 TSC 動議將其撤銷。然而，在正常情況下，提交者資格會持續存在，只要提交者希望繼續參與專案即可。
如果提交者展現出對專案的貢獻高於平均水平，尤其是在專案的策略方向和長期健康方面，則可能會被提名為審閱者，如下所述。
審閱者
審閱者是社群成員，他們透過分類問題、修復錯誤、實作增強功能/功能，為專案貢獻了大量時間，並且是值得信賴的社群領導者。
審閱者可以執行提交者的所有職責，並且還可以
- 可以在審閱和批准變更後合併外部 Pull Request 以處理已接受的問題。
- 可以在收集他們認為必要的回饋後合併自己的 Pull Request。（任何 Pull Request 在沒有至少一位提交者/審閱者/TSC 成員評論表示他們已查看程式碼的情況下，都不應合併。）
- 可以針對他們花費在 ESLint 上的時間，以每小時 80 美元的費率開發票。
成為審閱者的條件
- 以樂於助人和協作的方式與社群合作。
- 針對其他人的提交提供良好的回饋，並展現出對專案程式碼品質標準的整體理解。
- 承諾長期成為社群的一份子。
- 已提交至少 50 個合格的 Pull Request。
提交者會由現有的審閱者和 TSC 成員邀請成為審閱者。提名將導致討論，然後由 TSC 做出決定。
技術指導委員會 (TSC)
ESLint 專案由技術指導委員會 (TSC) 共同治理，該委員會負責專案的高層指導。
TSC 對此專案擁有最終決定權，包括
- 技術方向
- 專案治理和流程（包括本政策）
- 貢獻政策
- GitHub 儲存庫託管
TSC 席位沒有時間限制。TSC 的人數不得超過五名成員。這個人數確保了重要的專業知識領域得到充分的覆蓋，同時又能有效率地做出決策。
TSC 可以透過標準的 TSC 動議向 TSC 新增成員。
TSC 成員可以透過自願辭職、透過標準的 TSC 動議，或錯過連續四次 TSC 會議而從 TSC 中除名。在所有情況下，TSC 成員將恢復為審閱者身份，除非他們偏好校友身份。
對 TSC 成員資格的變更應在議程中發布，並且可以像其他任何議程項目一樣提出（請參閱下方的「TSC 會議」）。
TSC 成員中不得超過 1/3 的成員隸屬於同一雇主。如果因 TSC 成員的除名或辭職，或 TSC 成員的就業變動，導致超過 1/3 的 TSC 成員隸屬於同一雇主，則必須立即透過辭退或除名一名或多名隸屬於過度代表的雇主的 TSC 成員來糾正這種情況。
TSC 成員除了審閱者的職責外，還肩負額外的責任。這些責任確保專案順利運作。TSC 成員應審閱程式碼貢獻、批准對本文檔的變更、管理專案輸出的版權，並參加定期 TSC 會議。
TSC 成員可以執行審閱者的所有職責，並且還可以：
- 發佈所有 ESLint 專案的新版本。
- 參與 TSC 會議。
- 提出預算項目。
- 提出新的 ESLint 專案。
除了對審閱者的期望之外，對於 TSC 成員沒有特定的要求或資格。
審閱者由現有的 TSC 成員邀請成為 TSC 成員。提名將導致討論，然後由 TSC 做出決定。
TSC 會議
TSC 每隔一周在 TSC 會議 Discord 頻道舉行會議。會議由 TSC 批准的指定主持人主持。
被認為有爭議或屬於治理、貢獻政策、TSC 成員資格或發佈流程修改的項目，將被加入 TSC 議程。
議程的用意不是批准或審閱所有修補程式。這些應在 GitHub 上持續進行，並由更大的提交者群體處理。
任何社群成員、提交者或審閱者都可以透過記錄 GitHub Issue 來要求將某個項目加入下次會議的議程。任何人都可以透過在 issue 上加入「tsc agenda」標籤，將項目加入議程。
在每次 TSC 會議之前，主持人將與 TSC 成員分享議程。TSC 成員可以在每次會議開始時將任何他們喜歡的項目加入議程。主持人和 TSC 不能否決或刪除項目。
如果沒有達到法定人數的 TSC 成員出席會議，則無法對 TSC 議程項目進行具約束力的投票。當超過一半的 TSC 成員（減去未出席的成員）出席時，即達到法定人數。
TSC 可以邀請某些專案的人員或代表以無投票權的身份參與。
主持人負責總結每個議程項目的討論內容，並在會議後以 pull request 的形式發送。
尋求共識的流程
TSC 遵循尋求共識的決策模式。
當議程項目似乎達成共識時，主持人會問「有沒有人反對？」作為對共識的最後一次異議徵詢。
如果議程項目無法達成共識，TSC 成員可以要求進行表決結束或投票將問題擱置到下次會議。要求表決必須獲得大多數 TSC 的批准，否則討論將繼續進行。簡單多數決勝出。
此工作衍生自 YUI 貢獻者模型和 Node.js 專案治理模型。
此工作依據 創用 CC 姓名標示-相同方式分享 2.0 英國：英格蘭和威爾斯授權條款授權。