从项目开始之初，ESLint 就一直要求每个包含代码的 pull request 都必须有对应的 issue。 这有很多原因，主要与我们如何分类和处理收到的请求，以及 GitHub issue 跟踪器对我们的限制有关。 自那时以来，GitHub issue 和 pull request 跟踪器已经有了很多改进，因此，我们能够做出一些更改。
大多数 Pull Request 不再需要 Issue
我们取消了所有 pull request 都需要 issue 的限制。 对于几乎所有类型的更改，您现在可以直接提交 pull request 而无需 issue。 我们添加了一个 pull request 模板，只要您填写了该模板中要求的信息，就可以随意提交 pull request，而无需先打开 issue。
但是，仍有两类更改需要 issue
- 任何破坏性更改。
- 任何对核心的更改。
破坏性和核心更改具有影响最终用户的巨大潜力，因此我们仍然希望在人们花费时间编写代码之前了解这种影响。
Issue 的生命周期结束期限
我们从贡献者那里听到的事情之一是，当一个 issue 卡住而没有得到解决时，会令人沮丧。 从一开始，我们就尝试尽可能快地对 issue 和 pull request 给出反馈。 然而，随着 ESLint 的发展，issue 和 pull request 的数量也变得非常庞大，这使得团队难以处理。
开源社区中的不同团队以不同的方式处理这个问题。 有些团队选择永不关闭 issue，只是让所有 issue 无限期地保持开放状态，以防有人想要修复它们。 有些团队使用机器人自动关闭超过一定时间的 issue。 ESLint 团队对这些选择不太满意，因此我们找到了一种更人工化的流程，它是两者的混合体。
我们的首要目标是快速给出反馈，并且由于大多数 issue 都是请求 ESLint 团队进行更改，因此我们想让您知道我们是否会进行该更改。 最好的方法是用适当的评论关闭 issue。 我们制定的规则是
- 未被接受的 issue 可能会在 21 天后关闭。（只有被接受的 issue 才会出现在路线图上。）
- 如果 90 天后仍无人同意实施，则已接受的 issue 可能会被关闭。
虽然我们希望能够承诺实施每个关于 ESLint 的好主意，但现实情况是，许多请求最终不会出现在正式的路线图上。 ESLint 团队是一个由志愿者组成的团队，他们在业余时间工作，因此，可用于工作的时间很少。 我们认为，关闭 issue 并明确表示不会进行所请求的更改，比让 issue 永远开放以防有人决定贡献更改更诚实。 根据我们的经验，开放 90 天或更长时间的 issue 很少得到解决，只会让每个人对其状态感到困惑。
注意： 如果您对某个更改充满热情，请考虑提交 pull request 而不是 issue。 很多时候，我们只是没有额外的带宽来处理重要的请求，但我们可以指导其他人完成更改。 提交 pull request 会增加您的更改被采纳的机会（尽管它不能保证）。
持续学习
与往常一样，我们将继续根据 ESLint 团队和整个社区的反馈评估我们的 issue 和 pull request 策略。 我们希望这些新更改将通过简化接受贡献的流程，帮助 ESLint 社区继续发展壮大。
