治理

ESLint 是一个开源项目，依赖于社区的贡献。任何人都可以随时通过提交代码、参与讨论、提出建议或任何其他他们认为合适的贡献来为项目做出贡献。本文档描述了各种类型的贡献者如何在 ESLint 项目中工作。

角色和职责

用户

用户是社区成员，他们对项目有需求。任何人都可以成为用户；没有特殊要求。常见的用户贡献包括宣传项目（例如，在网站上显示链接并通过口口相传提高知名度）、从新用户的角度告知开发者项目的优点和缺点，或提供精神支持（一句“谢谢”意义重大）。

持续参与项目及其社区的用户通常会变得越来越投入。这些用户可能会发现自己成为贡献者，如下一节所述。

贡献者

贡献者是社区成员，他们以具体的方式为项目做出贡献，最常见的是代码和/或文档的形式。任何人都可以成为贡献者，贡献可以有多种形式。对项目没有承诺的期望，没有特定的技能要求，也没有选择过程。

贡献者对源代码具有只读访问权限，因此通过 pull request 提交更改。贡献者的 pull request 会由 TSC 成员审查并合并。TSC 成员和提交者与贡献者一起审查他们的代码并准备合并。

随着贡献者获得项目经验和熟悉度，他们在社区中的形象和对社区的承诺将会增加。在某个阶段，他们可能会发现自己被现有的网站团队成员或提交者提名为网站团队成员或提交者。

网站团队成员

网站团队成员是社区成员，他们通过持续参与社区表明他们致力于持续维护 eslint.org。网站团队成员被授予 eslint.org GitHub 仓库的推送权限，并且必须遵守项目的贡献指南。

网站团队成员

预计每周至少工作一小时，用于分类问题和审查 pull request。
预计每周在 ESLint 上总共至少工作两小时。
可以按每小时 50 美元的费率，为他们在 ESLint 上工作的时间开具发票。
预计每个工作日（不包括节假日和其他休假时间）在 #team Discord 频道签到一次，以获取团队更新。
预计在源代码仓库的公共分支上工作，并将来自该分支的 pull request 提交到 master 分支。
预计在不再需要公共分支时删除它们。
所有更改都必须提交 pull request。
他们的工作在被接受到仓库之前，需要由审查者和 TSC 成员审查。
可以标记和关闭与网站相关的问题（请参阅管理问题）。
可以合并一些 pull request（请参阅审查 Pull Request）。
可以随时休假，并且预计当他们离开超过几天时，会在 #team Discord 频道发布消息。

要成为网站团队成员

必须表现出作为团队成员参与维护 eslint.org 的意愿和能力。通常，潜在的网站团队成员需要表明他们了解网站的结构以及它如何融入更大的 ESLint 项目的目标和战略。
网站团队成员应尊重每一位社区成员，并以包容的精神进行协作。
已提交至少 10 个与网站相关的 pull request。什么是与网站相关的 pull request？是指向 eslint.org 仓库或 eslint 仓库中的 docs 目录的 pull request，并且由于其文档完善且经过测试，因此易于接受。

新的网站团队成员可以由任何现有的网站团队成员或提交者提名。一旦被提名，将由 TSC 成员进行投票。

重要的是要认识到，网站团队成员资格是一种特权，而不是权利。这种特权必须通过努力获得，一旦获得，TSC 成员可以通过标准的 TSC 动议将其撤销。但是，在正常情况下，网站团队成员只要愿意继续参与项目，就可以一直保持成员资格。

提交者

提交者是社区成员，他们通过持续参与社区表明他们致力于项目的持续开发。提交者被授予项目 GitHub 仓库的推送权限，并且必须遵守项目的贡献指南。

提交者

预计每周至少工作一小时，用于分类问题和审查 pull request。
预计每周在 ESLint 上总共至少工作两小时。
可以按每小时 50 美元的费率，为他们在 ESLint 上工作的时间开具发票。
预计每个工作日（不包括节假日和其他休假时间）在 #team Discord 频道签到一次，以获取团队更新。
预计在源代码仓库的公共分支上工作，并将来自该分支的 pull request 提交到 master 分支。
预计在不再需要公共分支时删除它们。
预计对 Triage Board 的“需要反馈”列中的问题提供反馈。
预计每个月至少处理一个他们没有创建的、在 Triage Board 的“准备实施”列中的问题。
所有更改都必须提交 pull request。
他们的工作在被接受到仓库之前，需要由 TSC 成员审查。
可以标记和关闭问题（请参阅管理问题）。
可以合并一些 pull request（请参阅审查 Pull Request）。
可以随时休假，并且预计当他们离开超过几天时，会在 #team Discord 频道发布消息。

要成为提交者

必须表现出作为团队成员参与项目的意愿和能力。通常，潜在的提交者需要表明他们理解并认同项目、项目的目标和战略。
提交者应尊重每一位社区成员，并以包容的精神进行协作。
已提交至少 10 个合格的 pull request。什么是合格的 pull request？是指具有重要技术价值，并且由于其文档完善且经过测试，因此易于接受的 pull request。

新的提交者可以由任何现有的提交者提名。一旦被提名，将由 TSC 成员进行投票。

重要的是要认识到，提交者资格是一种特权，而不是权利。这种特权必须通过努力获得，一旦获得，TSC 成员可以通过标准的 TSC 动议将其撤销。但是，在正常情况下，提交者资格只要提交者愿意继续参与项目，就可以一直存在。

表现出高于平均水平的项目贡献的提交者，尤其是在项目的战略方向和长期健康方面，可能会被提名为审查者，如下所述。

审查者

审查者是社区成员，他们通过分类问题、修复错误、实施改进/功能为项目贡献了大量时间，并且是值得信赖的社区领导者。

审查者可以执行提交者的所有职责，并且还可以

在审查和批准更改后，可以合并已接受问题的外部 pull request。
在收集到他们认为必要的反馈后，可以合并他们自己的 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 Issue 要求将某项内容添加到下次会议的议程中。任何人都可以通过向 issue 添加“tsc agenda”标签将项目添加到议程中。

在每次 TSC 会议之前，主持人将与 TSC 成员共享议程。TSC 成员可以在每次会议开始时向议程添加他们喜欢的任何项目。主持人和 TSC 不能否决或删除项目。

在没有达到法定人数的 TSC 成员出席会议的情况下，不得对 TSC 议程项目进行具有约束力的投票。当超过一半的 TSC 成员（减去未出席的成员）出席时，即达到法定人数。

TSC 可以邀请来自某些项目的人员或代表以无投票权身份参与。

主持人负责总结每个议程项目的讨论，并在会后将其作为 pull request 发送。

共识寻求过程

TSC 遵循共识寻求决策模型。

当议程项目似乎已达成共识时，主持人将询问“是否有人反对？”，作为对共识的最后异议征询。

如果议程项目无法达成共识，TSC 成员可以呼吁进行结束投票或投票将问题搁置到下次会议。投票呼吁必须得到 TSC 大多数成员的批准，否则讨论将继续。简单多数获胜。

这项工作衍生自 YUI 贡献者模型和 Node.js 项目治理模型。

这项工作根据 Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License 获得许可。

编辑此页