审查 Pull Request

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

谁可以审查 Pull Request？

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

当打开 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 Request 需要一位审查者或 TSC 成员的批准，以及另一位团队成员的额外批准。

对于破坏性更改，Pull Request 需要两位 TSC 成员的批准。

当 Pull Request 由团队成员或外部贡献者创建时，它会自动放置在 Triage 板的“需要分类”列中。在团队成员开始审查之前，Pull Request 应保留在该列中。

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

如果 Pull Request 确实有相关问题，则

一旦 Pull Request 获得一个批准，就会发生以下三种情况之一

当 Pull Request 获得第二个批准时，它应该要么合并（如果 100% 准备就绪），要么如果在下一个版本之前应该审查任何未解决的问题，则将其移至“合并候选”列。

TSC 成员、审查者、提交者和网站团队成员可以合并 Pull Request，具体取决于 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 Request。我现在将关闭此 Pull Request，但如果您想按照我们的指南重新提交，我们将很乐意审查。

编辑此页面