Versions

管理议题

新的议题经常被提交，我们如何应对这些议题直接影响到项目的成功。作为项目组的一员，意味着要帮助分流和解决所出现的议题，以便项目能够继续顺利运行。

要记住的事情

  1. 态度要好。即使人们在某个议题上表现得很粗鲁或咄咄逼人，作为项目组成员，你必须是对话中的成熟者。无论他们的风格如何，都要尽力与大家合作。记住，糟糕的措辞选择也可能是一个不太懂英语的人的标志，所以在试图确定某人信息的语气时一定要考虑这一点。无礼，即使有人对你无礼，也会对团队和整个项目产生不良影响。
  2. 要有好奇心。只要有不清楚的地方就提出议题。如果有细节遗漏，不要认为你了解报告的内容。每当你不确定时，最好询问更多信息。
  3. 不是所有的请求都是一样的。我们不太可能满足每一个请求，所以不要害怕说某些东西不符合项目的范围或不实用。如果是这样的话，最好能给出这样的反馈。
  4. 在适当的时候关闭。不要害怕关闭你认为不会完成的议题，或者当谈话中已经明确没有进一步的工作要做时。如果议题被错误地关闭，总是可以被重新打开，所以请在适当的时候自由关闭议题。请务必留下评论，解释为什么要关闭这个议题（如果不是通过提交来关闭）。

议题的类型

有四个主要的议题类别。

  1. 漏洞（Bug） - 某些东西没有按照预期的方式工作。
  2. 增强（Enhancement）–对已经存在的东西的改变。例如，在现有的规则中增加一个新的选项，或者在一个规则中存在漏洞，修复它将导致该规则报告更多的议题（在这种情况下，同时使用“漏洞（Bug）”和“增强（Enhancement）”）。
  3. 功能（Feature） - 增加一些不存在的东西。例如，添加一个新的规则，新的格式化，或新的命令行标志。
  4. 问题（Question） - 关于某些东西如何工作的询问，不会导致代码的改变。我们希望人们使用邮件列表或聊天室来提问，但有时他们也会打开一个议题。

当评估一个议题时，第一个目标是确定该议题属于哪个类别。

分流过程

所有 ESLint 的议题，包括所有 GitHub 仓库，都在我们的Triage Project上管理。在审查议题时，请使用 Triage 项目，而不是议题列表，以确定要处理的议题。Triage 项目有几个栏目。

需要分流 - 尚未被任何人审查的议题 分流（Triaging） - 有人审查过但尚未完全分流的议题 准备好交付开发团队（Ready for Dev Team） - 已被分流的议题，并具有开发团队查看的所有必要信息 正在评估（Evaluating） - 开发团队正在评估这些议题，以确定是否要继续前进。 需要反馈（Feedback Needed） - 一个团队成员在继续工作之前要求团队其他成员提供更多的意见。 等待 RFC（Waiting for RFC） - 该过程的下一步是编写RFC。 已开 RFC（RFC Opened） - 一个 RFC 被打开以解决这些议题 已阻止（Blocked） - 由于某些依赖性，该议题不能向前推进 准备实施（Ready to Implement） - 这些议题有开始实施所需的所有细节 已开 PR（PR Opened） - 这些议题都有一个开放的拉动请求 完成（Completed） - 该议题已被关闭（通过拉动请求合并或由团队手动关闭该议题）。

我们尽一切努力在尽可能多的栏目之间自动移动，但有时移动议题需要手动完成。

当有新议题时

当有新议题时，它会被自动添加到分流项目中的“需要分流（Needs Triage）”栏。这些议题需要被评估，以确定下一步行动。支持团队或开发团队的任何人都可以按照这些步骤来正确分流议题。

注意：如果议题位于“分流（Triaging）”栏中，这意味着有人已经在分流它，你应该让他们完成。除非有人请求帮助，否则没有必要对“分流（Triaging）”栏中的议题进行评论。

分流议题的步骤是：

  1. 将议题从“需要分流（Needs Triage）”移到分流项目中的“分流（Triaging）”。
  2. 检查：是否已经提供了议题模板中的所有信息？
    • 否：如果议题模板中缺少信息，或者你无法判断请求的内容，请要求作者提供缺少的信息。
      • 在议题上添加“需要信息（needs info）”的标签，以便我们知道这个议题由于缺乏信息而被搁置。
      • 在必要的信息被提供之前，不要继续进行其他步骤。
      • 如果议题作者在 7 天后还没有提供必要的信息，请关闭该议题。机器人会添加一个评论，说明该议题被关闭是因为缺少信息。
    • 是：
      • 如果该议题实际上是一个议题（而不是开发团队需要改变的东西），请将其转换为讨论。你可以将对话作为一个讨论继续进行。
      • 如果该议题是报告一个错误，请尝试按照议题中的指示重现该议题。如果你能重现这个议题，请添加“repro:yes”标签）机器人会自动删除“repro:need”标签）。如果你不能重现该议题，请向作者询问更多关于他们环境的信息或澄清重现步骤。
      • 如果该议题报告的是如期工作，请添加“如期工作（works as intended）”标签并关闭该议题。
      • 对于所有议题，请添加标签，描述ESLint受影响的部分。
        • 第三方插件（3rd party plugin）- 与第三方功能（插件、解析器、规则等）有关。
        • 构建（build）- 与在构建过程中运行的命令有关（测试、检查、发布脚本等）。
        • 命令行（cli）- 与命令行输入或输出有关，或与 CLIEngine 有关
        • 核心（core）- 与内部 API 有关
        • 文档（documentation）- 与 eslint.org 上的内容有关
        • 基础设施（infrastructure）- 与构建或部署所需的资源有关（虚拟机、CI 工具、机器人等）
        • 规则（rule）- 与核心规则有关
      • 如果你不能正确地分流该议题，请将该议题移回分流项目中的“需要分流（Needs Triage）”栏，以便其他人能够分流它
      • 如果你已经分流了议题，把议题移到分流项目中的“准备好交付开发团队（Ready for Dev Team）”一栏中

