Versions

管理议题和拉取请求

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

要记住的事情

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

分类议题和拉取请求

有五个主要分类:

  1. 缺陷(Bug):某些东西没有按照预期的方式工作。
  2. 增强(Enhancement):对已经存在的东西的改变。例如,在现有的规则中增加一个新的选项,或者在一个规则中存在漏洞,修复它将导致该规则报告更多的议题(在这种情况下,同时使用“缺陷(Bug)”和“增强(Enhancement)”)。
  3. 功能(Feature):增加一些不存在的东西。例如,添加一个新的规则,新的格式化,或新的命令行标志。
  4. 文档(Documentation):添加、更新或删除项目文档。
  5. 问题(Question):关于询问某些东西是如何工作的,而不会导致代码的改变。我们希望人们使用 GitHub 讨论或 Discord 来提问,而非创建议题。

当评估一个议题或拉取请求时,第一步就需要确定它属于哪个分类。

分流过程

包括所有 GitHub 仓库的 ESLint 议题和拉取请求,都通过我们的 Triage 项目进行管理。在审查议题时,请使用 Triage 项目,而不是议题列表,以确定要处理的议题。Triage 项目有几个栏目:

需要分流(Needs Triage):尚未被任何人审查的议题和拉取请求 分流(Triaging):有人审查过但尚未完全分流的议题和拉取请求 准备好交付开发团队(Ready for Dev Team):已分流的议题和拉取请求,并具备供开发团队查看的所有必要信息 正在评估(Evaluating):开发团队正在评估这些议题和拉取请求,以确定是否要继续前进 需要反馈(Feedback Needed):团队成员在继续工作之前要求团队其他成员提供更多的意见 等待 RFC(Waiting for RFC):下一步是编写 RFC 已开 RFC(RFC Opened):创建了 RFC 以解决这些议题 已阻止(Blocked):由于某些依赖,该议题不能向前推进 准备实施(Ready to Implement):这些议题有开始实施所需的所有细节 实施中(Implementing):这些议题都有一个开放的拉取请求,如果是拉取请求则已被批准 完成(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):与核心规则有关
      • 请根据议题或拉取请求的重要性分配初始优先级。如果不确定,相信你的直觉。我们随时可以更改优先级。
        • P1:紧急且重要,我们需要立即解决。
        • P2:重要但不紧急。应由 TSC 成员或审查者处理。
        • P3:很好,但并不重要。任何团队成员都可以胜任。
        • P4:好主意,但团队可能需要一段时间才能实现。
        • P5:好主意,但核心团队无法承诺一定实现,很可能需要由外部人员来完成。
      • 请初步评估影响范围(凭借直觉):
        • 低(Low):不会影响很多用户。
        • 中(Medium):影响大多数用户或对用户体验有明显影响。
        • 高(High):影响大量用户,破坏性变更或用户会非常明显地感觉到。
      • 如果你不能正确地分流该议题或拉取请求,请将该议题移回分流项目中的“需要分流(Needs Triage)”一栏,以便其他人能够分流它。
      • 如果拉取请求引用了已接受的问题,则将其移至分流项目中的“实施中(Implementing)”一栏。
      • 如果你已经分流了议题,把议题移到分流项目中的“准备好交付开发团队(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. 对到目前为止的讨论进行一段总结。应以“TSC Summary:”开头。
  2. 你希望 TSC 回答的议题。应以“TSC Question:”开头。

该议题将在下一次 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 天后关闭,如果它没有完成。

更改语言