版本

管理 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”和“增强功能”）。
  3. 功能：添加尚不存在的事物。例如，添加新的规则、新的格式化程序或新的命令行标志。
  4. 文档：添加、更新或删除项目文档。
  5. 问题：关于某些内容如何工作的问题，不会导致代码更改。我们更希望人们使用 GitHub Discussions 或 Discord 来提问，但有时他们会打开 Issue。

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

分类流程

ESLint 的所有 Issue 和 Pull Request（跨所有 GitHub 存储库）都在我们的 分类项目 中进行管理。在审查 Issue 以确定要处理的内容时，请使用分类项目而不是 Issue 列表。分类项目有几个列

  • 需要分类：尚未由任何人审查的 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 被打开时，它会自动添加到分类项目中的“需要分类”列中。需要评估这些 Issue 和 Pull Request 以确定后续步骤。支持团队或开发团队中的任何人都可以按照以下步骤正确分类 Issue。

注意：如果 Issue 或 Pull Request 位于“正在分类”列中，则表示某人正在分类它，您应该让他们完成。除非有人请求帮助，否则无需在“正在分类”列中的 Issue 或 Pull Request 上发表评论。

分类 Issue 或 Pull Request 的步骤如下

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

评估流程

当 Issue 已移动到“准备就绪，等待开发团队”列时，任何开发团队成员都可以选择该 Issue 并开始评估它。

  1. 将 Issue 移入“正在评估”列。
  2. 后续步骤

    • Bug：如果您可以验证该 Bug，请添加“accepted”标签并询问他们是否愿意提交 Pull Request。
    • 新规则：如果您愿意成为该规则的负责人（这意味着您认为它应该包含在 ESLint 核心代码中，并且您将负责将其纳入其中的流程），请添加一条评论，说明您将负责此问题，将问题分配给自己，并遵循以下指南。
    • 规则更改：如果您愿意成为更改的负责人，并且它不会是破坏性更改（不需要主要版本更新），请添加一条评论，说明您将负责此问题，将问题分配给自己，并遵循以下指南。
    • 破坏性更改：如果您怀疑或可以验证更改将是破坏性的，请将其标记为“Breaking”。
    • 重复项：如果您能够验证该问题是重复项，请添加一条评论，提及重复的问题（例如，“Duplicate of #1234”），并关闭该问题。
  3. 无论上述情况如何，始终都要留下评论。不要只添加标签；通过提问（如有必要，请求更多信息）或陈述您对问题的看法来与打开问题的人互动。如果是已验证的 Bug，请询问用户是否愿意提交 Pull Request。
  4. 如果无法实现该问题，因为它需要更新外部依赖项或需要等待另一个问题解决，请将该问题移至“Blocked”列。
  5. 如果该问题已被接受，并且 RFC 是下一步，请将该问题移至“Waiting for RFC”列，并在问题上评论需要 RFC。

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

接受 Issue 和 Pull Request

当问题满足以下条件时，可以将其标记为“accepted”

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

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

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

支持 Issue

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

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

一旦达成关于纳入的共识，请添加“accepted”标签。如有必要，还可以根据需要添加“help wanted”和“good first issue”标签。

共识

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

何时发送给 TSC

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

  1. 迄今为止讨论的简要概述。这应该以“TSC Summary:”开头。
  2. 您希望 TSC 回答的问题。这应该以“TSC Question:”开头。

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

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

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

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

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

破坏性更改：注意可能导致破坏性更改的更改。表示破坏性更改的问题应标记为“breaking”。

请求 TSC 反馈

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

何时关闭 Issue

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

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

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

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

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

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

  • 未接受：在打开 21 天后关闭，因为这些问题没有足够的支持来推进。
  • 已接受：如果团队或社区中没有人愿意站出来并拥有完成它的工作，则在 90 天后关闭。
  • 需要帮助：如果 90 天后尚未完成，则关闭。
编辑此页面
© OpenJS Foundation 和 ESLint 贡献者，www.openjsf.org。内容根据MIT 许可证授权。
更改语言