管理问题和 Pull Request

新的 Issue 和 Pull Request 频繁提交，我们对这些 Issue 的响应方式直接影响项目的成功。作为项目团队的一员，意味着帮助分诊和处理收到的 Issue，以便项目能够顺利进行。

需要注意的事项

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

Issue 和 Pull Request 的类型

主要有五个类别

Bug（错误）：某些功能没有按预期工作。
Enhancement（增强）：对现有功能的更改。例如，向现有规则添加新选项，或修复规则中的错误，其中修复错误会导致规则报告更多问题（在这种情况下，同时使用“Bug”和“Enhancement”）。
Feature（功能）：添加不存在的功能。例如，添加新规则、新格式化程序或新的命令行标志。
Documentation（文档）：添加、更新或删除项目文档。
Question（问题）：关于某个工作原理的询问，不会导致代码更改。我们更希望人们使用 GitHub Discussions 或 Discord 提问，但有时他们会打开一个 Issue。

评估 Issue 或 Pull Request 的第一目标是确定 Issue 属于哪个类别。

分诊流程

ESLint 的所有 Issue 和 Pull Request，在所有 GitHub 仓库中，都在我们的分诊项目上管理。请使用分诊项目而不是 Issue 列表来查看 Issue，以确定要处理的内容。分诊项目有几个列

Needs Triage（需要分诊）：尚未由任何人审查的 Issue 和 Pull Request。
Triaging（正在分诊）：有人已经审查过，但尚未完全分诊的 Issue 和 Pull Request。
Ready for Dev Team（准备给开发团队）：已经分诊，并且开发团队可以查看所需的所有信息的 Issue 和 Pull Request。
Evaluating（正在评估）：开发团队正在评估这些 Issue 和 Pull Request，以确定是否继续进行。
Feedback Needed（需要反馈）：团队成员正在向团队的其余成员请求更多输入，然后再继续进行。
Waiting for RFC（等待 RFC）：流程的下一步是编写 RFC。
RFC Opened（RFC 已打开）：已打开 RFC 来解决这些 Issue。
Blocked（已阻止）：由于某种依赖关系，Issue 无法继续进行。
Ready to Implement（准备实施）：这些 Issue 具有开始实施所需的所有细节。
Implementing（正在实施）：这些 Issue 中每个 Issue 都有一个开放的 Pull Request，或者这是一个已经获得批准的 Pull Request。
Second Review Needed（需要第二次审查）：Pull Request 已经获得一个批准，并且批准者在合并之前要求进行第二次审查。
Merge Candidates（合并候选）：Pull Request 已经获得至少一个批准，并且至少一个批准者认为 Pull Request 准备好合并到下一个版本，但仍然希望 TSC 成员进行验证。
Complete（完成）：Issue 已关闭（通过 Pull Request 合并或由团队手动关闭 Issue）。

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

当 Issue 或 Pull Request 被打开时

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

注意： 如果 Issue 或 Pull Request 在“Triaging”列中，这意味着有人已经在分诊它，你应该让他们完成。除非有人请求帮助，否则无需对“Triaging”列中的 Issue 或 Pull Request 进行评论。

分诊 Issue 或 Pull Request 的步骤是

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

评估流程

当 Issue 被移动到“Ready for Dev Team”列时，任何开发团队成员都可以选择该 Issue 来开始评估它。

将 Issue 移动到“Evaluating”列。
下一步
- Bugs（错误）：如果你可以验证该错误，请添加“accepted”标签并询问他们是否希望提交 Pull Request。
- New Rules（新规则）：如果你愿意倡导该规则（意味着你相信它应该包含在 ESLint 核心中，并且你将承担包含它的过程），请添加评论说明你将倡导该 Issue，将 Issue 分配给自己，并遵循指南。
- 规则变更：如果您愿意负责该变更，并且该变更不会造成破坏性更新（无需主版本号递增），请添加评论说明您将负责该问题，将问题分配给自己，并遵循指南。
- 破坏性变更：如果您怀疑或能够验证某个变更会造成破坏性更新，请将其标记为“Breaking”。
- 重复问题：如果您能够验证该问题是重复问题，请添加评论提及重复问题（例如，“Duplicate of #1234”），并关闭该问题。
无论上述情况如何，始终留下评论。不要仅仅添加标签；与提交问题的用户互动，提出问题（如有必要，请求更多信息）或表达您对该问题的看法。如果确认是错误，请询问用户是否愿意提交拉取请求。
如果该问题无法实现，因为它需要更新外部依赖项或需要等待另一个问题解决，请将该问题移动到“Blocked”列。
如果该问题已被接受，并且需要 RFC 作为下一步，请将该问题移动到“Waiting for RFC”列，并在问题上评论说明需要 RFC。

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

接受 Issue 和 Pull Request

当问题是

您能够重现和验证的错误（即，您确定这是一个错误）。
您正在负责的新规则或规则变更，并且已就将其包含在项目中的事宜达成共识。

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

当问题被接受并且可以开始实现时，应将其移动到“Ready to Implement”列。

倡导 Issue

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

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

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

共识

当至少有三名团队成员认为变更是一个好主意，并且没有人认为变更是一个坏主意时，问题就达成共识。为了表明您对问题的支持，请在原始问题描述中留下 +1 反应（点赞），以及您可能提出的任何评论。

何时提交给 TSC

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

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

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

评估核心功能和增强 (仅限 TSC 成员)

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

该功能或增强功能在项目的范围内，应添加到路线图中。
有人承诺在未来一年内包含该变更。
对谁将完成这项工作有合理的把握。

当一个建议过于雄心勃勃或需要太长时间才能完成时，最好不要接受该建议。坚持小而增量的变更，并制定项目最终发展方向的路线图。不要让项目陷入需要很长时间才能完成的大功能中。

破坏性变更：留意可能造成破坏性变更的变更。代表破坏性变更的问题应标记为“breaking”。

向 TSC 征求反馈

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

何时关闭 Issue

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

团队成员可以在以下情况下立即关闭问题

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

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

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

为了保持问题积压的可管理性，团队成员还可以关闭问题，如果满足以下条件

未接受：在打开 21 天后关闭，因为这些问题没有足够的支持来推进。
已接受：如果在 90 天内没有团队成员或社区成员愿意站出来并拥有完成该工作，则关闭。
需要帮助：如果在 90 天内未完成，则关闭。

编辑此页