管理 Issue 和 Pull Request

新的 issue 和 pull request 被频繁提交，我们如何回应这些 issue 直接影响项目的成功。成为项目团队的一员意味着帮助分类和解决涌入的 issue，以便项目可以继续顺利运行。

需要记住的事情

1. 友善。 即使人们在 issue 上粗鲁或具有攻击性，作为项目团队成员，您也必须在对话中保持成熟。尽力与每个人合作，无论他们的风格如何。请记住，糟糕的措辞选择也可能是不太懂英语的人的标志，因此在尝试确定某人消息的语气时，请务必考虑到这一点。粗鲁，即使在别人对您粗鲁时，也会对团队和整个项目产生不良影响。
2. 保持好奇心。 当某些内容不清楚时，请在 issue 上提问。如果缺少详细信息，请不要假设您理解正在报告的内容。每当您不确定时，最好要求提供更多信息。
3. 并非所有请求都是平等的。 我们不太可能满足每个请求，因此不要害怕说某些内容不符合项目的范围或不切实际。如果情况确实如此，最好给出这样的反馈。
4. 在适当的时候关闭。 不要害怕关闭您认为不会完成的 issue，或者当从对话中清楚地表明没有进一步的工作要做时。如果 issue 被错误地关闭，可以随时重新打开，因此请在适当的时候随意关闭 issue。只需确保留下评论解释 issue 被关闭的原因（如果不是由提交关闭）。

Issue 和 Pull Request 的类型

有五个主要类别

1. Bug：某些东西没有按预期工作。
2. 增强：对已存在事物的更改。例如，向现有规则添加新选项，或修复规则中的 bug，修复后将导致规则报告更多问题（在这种情况下，同时使用“Bug”和“增强”）。
3. 功能：添加尚不存在的事物。例如，添加新规则、新格式化程序或新命令行标志。
4. 文档：添加、更新或删除项目文档。
5. 问题：关于某些事物如何工作的询问，不会导致代码更改。我们更希望人们使用 GitHub Discussions 或 Discord 提问，但有时他们会打开 issue。

评估 issue 或 pull request 的首要目标是确定 issue 属于哪个类别。

分类过程

ESLint 的所有 issue 和 pull request，跨所有 GitHub 存储库，都在我们的 Triage Project 上管理。在审查 issue 以确定要处理的内容时，请使用 Triage 项目而不是 issue 列表。Triage 项目有几个列

• 需要分类：尚未被任何人审查的 issue 和 pull request。
• 正在分类：已被某人审查但尚未完全分类的 issue 和 pull request。
• 准备好供开发团队处理：已分类且具有开发团队查看所需的所有信息的 issue 和 pull request。
• 评估中：开发团队正在评估这些 issue 和 pull request，以确定是否继续推进。
• 需要反馈：团队成员正在请求团队其他成员的更多意见，然后再继续。
• 等待 RFC：流程的下一步是编写 RFC。
• RFC 已打开：已打开 RFC 以解决这些 issue。
• 已阻止：由于某些依赖关系，issue 无法继续推进。
• 准备好实施：这些 issue 具有开始实施所需的所有详细信息。
• 正在实施：每个 issue 都有一个打开的 pull request，或者这是一个已批准的 pull request。
• 需要二次审查：已经获得一次批准的 pull request，批准者正在请求在合并前进行二次审查。
• 合并候选：已经获得至少一次批准的 pull request，并且至少有一位批准者认为 pull request 已准备好合并到下一个版本中，但仍然希望 TSC 成员进行验证。
• 已完成：issue 已关闭（通过 pull request 合并或团队手动关闭 issue）。

我们尽一切努力自动化尽可能多的列之间的移动，但有时移动 issue 需要手动完成。

当 Issue 或 Pull Request 被打开时

当 issue 或 pull request 被打开时，它会自动添加到 Triage 项目的“需要分类”列中。这些 issue 和 pull request 需要进行评估以确定后续步骤。支持团队或开发团队的任何成员都可以按照这些步骤正确分类 issue。

注意： 如果 issue 或 pull request 位于“正在分类”列中，则表示有人已经在对其进行分类，您应该让他们完成。除非有人寻求帮助，否则无需在“正在分类”列中的 issue 或 pull request 上发表评论。

分类 issue 或 pull request 的步骤是

