管理 Issue 和 Pull Request

新的 Issue 和 Pull Request 经常被提交，我们如何回应这些 Issue 直接影响着项目的成功。作为项目团队的一员，这意味着帮助对收到的 Issue 进行分类和处理，以便项目能够继续顺利运行。

需要牢记的事项

保持友好。即使有人在 Issue 中表现粗鲁或咄咄逼人，作为项目团队成员，您也必须在对话中保持成熟。尽力与每个人合作，无论他们的风格如何。请记住，措辞不当也可能是某些人英语不太好的一种表现，因此在试图判断某人信息语气时，务必考虑到这一点。即使有人对你粗鲁，你也不能表现出粗鲁，因为这会给团队和整个项目带来负面影响。
保持好奇心。当某些事情不清楚时，在 Issue 上提出问题。如果缺少细节，不要假设您理解了正在报告的内容。无论何时不确定，最好要求提供更多信息。
并非所有请求都平等。我们不可能满足每个请求，因此不要害怕说某些事情不符合项目的范围或不切实际。如果情况属实，最好给出这样的反馈。
在适当的时候关闭。不要害怕关闭您认为不会完成的 Issue，或者当从对话中清楚地表明没有进一步的工作要做时。如果 Issue 被错误地关闭，可以随时重新打开，因此在适当的时候可以随时关闭 Issue。只需确保留下评论解释为什么关闭 Issue（如果不是由提交关闭）。

Issue 和 Pull Request 的类型

主要有五类

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

评估 Issue 或 Pull Request 的首要目标是确定该 Issue 属于哪一类。

分类流程

所有 ESLint 的 Issue 和 Pull Request（跨所有 GitHub 存储库）都在我们的 Triage 项目中管理。在审查 Issue 以确定要处理哪些 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 准备合并到下一个版本中，但仍希望 TSC 成员进行验证的 Pull Request。
已完成：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 进行分类的步骤如下

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

评估流程

当问题被移至“准备就绪，等待开发团队”列时，任何开发团队成员都可以选择该问题开始评估。

将问题移至“评估中”列。
后续步骤
- Bug：如果您能够验证 Bug，请添加“已接受”标签，并询问用户是否愿意提交拉取请求。
- 新规则：如果您愿意成为该规则的负责人（这意味着您认为它应该包含在 ESLint 核心代码中，并且您将负责将其纳入其中的过程），请添加一条评论说明您将负责该问题，将问题分配给自己，并遵循下面指南。
- 规则更改：如果您愿意成为更改的负责人，并且它不会是重大更改（不需要主版本号递增），请添加一条评论说明您将负责该问题，将问题分配给自己，并遵循下面指南。
- 重大更改：如果您怀疑或能够验证更改是重大更改，请将其标记为“重大更改”。
- 重复问题：如果您能够验证该问题是重复问题，请添加一条评论提及重复的问题（例如，“重复 #1234”），并关闭该问题。
无论上述情况如何，始终要留下评论。不要只是添加标签；通过提出问题（如有必要，请求更多信息）或陈述您对问题的看法来与打开问题的人互动。如果是已验证的 Bug，请询问用户是否愿意提交拉取请求。
如果问题无法实施，因为它需要更新外部依赖项或需要等待另一个问题解决，请将问题移至“已阻塞”列。
如果问题已被接受，并且下一步需要 RFC，请将问题移至“等待 RFC”列，并在问题上评论需要 RFC。

注意：“适合新手的问题”旨在帮助新贡献者感到受欢迎并获得授权，为 ESLint 做出贡献。为了确保新贡献者有机会处理这些问题，标记为“适合新手的问题”的问题必须在问题被标记之日起开放 30 天，然后团队成员才能开始处理它们。

接受 Issue 和 Pull Request

当问题满足以下条件时，可能会被标记为“已接受”

您能够重现和验证的 Bug（即您确定它是 Bug）
您正在负责的新规则或规则更改，并且已达成共识将其纳入项目

如果适合路线图，TSC 成员会将“已接受”标签添加到其他问题。

当问题被接受并且可以开始实施时，应将其移至“准备实施”列。

推动 Issue

新规则和规则更改需要负责人。作为负责人，您的工作是

获得 ESLint 团队对纳入的共识
指导规则创建过程，直到完成（因此，只负责您有时间实施或帮助其他贡献者实施的规则）

一旦达成关于纳入的共识，请添加“已接受”标签。根据需要，可选地添加“需要帮助”和“适合新手的问题”标签。

共识

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

何时发送给 TSC

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

到目前为止讨论的简要概述。这应该以“TSC 摘要：”开头。
您希望 TSC 回答的问题。这应该以“TSC 问题：”开头。

将在下次 TSC 会议上讨论该问题，并将决议发布回该问题。

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

除了上述内容外，对核心（包括 CLI 更改）的更改会导致次要或主要版本发布，必须由 TSC 通过标准 TSC 提案批准。在问题上添加标签“tsc 议程”，它将在下次 TSC 会议上讨论。通常，请求应满足以下条件才能被考虑

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

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

重大更改：注意可能导致重大更改的更改。代表重大更改的问题应标记为“重大更改”。

请求 TSC 的反馈

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

何时关闭 Issue

所有团队成员都可以在问题解决后根据情况关闭问题。

团队成员可以**立即**关闭问题，如果

该问题是现有问题的重复。
该问题只是一个问题，并且已得到解答。

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

如果问题是在周一至周五打开的，请等待2 天。
如果问题是在周六或周日打开的，请等待3 天。

为了努力保持问题积压工作易于管理，如果满足以下条件，团队成员也可以关闭问题

未接受：在问题开放 21 天后关闭，因为这些问题没有足够的支持来推进。
已接受：如果团队或社区中没有人愿意站出来承担完成工作的责任，则在 90 天后关闭。
需要帮助：如果 90 天后未完成，则关闭。

编辑此页面