Issues workflow

Issues workflow

在提交您自己之前，请在问题跟踪器中搜索类似的条目，否则很有可能其他人也有相同的问题或功能建议. 通过奖励表情符号显示您的支持和/或参加讨论.

请使用问题跟踪器提供的提交错误. 括号中的文字可以帮助您添加内容. 提交实际问题时将其忽略. 您可以复制粘贴它，然后根据需要进行编辑.

Issue triaging

我们的问题分诊政策有所描述 . 非常欢迎您帮助 GitLab 团队分类问题. 我们还每季度组织一次 .

最重要的是确保有效问题得到开发团队的反馈. 因此，优先考虑的是可以为这些问题提供帮助的开发人员. 请从GitLab 团队中选择具有相关经验的 . 如果没有人提到这种专业知识，请在提交历史中查找受影响的文件以找到某人.

我们还使用GitLab Triage来自动化一些分类策略. 当前已将其设置为在其上运行的计划管道（ ，必须至少具有开发人员访问项目的权限） 项目.

To allow for asynchronous issue handling, we use milestones and . Leads and product managers handle most of the scheduling into milestones. Labeling is a task for everyone.

大多数问题的标签至少包含以下之一：

  • 类型： ~feature ， ~bug ， ~backstage ， ~documentation等.
  • 阶段： ~"devops::plan" ， ~"devops::create"等
  • 组： ~"group::source code" ， ~"group::knowledge" ， ~"group::editor"等
  • 类别： ~"Category:Code Analytics" ， ~"Category:DevOps Score" ， ~"Category:Templates"等
  • 特点： ~wiki ， ~ldap ， ~api ， ~issues ， ~"merge requests" ，等等.
  • Department: ~UX, ~Quality
  • Team: ~"Technical Writing", ~Delivery
  • Specialization: ~frontend, ~backend, ~documentation
  • 发布范围： ， ~Stretch ， ~"Next Patch Release"
  • Priority: ~P1, ~P2, ~P3, ~P4
  • 严重性： S1 ， ~S2 ， ~S3 ， ~S4

所有标签，其含义和优先级均在标签页面上定义.

如果您遇到的问题都不存在，并且可以设置标签，则可以随时添加类型，阶段，组以及类别/功能标签.

类型标签非常重要. 他们定义了这是什么类型的问题. 每个问题都应该只有一个.

当前的类型标签为：

  • ~feature
  • ~bug
  • ~backstage
  • 〜”支持请求”
  • ~meta

许多类型标签都分配了优先级，这会根据其重要性自动使它们浮动到顶部.

类型标签始终是小写字母，并且可以具有除蓝色（已为类别标签保留）以外的任何颜色.

上的描述说明了每种类型标签下的内容.

GitLab 手册记录了什么是错误以及 .

Facet labels

有时，改进问题的类型很有用. 在这种情况下，您可以添加构面标签.

以下是构面标签的非详尽列表：

  • 增强功能：此标签可以完善具有功能标签的问题.
  • 〜” master：broken”：此标签可以细化带有〜bug 标签的问题.
  • 〜” failure :: flaky-test”：此标签可以细化带有〜bug 标签的问题.
  • 〜”技术债务”：此标签可以完善具有〜后台标签的问题.
  • 〜”静态分析”：此标签可以细化具有〜backstage 标签的问题.
  • 〜” ci-build”：此标签可以优化具有〜backstage 标签的问题.
  • 〜性能：性能问题可能描述〜错误或〜功能.
  • 〜安全性：一个安全性问题可以描述一个 bug 或一个功能.
  • 数据库：数据库问题可能描述错误或功能.
  • 〜customer：这与客户创建的或客户感兴趣的问题有关.
  • 〜” UI 文本”：在 UI 内添加或修改任何文本的问题，例如用户辅助显微镜，按钮/菜单标签或错误消息.

Stage labels

阶段标签指定问题属于哪个阶段 .

Naming and color convention

舞台标签遵守devops::<stage_key>命名约定. <stage_key>是阶段密钥，因为它位于https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml的单个真相来源中，其中_替换为空间.

例如，” Manage”阶段由gitlab-org组中的~"devops::manage"标签表示，因为它的关键stages是manage .

通过可以找到当前阶段的标签.

这些标签是作用域标签 ，因此是互斥的.

舞台标签用于自动生成 .

Group labels

组标签指定了问题所属的 .

强烈建议添加一个组标签，因为我们的分类自动化会使用它来推断正确的舞台标签 .

Naming and color convention

组标签遵循group::<group_key>命名约定，其颜色为#A8D695 . <group_key>是组密钥，因为它位于https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml 的组的单个真实来源中，其中已替换_与空间.

例如，” Continuous Integration”组由gitlab-org组中的〜” group :: continuous integration”标签表示，因为它的关键在stages.manage.groups下是 .

通过可以找到当前的组标签.

这些标签是作用域标签 ，因此是互斥的.

