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