审查 Pull Request

Pull Request 提交频繁，是我们与社区互动的最佳机会。因此，重要的是 Pull Request 在合并前得到充分审查，并且 Pull Request 上的互动是积极的。

谁可以审查 Pull Request？

任何人，包括团队成员和公众，都可以在 Pull Request 上留下评论。

审查 Pull Request

当 Pull Request 被打开时，机器人将检查以下内容

1. 提交者是否已签署 CLA？
2. 提交消息摘要的格式是否正确？
3. 提交摘要是否太长？

机器人将添加评论，说明它发现的问题。在这些问题得到解决之前，您无需进一步查看 Pull Request（无需在 Pull Request 上评论要求提交者执行机器人要求的事情 - 这就是我们设置机器人的原因！）。

一旦机器人检查通过，您需要检查以下内容

1. 再次检查 Pull Request 标题是否基于 issue 正确（或者，如果没有引用 issue，则基于声明的问题）。
2. 如果 Pull Request 对核心代码进行了更改，请确保存在 issue，并且 Pull Request 在提交消息中引用了该 issue。
3. 代码是否遵循我们的约定（包括头部注释、JSDoc 注释等）？如果否，请留下反馈并参考 代码约定 文档。
4. 对于代码更改
   • 是否有测试验证更改？ 如果没有，请要求他们添加。
   • 更改是否需要文档？ 如果是，请要求提交者添加必要的文档。
5. 是否存在任何自动化测试错误？ 如果是，请要求提交者检查它们。
6. 如果您已审查了 Pull Request 且没有未解决的问题，请留下评论 “LGTM” 以表示您的批准。如果您希望其他人验证更改，请评论 “LGTM 但希望其他人验证。”

注意： 如果您是团队成员并且您在 Pull Request 上留下了评论，请跟进以验证您的评论是否已得到解决。

Pull Request 所需的批准

任何提交者、审查者或 TSC 成员都可以批准 Pull Request，但合并所需的批准取决于 Pull Request 的类型。

合并非破坏性更改需要一位提交者的批准，该更改是

1. 文档更改
2. 错误修复（针对规则或核心代码）
3. 依赖项升级
4. 与构建相关
5. 杂项

对于非破坏性功能，Pull Request 需要一位审查者或 TSC 成员的批准，以及来自任何其他团队成员的额外批准。

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

在 Triage Board 中移动 Pull Request

当 Pull Request 被创建时，无论是团队成员还是外部贡献者创建的，它都会自动放置在 Triage board 的 “Needs Triage” 列中。Pull Request 应保留在该列中，直到团队成员开始审查它。

如果 Pull Request 没有相关的 issue，则应通过正常的 issue 分流流程 将其标记为已接受。一旦接受，将 Pull Request 移动到 “Implementing” 列。

如果 Pull Request 有相关的 issue，则

• 如果 issue 已被接受，将 Pull Request 移动到 “Implementing” 列。
• 如果 issue 未被接受，将 Pull Request 移动到 “Evaluating” 列，直到 issue 被标记为已接受，届时将 Pull Request 移动到 “Implementing”。

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

1. Pull Request 具有所需的批准，并且等待期（见下文）已过，因此可以合并。
2. Pull Request 具有所需的批准，但等待期尚未过去，因此应将其移动到 “Merge Candidates” 列。
3. Pull Request 需要另一个批准才能合并，因此应将其移动到 “Second Review Needed” 列。

当 Pull Request 获得第二个批准时，应将其合并（如果 100% 准备就绪）或移动到 “Merge Candidates” 列，如果存在任何应在下次发布前审查的未解决问题。

谁可以合并 Pull Request

TSC 成员、审查者、提交者和网站团队成员可以在收到所需的批准后合并 Pull Request，具体取决于 Pull Request 的内容。

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

1. 文档更改
2. 依赖项升级
3. 杂项

何时合并 Pull Request

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

1. 所有评论都已得到解决。
2. 做出评论的任何团队成员都已验证他们的问题已得到解决。
3. 所有自动化测试都通过（永远不要合并测试失败的 Pull Request）。

合并前，请务必对提交者表示感谢，特别是如果他们为 Pull Request 付出了很多努力。

团队成员可以立即合并 Pull Request，如果它

1. 进行小的文档更改。
2. 是杂项。
3. 修复存储库上其他工作的阻塞（与构建相关、与测试相关、与依赖项相关等）。
4. 是需要进入补丁发布的重要修复。

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

• 如果 Pull Request 是在周一至周五打开的，则等待 2 天。
• 如果 Pull Request 是在周六或周日打开的，则等待 3 天。

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

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

何时关闭 Pull Request

在以下几种情况下，关闭 Pull Request 而不合并是合适的

1. Pull Request 解决了已修复的 issue。
2. Pull Request 已 17 天未更新。
3. Pull Request 提交者不愿意遵循项目指南。

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

关闭评论示例

如果 Pull Request 已 17 天未更新

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

如果 Pull Request 提交者不愿意遵循项目指南。

很遗憾，我们无法接受不符合我们指南的 Pull Request。我现在将关闭此 Pull Request，但如果您想按照我们的指南重新提交，我们将很乐意审查。