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 天后关闭,如果它没有完成。