评估过程

当一个议题被移到“准备好交付开发团队（Ready for Dev Team）”一栏时，任何开发团队成员都可以拿起这个议题开始评估它。

  1. 将议题移到“正在评估（Evaluating）”栏中。
  2. 接下来的步骤。 漏洞：如果你能验证该漏洞，添加“已接受（accepted）”标签，并询问他们是否愿意提交拉动请求。 新规则：如果你愿意拥护该规则（意味着你认为它应该被纳入 ESLint 核心，并且你将主导纳入该规则的过程），添加评论说你将拥护该议题，将该议题分配给自己，并遵循下面的指南。 规则变化：如果你愿意支持这个变化，并且它不会是一个破坏性的变化（需要一个主要的版本增量），添加一个评论说你将支持这个议题，把这个议题分配给你自己，并遵循下面的指南。 破坏性改变：如果你怀疑或可以证实某项改变是破坏性的，请将其标记为“破坏性（Breaking）”。 重复议题：如果你能证实该议题是重复的，请添加评论提及重复的议题（例如，“#1234的 副本”）并关闭该议题。
  3. 无论上述情况如何，都要留下评论。不要只是添加标签，通过提问（必要时要求提供更多信息）或说明你对该议题的看法，与打开该议题的人互动。如果这是一个经过验证的错误，询问用户是否愿意提交一个拉动请求。
  4. 如果这个议题无法实施，因为它需要更新外部依赖关系，或者需要等待另一个议题的解决，那么就把这个议题移到“已阻止（Blocked）”栏。
  5. 如果该议题已被接受，且下一步需要RFC，则将该议题移至“等待 RFC（Waiting for RFC）”栏，并在该议题上注释需要 RFC。

注意：“适合入手（good first issue）”议题是为了帮助新的贡献者感到受欢迎，并有能力对 ESLint 做出贡献。为了确保新的贡献者有机会在这些议题上工作，被标记为“适合入手（good first issue）”的议题必须开放 30 天（从议题被标记的那天起）才允许团队成员在这些议题上工作。

接受议题

当议题是以下情况时，议题可以被标记为“已接受（accepted）”：

  • 你已经重现并验证的错误（即你确定它是一个错误）。
  • 你正在倡导的新规则或规则变化，并且在项目中已经达成了共识。

如果“已接受（accepted）”的标签对路线图来说是合适的，将由 TSC 成员添加到其他议题上。

当议题被接受并且可以开始实施时，它应该被移到“准备实施（Ready to Implement）”栏中。

倡导议题

新的规则和规则变化需要倡议。倡议者需要：

  • 从 ESLint 团队中获得关于包容性的共识。
  • 引导规则的创建过程，直到它完成（所以只有在你有时间实施或帮助其他贡献者实施的情况下，你才能成为规则的支持者）

一旦就议题达成共识，则可在必要时添加“已接受（accepted）”以及“需要帮助（help wanted）”和“适合入手（good first issue）”的标签。

共识

当至少有三个团队成员认为这个变化是个好主意，并且没有人认为这个变化是个坏主意时，就会在议题上达成共识。为了表示你对某一议题的支持，除了你可能有的任何评论外，在原始议题描述上留下 +1 反应（大拇指）。

何时提交给 TSC

如果不能就某一议题达成共识，或某一议题的进展停滞不前，不清楚是否应该关闭该议题，那么你可以将该议题提交给 TSC 解决。要做到这一点，请为该议题添加“TSC 议程（tsc agenda）”标签，并添加包括以下信息的评论：

  1. 对到目前为止的讨论进行一段总结。
  2. 你希望 TSC 回答的议题。

该议题将在下一次 TSC 会议上讨论，决议将被贴回该议题。

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

除上述内容外，对核心的修改（包括 CLI 的修改），如果会导致小版本或大版本的发布，必须由 TSC 通过标准的TSC动议批准。在该议题上添加“TSC 议程（tsc agenda）”的标签，它将在下一次 TSC 会议上讨论。一般来说，仅考虑满足以下标准的请求：

  1. 该功能或改进在项目的范围内，应该被添加到路线图中。
  2. 有人承诺在未来一年内加入该变化
  3. 对谁来做这项工作有合理的确定性。

当一个建议步子迈的太大或需要太多的时间来完成时，最好不要接受这个建议。坚持小的、渐进式的修改，并为你希望项目最终走向何方制定一个路线图。不要让项目被那些需要很长时间才能完成的大功能所拖累。

破坏性变化（Breaking Changes）：要注意那些会破坏的变化。代表破坏性变化的议题应该被标记为“破坏性（breaking）”。

何时关闭议题

所有团队成员都可以根据议题的解决情况来关闭议题。

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

  1. 该议题是现有议题的副本。
  2. 该议题只是个问题，并已被回答。

团队成员可以关闭议题，如果共识是在等待期后不接受该议题（以确保其他团队成员有机会在关闭前审查该议题）。

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

为了保持议题的可管理性，如果满足以下条件，团队成员也可以关闭议题：

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

编辑此页