治理
ESLint 是一个开源项目，依赖于社区的贡献。任何人都可以通过提交代码、参与讨论、提出建议或任何他们认为合适的其他贡献，在任何时候为该项目做出贡献。本文档描述了各种类型的贡献者如何在 ESLint 项目中工作。
角色和职责
用户
用户是社区成员，他们需要该项目。任何人都可以成为用户；没有特殊要求。常见的用户贡献包括推广项目（例如，在网站上显示链接并通过口头传播提高知名度）、告知开发者从新用户角度看出的优缺点，或提供精神支持（一句“谢谢”非常有用）。
继续参与项目及其社区的用户，往往会越来越积极参与。这些用户可能会发现自己成为贡献者，如下一节所述。
贡献者
贡献者是社区成员，他们以具体的方式为项目做出贡献，最常见的方式是代码和/或文档。任何人都可以成为贡献者，贡献可以采取多种形式。项目没有承诺要求，没有特定的技能要求，也没有筛选过程。
贡献者对源代码具有只读访问权限，因此通过拉取请求提交更改。贡献者的拉取请求由 TSC 成员审核并合并。TSC 成员和贡献者与贡献者合作，审核他们的代码并准备合并。
随着贡献者积累经验，熟悉项目，他们在社区中的角色和承诺将增加。在某个阶段，他们可能会发现自己被现有的网站团队成员或贡献者提名为网站团队成员或贡献者。
网站团队成员
网站团队成员是社区成员，他们已证明他们通过持续参与社区，致力于 eslint.org 的持续维护。网站团队成员被授予对 eslint.org GitHub 存储库的推送权限，并且必须遵守项目的 贡献指南。
网站团队成员
- 预计每周至少花一个小时处理问题和审核拉取请求。
- 预计每周总共在 ESLint 上花至少两个小时。
- 可以为他们在 ESLint 上花费的时间开具发票，每小时 50 美元。
- 预计每周工作日（节假日和其他休假时间除外）在
#teamDiscord 频道上签入一次，以获取团队更新。 - 预计在源代码库的公共分支上工作，并从该分支提交拉取请求到主分支。
- 预计在公共分支不再需要时删除它们。
- 必须为所有更改提交拉取请求。
- 他们的工作在被接受到存储库之前，由审阅者和 TSC 成员审核。
- 可以标记和关闭与网站相关的 issue（参见 管理 issue）
- 可以合并一些拉取请求（参见 审核拉取请求）
- 可以随时休假，并且预计在他们要离开超过两天时，在
#teamDiscord 频道中发布。
要成为网站团队成员
- 必须表现出愿意并且能够作为团队成员参与 eslint.org 的维护。通常，潜在的网站团队成员需要表现出他们了解网站的结构以及它如何适应 ESLint 项目更大目标和战略。
- 网站团队成员应尊重每位社区成员，并以包容精神协作工作。
- 已提交至少 10 个与网站相关的拉取请求。什么是与网站相关的拉取请求？一个对
eslint.org存储库或eslint存储库中的docs目录做出的拉取请求，并且由于文档良好且经过测试，因此需要很少的努力即可接受。
新的网站团队成员可以由任何现有的网站团队成员或贡献者提名。一旦他们被提名，TSC 成员将进行投票。
重要的是要认识到，网站团队成员身份是一种特权，而不是权利。这种特权必须获得，并且一旦获得，就可以通过标准的 TSC 动议被 TSC 成员撤销。但是，在正常情况下，网站团队成员只要他们愿意继续参与项目，就会一直保留成员身份。
贡献者
贡献者是社区成员，他们已证明他们通过持续参与社区，致力于项目的持续开发。贡献者被授予对项目 GitHub 存储库的推送权限，并且必须遵守项目的 贡献指南。
贡献者
- 预计每周至少花一个小时处理问题和审核拉取请求。
- 预计每周总共在 ESLint 上花至少两个小时。
- 可以为他们在 ESLint 上花费的时间开具发票，每小时 50 美元。
- 预计每周工作日（节假日和其他休假时间除外）在
#teamDiscord 频道上签入一次，以获取团队更新。 - 预计在源代码库的公共分支上工作，并从该分支提交拉取请求到主分支。
- 预计在公共分支不再需要时删除它们。
- 预计在 分类板 的“需要反馈”列中提供有关 issue 的反馈。
- 预计每月在 分类板 的“准备实施”列中处理至少一个他们没有创建的 issue。
- 必须为所有更改提交拉取请求。
- 他们的工作在被接受到存储库之前，由 TSC 成员审核。
- 可以标记和关闭 issue（参见 管理 issue）
- 可以合并一些拉取请求（参见 审核拉取请求）
- 可以随时休假，并且预计在他们要离开超过两天时，在
#teamDiscord 频道中发布。
要成为贡献者
- 必须表现出愿意并且能够作为团队成员参与项目。通常，潜在的贡献者需要表现出他们了解并认同项目、其目标和战略。
- 贡献者应尊重每位社区成员，并以包容精神协作工作。
- 已提交至少 10 个符合条件的拉取请求。什么是符合条件的拉取请求？一个具有重大技术意义的拉取请求，并且由于文档良好且经过测试，因此需要很少的努力即可接受。
新的贡献者可以由任何现有的贡献者提名。一旦他们被提名，TSC 成员将进行投票。
重要的是要认识到，贡献者身份是一种特权，而不是权利。这种特权必须获得，并且一旦获得，就可以通过标准的 TSC 动议被 TSC 成员撤销。但是，在正常情况下，贡献者身份只要贡献者愿意继续参与项目，就会一直保留。
对项目做出高于平均水平贡献的贡献者，特别是对项目的战略方向和长期健康状况做出贡献的贡献者，可以被提名成为审阅者，如下所述。
审阅者
审阅者是社区成员，他们通过处理 issue、修复错误、实施增强/功能，为项目贡献了大量时间，并且是值得信赖的社区领导者。
审阅者可以执行所有贡献者的职责，还可以
- 在审核并批准更改后，可以合并已接受 issue 的外部拉取请求。
- 在收集到他们认为必要的反馈后，可以合并他们自己的拉取请求。（任何拉取请求在合并之前，都应该至少有一位贡献者/审阅者/TSC 成员的评论，表明他们查看了代码。）
- 可以为他们在 ESLint 上花费的时间开具发票，每小时 80 美元。
要成为审阅者
- 以积极和协作的方式与社区合作。
- 已对其他人的提交提供良好的反馈，并表现出对项目代码质量标准的整体理解。
- 承诺长期成为社区的一部分。
- 提交了至少 50 个符合条件的 Pull Request。
现有审阅者和 TSC 成员可以邀请 Committer 成为审阅者。提名将经过讨论，然后由 TSC 决定。
技术指导委员会 (TSC)
ESLint 项目由技术指导委员会 (TSC) 共同管理，该委员会负责项目的总体指导。
TSC 对该项目拥有最终决定权，包括
- 技术方向
- 项目管理和流程（包括本政策）
- 贡献政策
- GitHub 代码库托管
TSC 席位没有时间限制。TSC 的规模不能超过 5 名成员。这种规模确保了对重要专业领域的充分覆盖，同时又能有效地做出决策。
TSC 可以通过标准的 TSC 动议添加额外的成员。
TSC 成员可以通过自愿辞职、标准的 TSC 动议或连续缺席四次 TSC 会议从 TSC 中移除。在所有情况下，TSC 成员将恢复审阅者身份，除非他们更愿意成为校友。
TSC 成员变更应发布在议程中，并可以像其他议程项目一样提出（见下文“TSC 会议”）。
TSC 成员中来自同一雇主的比例不得超过 1/3。如果 TSC 成员的移除或辞职，或 TSC 成员的雇佣变更导致来自同一雇主的 TSC 成员比例超过 1/3，则必须立即通过来自过度代表雇主的 1 名或多名 TSC 成员的辞职或移除来解决这种情况。
TSC 成员除了审阅者的职责之外，还承担其他职责。这些职责确保项目的顺利运行。TSC 成员应审查代码贡献，批准对本文件的更改，管理项目输出中的版权，并参加定期的 TSC 会议。
TSC 成员可以执行审阅者的所有职责，还可以
- 发布所有 ESLint 项目的新版本。
- 参加 TSC 会议。
- 提出预算项目。
- 提出新的 ESLint 项目。
除了对审阅者的期望之外，TSC 成员没有特定的要求或资格。
现有 TSC 成员可以邀请审阅者成为 TSC 成员。提名将经过讨论，然后由 TSC 决定。
TSC 会议
TSC 每两周在 TSC 会议 Discord 频道举行一次会议。会议由 TSC 批准的指定主持人主持。
将有争议的项目或对治理、贡献政策、TSC 成员或发布流程的修改添加到 TSC 议程中。
议程的意图不是批准或审查所有补丁。这些应该在 GitHub 上持续进行，并由更大的 Committer 集团处理。
任何社区成员、Committer 或审阅者都可以通过记录 GitHub Issue 来要求将某事添加到下一次会议的议程中。任何人都可以通过在 Issue 中添加“tsc agenda”标签将该项目添加到议程中。
在每次 TSC 会议之前，主持人将与 TSC 成员分享议程。TSC 成员可以在每次会议开始时将他们喜欢的任何项目添加到议程中。主持人和 TSC 不能否决或删除项目。
在会议中没有足够数量的 TSC 成员在场的情况下，TSC 议程项目不能进行具有约束力的投票。当超过一半的 TSC 成员（减去缺席成员）在场时，即达到法定人数。
TSC 可以邀请特定项目的人员或代表以非投票身份参加。
主持人负责总结每个议程项目的讨论，并在会议结束后将其作为 Pull Request 发送。
共识寻求流程
TSC 遵循 协商一致决策 模式。
当议程项目似乎已达成共识时，主持人将询问“有人反对吗？”作为对共识的最终异议呼吁。
如果议程项目无法达成共识，TSC 成员可以呼吁进行结束投票或将问题提交给下次会议的投票。投票呼吁必须得到大多数 TSC 的批准，否则讨论将继续进行。简单多数获胜。
这项工作是 YUI 贡献者模型 和 Node.js 项目治理模型 的衍生作品。
这项工作根据 知识共享署名-相同方式共享 2.0 英国：英格兰和威尔士许可 授权。