审查 Pull Requests

Pull requests 频繁提交，是我们与社区互动最佳的机会。因此，在合并之前，必须对 pull requests 进行良好的审查，并且 pull requests 上的互动必须是积极的。

谁可以审查 Pull Requests？

任何人都可以对 pull requests 发表评论，包括团队成员和公众。

当打开 pull request 时，机器人将检查以下内容

机器人将添加一条评论，说明它发现的问题。在解决这些问题之前，您无需进一步查看 pull request（无需在 pull request 上发表评论来要求提交者执行机器人要求的操作 - 这就是我们使用机器人的原因！）。

一旦满足机器人的检查，您将检查以下内容

仔细检查 pull request 标题是否基于问题（或者，如果未引用问题，则基于陈述的问题）正确。
如果 pull request 对核心进行了更改，请确保存在问题并且 pull request 在提交消息中引用了该问题。
代码是否遵循我们的约定（包括标题注释、JSDoc 注释等）？如果不是，请留下反馈并参考代码约定文档。
对于代码更改
- 是否有测试验证更改？如果没有，请索取。
- 更改是否需要文档？如果是，请要求提交者添加必要的文档。
是否存在任何自动测试错误？如果是，请要求提交者检查。
如果您已审查 pull request 并且没有未解决的问题，请留下评论“LGTM”以表示您的批准。如果您想让其他人验证更改，请评论“LGTM 但希望其他人验证”。

注意：如果您是团队成员并且已在 pull request 上发表评论，请跟进以验证您的评论是否已得到解决。

任何提交者、审查者或 TSC 成员都可以批准 pull request，但合并所需的批准根据 pull request 的类型而有所不同。

合并非重大更改需要一个提交者批准，该更改为

对于非重大功能，pull requests 需要一位审查者或 TSC 成员的批准，以及任何其他团队成员的额外批准。

对于重大更改，pull requests 需要两名 TSC 成员的批准。

无论 pull request 是由团队成员还是外部贡献者创建，它都会自动放置在 Triage 板的“需要分类”列中。在团队成员开始审查之前，pull request 应保留在该列中。

如果 pull request 没有相关问题，则应通过问题的正常分类流程将其标记为已接受。接受后，将 pull request 移至“正在实施”列。

如果 pull request 有相关问题，则

一旦 pull request 获得一个批准，可能会发生三种情况之一

当 pull request 获得第二个批准时，应将其合并（如果 100% 准备就绪）或将其移至“合并候选”列，如果存在应在下次发布之前审查的任何未解决的问题。

TSC 成员、审查者、提交者和网站团队成员可以合并 pull requests，具体取决于 pull request 的内容，前提是它已获得所需的批准。

网站团队成员可以合并 eslint.org 存储库中的 pull request，如果它是

我们使用“合并”按钮将请求合并到存储库中。在合并 pull request 之前，请验证

在合并之前务必感谢提交者，尤其是在他们为 pull request 付出了大量工作的情况下。

团队成员可以立即合并 pull request，如果它

否则，团队成员应在合并 pull request 之前遵守等待期

等待期确保其他团队成员有机会在合并 pull request 之前对其进行审查。

注意：除非您收到所需的批准，否则您不应合并您的 pull request。

在某些情况下，适宜在不合并的情况下关闭 pull request

在任何这些情况下，请务必留下评论说明关闭 pull request 的原因。

如果 pull request 17 天内未更新

由于 17 天内没有活动而关闭。如果您仍然有兴趣提交此代码，请随时重新提交。

如果 pull request 提交者不愿意遵循项目指南。

不幸的是，我们无法接受不遵循我们指南的 pull requests。我将立即关闭此 pull request，但如果您想根据我们的指南重新提交，我们将很乐意审查。

编辑此页面