1. 将 issue 或 pull request 从 Triage 项目中的“需要分类”移动到“正在分类”。
2. 检查：issue 模板中的所有信息是否已提供？
   • 否： 如果 issue 模板中缺少信息，或者您无法分辨正在请求什么，请要求作者提供缺失的信息
     • 将“需要信息”标签添加到 issue，以便我们知道此 issue 由于缺少信息而停滞不前。
     • 在提供必要信息之前，请勿继续执行其他步骤。
     • 如果 issue 作者在 7 天后仍未提供必要信息，请关闭 issue。机器人将添加评论，说明 issue 因缺少信息而被关闭。
   • 是
     • 如果 issue 实际上是一个问题（而不是开发团队需要更改的内容），请将其转换为讨论。您可以继续作为讨论进行对话。
     • 如果 issue 报告的是 bug，或者 pull request 修复的是 bug，请尝试按照 issue 中的说明重现该 issue。如果您可以重现该 bug，请添加“repro:yes”标签。（机器人将自动删除“repro:needed”标签。）如果您无法重现该 bug，请向作者询问有关其环境的更多信息或澄清重现步骤。
     • 如果 issue 或 pull request 报告的内容按预期工作，请添加“works as intended”标签并关闭 issue。
     • 请添加描述受影响的 ESLint 部分的标签
       • 第三方插件：与第三方功能（插件、解析器、规则等）相关。
       • 构建：与构建期间运行的命令（测试、linting、发布脚本等）相关。
       • cli：与命令行输入或输出，或 CLIEngine 相关。
       • 核心：与内部 API 相关。
       • 文档：与 eslint.org 上的内容相关。
       • 基础设施：与构建或部署所需的资源（VM、CI 工具、机器人等）相关。
       • 规则：与核心规则相关。
     • 请根据 issue 或 pull request 的重要性分配初始优先级。如果您不确定，请使用您的最佳判断。我们稍后可以随时更改优先级。
       • P1：紧急且重要，我们需要立即解决此问题。
       • P2：重要但不紧急。应由 TSC 成员或审查员处理。
       • P3：锦上添花但不重要。可以由任何团队成员处理。
       • P4：一个好主意，我们希望拥有，但团队可能需要一段时间才能实现。
       • P5：核心团队无法承诺的好主意。可能需要由外部贡献者完成。
     • 请分配初始影响评估（尽力猜测）
       • 低：不影响很多用户。
       • 中：影响大多数用户或对用户体验有明显影响。
       • 高：影响大量用户，是破坏性更改，或者对用户来说非常明显。
     • 如果您无法正确分类 issue 或 pull request，请将 issue 移回 Triage 项目中的“需要分类”列，以便其他人可以对其进行分类。
     • 如果 pull request 引用了已接受的 issue，请将其移动到 Triage 项目中的“正在实施”列。
     • 如果您已分类 issue，请将 issue 移动到 Triage 项目中的“准备好供开发团队处理”列。

评估过程

当 issue 移至“准备好供开发团队处理”列时，任何开发团队成员都可以选择 issue 开始评估。

1. 将 issue 移至“评估中”列。
2. 下一步
   • Bug：如果您可以验证 bug，请添加“accepted”标签，并询问他们是否愿意提交 pull request。
   • 新规则：如果您愿意支持该规则（意味着您认为它应该包含在 ESLint 核心中，并且您将负责将其包含在内的过程），请添加评论说您将支持该 issue，将 issue 分配给自己，并遵循下面的 指南。
   • 规则更改：如果您愿意支持更改，并且更改不会是破坏性的（需要主要版本递增），请添加评论说您将支持该 issue，将 issue 分配给自己，并遵循下面的 指南。
   • 破坏性更改：如果您怀疑或可以验证更改将是破坏性的，请将其标记为“Breaking”。
   • 重复项：如果您可以验证 issue 是重复项，请添加评论提及重复 issue（例如，“Duplicate of #1234”）并关闭 issue。
3. 无论上述情况如何，始终留下评论。不要只添加标签；通过提出问题（如果需要，请求更多信息）或陈述您对 issue 的看法来与打开 issue 的人互动。如果是已验证的 bug，请询问用户是否愿意提交 pull request。
4. 如果 issue 无法实施，因为它需要更新外部依赖项或需要等待另一个 issue 解决，请将 issue 移动到“已阻止”列。
5. 如果 issue 已被接受并且下一步需要 RFC，请将 issue 移动到“等待 RFC”列，并在 issue 上评论需要 RFC。