您可以在” 页面中找到列出的组 .

通常，舞台标签和组标签之间存在 1：1 的关系. 本着”人人都可以贡献”的精神，任何问题都可以由任何团体根据当前的优先事项来解决. 拾取属于其他组的问题时，应重新标记. 例如，如果计划阶段的”访问”组中的某人拾取了标有~"devops::create"和~"group::knowledge"的问题，则应在发布该问题时将其重新标记为~"group::access"保持原始~"devops::create"不变.

我们还使用阶段标签和组标签来帮助量化 . 请阅读吞吐量中的阶段和组标签，以获取有关在这种情况下如何使用标签的更多信息.

在手册的” 页面中：

强烈建议添加类别标签，因为我们的分类自动化会使用它来推断正确的组和阶段标签 .

如果您是特定领域的专家，则可以更轻松地找到要解决的问题. 您还可以订阅这些标签，以在每次用与您的专业知识相对应的类别标签标记问题时接收电子邮件.

Naming and color convention

类别标签遵循” Category:<Category Name>命名约定，其颜色为#428BCA . <Category Name>是类别名称，因为它位于https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 的类别的唯一真实来源中.

例如，” DevOps 分数”类别由gitlab-org组中的〜” Category：DevOps 分数”标签表示，因为其devops_score.name值为” DevOps 分数”.

如果类别的标签不遵守此命名约定，则应在使用label属性指定它.

Feature labels

From the handbook’s Product stages, groups, and categories page:

如果没有类别标签，强烈建议添加功能标签，因为我们的分类自动分类系统会使用该功能标签来 .

如果您是特定领域的专家，则可以更轻松地找到要解决的问题. 您还可以订阅这些标签，以在每次问题被标记有与您的专业知识相对应的功能标签时接收电子邮件.

特征标签的例子是~wiki ， ~ldap ， ~api ， ~issues ， ~"merge requests"等.

Naming and color convention

功能标签全部为小写.

Department labels

当前部门标签为：

  • ~UX
  • ~Quality

Team labels

重要提示 ：现在不推荐使用大多数历史团队标签（例如”管理”，”计划”等），而推荐使用” 和” 阶段”标签 .

团队标签指定负责此问题的团队. 分配团队标签可确保问题引起适当人员的注意.

当前的团队标签为：

  • ~Delivery
  • 〜”技术写作”

Naming and color convention

团队标签始终大写，以便显示为任何问题的第一个标签.

这些标签缩小了工作单元的专业范围.

  • ~frontend
  • ~backend
  • ~documentation

Release scoping labels

发布范围界定标签有助于我们清楚地传达对发布工作的期望. 发行范围界定标签分为三个级别：

  • 〜可交付成果：预期在当前里程碑中交付的问题.
  • 〜延伸：问题是实现当前里程碑的延伸目标. 如果当前发行版中未解决这些问题，则强烈考虑将它们用于下一个发行版.
  • 〜”下一个补丁程序发行版”：下一个补丁程序发行版中的问题. 首先进行处理，然后将~"Pick into XY"标签添加到合并请求中，并添加适当的里程碑.

为当前里程碑计划的每个发行都应标记为〜Deliverable 或〜” Stretch”. 上一个里程碑的所有未解决问题都应标记为”下一个补丁发布”，或以其他方式重新安排到另一个里程碑.

Priority labels

我们具有以下优先级标签：

  • ~P1
  • ~P2
  • ~P3
  • ~P4

请参阅手册中的问题分类部分，以了解其用法.

Severity labels

我们具有以下严重性标签：

  • ~S1
  • ~S2
  • ~S3
  • ~S4

请参阅手册中的问题分类部分，以了解其用法.

我们目前没有能力或不想给予优先考虑的对用户有益的问题” nice to haves”被标记为”正在接受合并请求”，以便社区可以做出贡献.

社区贡献者可以针对他们想要的任何问题提交合并请求，但是〜”接受合并请求”标签具有特殊含义. 它指出了以下变化：

  1. 我们已经达成共识，
  2. 定义明确
  3. 可能会被维护者接受.

我们希望避免出现以下情况：投稿人选择〜”接受合并请求”问题，然后关闭他们的合并请求，因为我们意识到它不符合我们的愿景，或者我们想以其他方式解决它.

我们建议从未参与过任何开源项目的人员寻找标有~"Accepting merge requests"且权重为 1或带有~"Good for 1st time contributors" 问题. 我们欢迎更多有经验的贡献者与他们一起解决.

如果您决定要解决某个问题，请@-提及 . 然后，产品经理将邀请适当的 GitLab 团队成员进一步讨论范围，设计和技术注意事项. 这将确保您的贡献与 GitLab 产品保持一致，并最大程度地减少返工和将其合并到 master 中的延迟.

在问题上贴上”接受合并请求”标签的 GitLab 团队成员应与负责任的产品经理一起更新问题描述，并邀请上述任何潜在的社区贡献者加入@提及.

Stewardship label