注意： “Good first issue” issue 旨在帮助新贡献者感到受欢迎并有权为 ESLint 做出贡献。为了确保新贡献者有机会处理这些 issue，标记为“good first issue”的 issue 必须从 issue 被标记之日起开放 30 天，团队成员才能处理它们。

接受 Issue 和 Pull Request

当 issue 属于以下情况时，可能会被标记为“accepted”

• 您能够重现和验证的 bug（即，您确定它是一个 bug）。
• 您正在支持的新规则或规则更改，并且已就将其包含在项目中达成共识。

如果适合路线图，“accepted”标签将由 TSC 成员添加到其他 issue。

当 issue 被接受并且可以开始实施时，应将其移动到“准备好实施”列。

支持 Issue

新规则和规则更改需要支持者。作为支持者，您的工作是

• 从 ESLint 团队就包含达成共识。
• 指导规则创建过程直到完成（因此仅支持您有时间实施或帮助其他贡献者实施的规则）。

一旦就包含达成共识，请添加“accepted”标签。可选地，根据需要添加“help wanted”和“good first issue”标签。

共识

当至少有三名团队成员认为更改是一个好主意，并且没有人认为更改是一个坏主意时，就 issue 达成共识。为了表示您对 issue 的支持，除了您可能有的任何评论外，还在原始 issue 描述上留下 +1 反应（竖起大拇指）。

何时发送到 TSC

如果无法就 issue 达成共识，或者 issue 的进展停滞不前，并且不清楚是否应关闭 issue，那么您可以将 issue 提交给 TSC 进行解决。为此，请将“tsc agenda”标签添加到 issue，并添加包含以下信息的评论

1. 对到目前为止的讨论的单段摘要。这应以“TSC Summary:”开头。
2. 您希望 TSC 回答的问题。这应以“TSC Question:”开头。

该 issue 将在下一次 TSC 会议上讨论，解决方案将发布回 issue。

评估核心功能和增强功能（仅限 TSC 成员）

除了上述内容外，对核心（包括 CLI 更改）的更改，如果会导致次要或主要版本发布，则必须通过标准 TSC 动议获得 TSC 批准。将标签“tsc agenda”添加到 issue，它将在下一次 TSC 会议上讨论。一般来说，请求应满足以下标准才能被考虑

1. 功能或增强功能在项目的范围内，应添加到路线图中。
2. 有人承诺在明年内包含更改。
3. 对于谁将完成这项工作有合理的确定性。

当建议过于雄心勃勃或需要花费太多时间才能完成时，最好不要接受该提案。坚持小的、渐进的更改，并制定您希望项目最终走向的路线图。不要让项目陷入需要很长时间才能完成的大型功能中。

破坏性更改： 注意可能具有破坏性的更改。代表破坏性更改的 issue 应标记为“breaking”。

请求 TSC 的反馈

为了请求 TSC 的反馈，团队成员可以 ping @eslint/eslint-tsc 并在 issue 或 pull request 上添加标签“tsc waiting”。除非另有要求，否则每位 TSC 成员都应就标记为“tsc waiting”的 issue提供反馈。如果 TSC 成员无法及时回复，他们应发布评论，说明他们预计何时能够留下反馈。最后一位就标记为“tsc waiting”的 issue 提供反馈的 TSC 成员应删除该标签。

何时关闭 Issue

所有团队成员都可以根据 issue 的解决方式关闭 issue。

如果出现以下情况，团队成员可以立即关闭 issue

1. 该 issue 是现有 issue 的重复项。
2. 该 issue 只是一个问题并且已得到解答。

团队成员可以关闭共识为不接受 issue 的 issue，但需要等待一段时间（以确保其他团队成员有机会在 issue 关闭前进行审查）

• 如果 issue 在周一至周五打开，请等待 2 天。
• 如果 issue 在周六或周日打开，请等待 3 天。

为了使 issue backlog 保持可管理，如果满足以下条件，团队成员也可以关闭 issue

• 未接受：在打开 21 天后关闭，因为这些 issue 没有足够的支持来向前推进。
• 已接受：如果在 90 天后，团队或社区中没有人愿意挺身而出并负责完成工作，则关闭。
• 需要帮助： 如果在 90 天后仍未完成，则关闭。