对于与 GitLab 的开源管理有关的问题，有〜”管理”标签.

该标签将用于解决有关 GitLab 管理问题的问题. 例如，如果 GitLab Inc.计划将 GitLab EE 中的功能添加到 GitLab CE 中，则相关问题将标记为”管理”.

最近的一个例子是 .

Feature proposals

要创建功能建议，请在上打开问题 .

为了帮助跟踪功能建议，我们创建了标签. 目前，不是项目成员的用户无法添加标签. 您可以改为要求核心团队成员之一在问题上添加标签〜feature，或在描述后的新行中添加以下代码段： ~feature .

请使功能建议尽可能小而简单，复杂的建议可能会被编辑以使其小而简单.

请使用问题跟踪器上提供的提交功能建议.

For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should be given the ~”UX” label. This will allow the UX team to provide input and guidance. You may need to ask one of the core team members to add the label, if you do not have permissions to do it by yourself.

如果您想自己创建一些东西，请考虑首先打开一个问题，讨论将其包含在 GitLab 中是否有趣.

问题权重使我们对解决一个或多个问题所需的工作量有所了解. 这样可以更准确地安排工作.

鼓励您设置任何问题的权重. 遵循以下准则将使其易于管理，而没有不必要的开销.

  1. 尽早设置任何问题的权重
  2. 如果您不同意设定的权重，请与其他开发人员讨论，直到就权重达成共识
  3. 问题权重是问题复杂性的抽象度量. 不要将发行权重直接与时间相关. 这称为 ，是您要避免的事情.
  4. 如果某事物非常大，则应将其拆分为多个问题或大块. 您不能简单地设置父问题的权重，而不能设置子问题的权重.

Regression issues

每个月度发行版的 CE 问题跟踪器上都有一个相应的发行版，以跟踪该发行版所破坏的功能以及修补程序发行版中需要包含的所有修补程序（请参阅示例）.

如问题描述中所概述的那样，预期的工作流程是发布一个注释，其中包含对描述回归的问题的引用，然后通过对合并请求的引用来更新该注释，该合并请求将在发布后对其进行修复.

如果您是贡献者，没有所需的权限来更新其他用户的注释，请发布新注释，同时提及问题和合并请求.

发布经理将在解决补丁程序后更新回归问题中 .

为了跟踪可以在 GitLab 的代码库中改进的事物，我们在GitLab 的问题跟踪器中使用〜”技术债务”标签. 对于错过的用户体验要求，我们使用〜” UX 债务”标签.

这些标签应添加到描述可以改进的问题，已采取的捷径，需要额外注意的功能以及由于高速发展而遗留下来的所有其他事项的问题上. 例如，需要重构的代码应使用〜”技术债务”标签，根据我们的设计系统准则，未交付的某些产品应使用〜” UX 债务”标签.

每个人都可以创建一个问题，但是如果您没有权限自行添加，则可能需要请求添加特定标签. 可以将其他标签与这些标签结合使用，以更轻松地计划发布的改进.

用这些标签标记的问题具有与描述要在 GitLab 中引入的新功能的问题相同的优先级，并且应该安排由适当的人员发布.

请确保在问题的描述中提及与”技术债务”问题或” UX 债务”问题相关的合并请求.

Technical debt in follow-up issues

在开发新功能时通常会发现技术债务. 本着”最小可行的改变”的精神，通常将解决方案推迟到后续问题上. 但是，这不能用作合并劣质代码的借口，否则这些劣质代码将无法通过审阅，或者忽略了琐事，这些琐事不值得单独安排，最好在原始合并请求中解决-否则完全追踪！

The overheads of scheduling, and rate of change in the GitLab codebase, mean that the cost of a trivial technical debt issue can quickly exceed the value of tracking it. This generally means we should resolve these in the original merge request - or simply not create a follow-up issue at all.

例如，在文件之间复制的注释中的错字值得在同一 MR 中修复，但不值得为其创建后续问题. 重命名在许多地方使用的方法以使其意图更清晰可能是值得修复的，但是这种方法不应在同一 MR 中发生，并且通常不值得自己解决. 如果我们要创建这些问题，这些问题将始终标记为~P4 ~S4 .

更严重的技术债务可能对发展速度产生影响. 如果不能及时解决，那么代码库将变得不必要地难以更改，新功能也将难以添加，并且大量回归.

应该认真对待此类技术债务的发现，尽管在后续问题中解决问题可能是适当的，但维护人员通常应从原始 MR 的作者或相关领域的工程或产品经理那里获得调度承诺. . 这可以采取在问题上使用适当的优先级/严重性标签的形式，也可以采用明确的里程碑和受让人的形式.

维护者必须始终同意，以这种方式解决一个悬而未决的讨论，并且它将是引发问题的人. 标题和描述的质量应与通常创建的标题和描述的质量相同-特别是，问题标题不能以” Follow-up开头！ 创建维护者还应该期望在后续问题上开始工作时会有所参与.