标签
为了支持异步问题处理，我们使用 milestones
和 labels。负责人和产品经理主要负责将任务安排到里程碑中。而标记标签则是每个人的任务。（对于某些项目，标签只能由 GitLab 团队成员设置，社区贡献者无法设置）。
大多数问题至少会包含以下一种标签：
- 类型。例如：
~"type::feature"、~"type::bug"或~"type::maintenance"。 - 阶段。例如：
~"devops::plan"或~"devops::create"。 - 分组。例如：
~"group::source code"、~"group::knowledge"或~"group::editor"。 - 类别。例如：
~"Category:Code Analytics"、~"Category:DevOps Reports"或~"Category:Templates"。 - 功能。例如：
~wiki、~ldap、~api、~issues或~"merge requests"。 - 部门：
~UX、~Quality - 团队：
~"Technical Writing"、~Delivery - 专长：
~frontend、~backend、~documentation - 发布范围：
~Deliverable、~Stretch、~"Next Patch Release" - 优先级：
~"priority::1"、~"priority::2"、~"priority::3"、~"priority::4" - 严重程度：
~"severity::1"、~"severity::2"、~"severity::3"、~"severity::4"
如果问题属于 breaking change，请添加 ~"breaking change" 标签。
如果问题与应用安全相关，请添加 ~security 标签。
所有标签及其含义和优先级都在 标签页面 中定义。
如果您遇到没有任何标签的问题，且您有权设置标签，可以随时添加类型、阶段、分组标签，通常还可以添加类别/功能标签。
类型标签
类型标签非常重要。它们定义了问题的类型。每个问题都应有且仅有一个类型标签。
类型和子类型标签的单一真实来源（SSOT）可在 手册中查阅。
部分类型标签被分配了优先级，根据其重要性会自动置顶。
类型标签必须小写，且不能使用蓝色（蓝色已保留给类别标签）。
标签页面 的描述解释了每个类型标签涵盖的内容。
GitLab 手册说明了 何时属于 bug 和 何时属于功能请求。
阶段标签
阶段标签指定问题所属的 阶段。
命名和颜色约定
阶段标签遵循 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。
当前阶段标签可通过 在标签列表中搜索 devops:: 找到。
这些标签是 作用域标签，因此互斥。
阶段标签用于自动生成 方向页面。
分组标签
分组标签指定问题所属的 分组。
强烈建议添加分组标签，因为我们的分类自动化会使用它来 推断正确的阶段标签。
命名和颜色约定
分组标签遵循 group::<group_key> 命名约定，颜色为 #A8D695。
<group_key> 是分组在单一真实来源中的键值（位于 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml），其中 _ 替换为空格。
例如，“Pipeline Execution” 分组在 gitlab-org 组中用 ~"group::pipeline execution" 标签表示，因为其在 stages.manage.groups 下的键值为 pipeline_execution。
当前分组标签可通过 在标签列表中搜索 group:: 找到。
这些标签是 作用域标签，因此互斥。
您可以在 产品阶段、分组和类别 页面中找到所有分组。
我们使用 “分组” 一词来映射产品阶段中的产品需求。由于团队需要收集其成员计划分配的工作，我们使用 ~group:: 标签来实现这一点。
类别标签
来自手册的 产品阶段、分组和类别 页面：
类别是高级能力，在其他公司可能是独立产品，例如组合管理（Portfolio Management）。
强烈建议添加类别标签，因为我们的分类自动化会使用它来 推断正确的分组和阶段标签。
如果您是某个领域的专家，类别标签能帮助您更容易找到可处理的问题。您还可以订阅这些标签，每当问题被标记为与您专长对应的类别标签时，您会收到邮件通知。
命名和颜色约定
类别标签遵循 Category:<Category Name> 命名约定，颜色为 #428BCA。
<Category Name> 是类别在单一真实来源中的名称（位于 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml）。
例如，“DevOps Reports” 类别在 gitlab-org 组中用 ~"Category:DevOps Reports" 标签表示，因为其 devops_reports.name 值为 “DevOps Reports”。
如果类别标签不遵循此命名约定，应在 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 中通过 label 属性 指定。
功能标签
来自手册的 产品阶段、分组和类别 页面：
功能：小型独立功能，例如问题权重。部分常见功能在括号中列出，便于通过关键词找到对应的产品经理。
如果不适用类别标签，强烈建议添加功能标签，因为我们的分类自动化会使用它来 推断正确的分组和阶段标签。
如果您是某个领域的专家，功能标签能帮助您更容易找到可处理的问题。您还可以订阅这些标签，每当问题被标记为与您专长对应的功能标签时，您会收到邮件通知。
功能标签的示例包括 ~wiki、~ldap、~api、~issues 和 ~"merge requests"。
命名和颜色约定
功能标签均为小写。
工作流标签
问题使用以下工作流标签指定当前状态：
~"workflow::awaiting security release"~"workflow::blocked"~"workflow::complete"~"workflow::design"~"workflow::feature-flagged"~"workflow::in dev"~"workflow::in review"~"workflow::planning breakdown"~"workflow::problem validation"~"workflow::production"~"workflow::ready for design"~"workflow::ready for development"~"workflow::refinement"~"workflow::scheduling"~"workflow::solution validation"~"workflow::start"~"workflow::validation backlog"~"workflow::verification"
维度标签
为跟踪创建问题的附加信息或上下文，开发者可添加 维度标签。维度标签有时也用于问题优先级排序或度量（如关闭时间）。例如 ~"customer" 标签表示客户兴趣。
部门标签
当前部门标签包括：
~"UX"~"Quality"~"infrastructure"~"security"
团队标签
重要提示：大多数历史团队标签（如 Manage 或 Plan）现已弃用，推荐使用 分组标签 和 阶段标签。
团队标签指定哪个团队负责此问题。分配团队标签可确保问题得到相关人员的关注。
当前团队标签包括：
~"Delivery"~"Technical Writing"~"Engineering Productivity"~"Contributor Success"
命名和颜色约定
团队标签始终大写，以便在任何问题中显示为第一个标签。
专长标签
这些标签缩小了工作单元的 专长 范围。
~"frontend"~"backend"~"documentation"
发布范围标签
发布范围标签帮助我们清晰传达对发布工作的期望。发布范围标签分为三个级别：
~"Deliverable"：预计在当前里程碑交付的问题。~"Stretch"：作为当前里程碑交付的延伸目标。如果这些问题在当前版本中未完成，将强烈考虑在下一个版本中实现。~"Next Patch Release"：计划放入下一个补丁版本的问题。优先处理这些问题，并遵循 补丁版本运行手册 将修复程序回溯到当前版本。
当前里程碑中的每个问题都应标记为 ~"Deliverable" 或 ~"Stretch"。任何未解决的旧里程碑问题应标记为 ~"Next Patch Release"，或重新安排到其他里程碑。
优先级标签
我们有以下优先级标签：
~"priority::1"~"priority::2"~"priority::3"~"priority::4"
请参考手册中的问题分类 优先级标签 部分，了解其使用方式。
严重程度标签
我们有以下严重程度标签：
~"severity::1"~"severity::2"~"severity::3"~"severity::4"
请参考手册中的问题分类 严重程度标签 部分，了解其使用方式。
社区贡献者标签
许多问题有明确的解决方案，且对 GitLab 用户有争议性较小的益处。然而，GitLab 可能无法在当前路线图中容纳所有这些建议。这些问题被标记为 ~"Seeking community contributions"，因为我们欢迎合并请求来解决它们。
社区贡献者可以提交任何问题的合并请求，但 ~"Seeking community contributions" 标签有特殊含义。它指向以下变更：
- 我们已达成共识，
- 定义清晰，
- 很可能被维护者接受。
我们希望避免这种情况：贡献者选择了一个 ~"Seeking community contributions" 问题，但其合并请求被关闭，因为我们意识到它不符合我们的愿景，或我们想以不同方式解决。
我们手动将 ~"Seeking community contributions" 标签添加到符合上述标准的问题中。我们不自动添加此标签，因为它需要人工评估。
我们建议从未参与过任何开源项目的人寻找标记为 ~"Seeking community contributions" 且 权重为 1 或带有 ~"quick win" 标签 的问题。更有经验的贡献者非常欢迎处理 任何此类问题。
对于权重为 2 或更高且范围明确的功能，我们建议查看带有 标签 ~"Community Challenge" 的问题。如果您对 ~"Community Challenge" 问题的合并请求被合并，您还有机会赢得定制的 GitLab 商品。
如果您决定要处理某个问题，请尽快 @-mention 合适的产品经理。产品经理将邀请相关的 GitLab 团队成员进一步讨论范围、设计和技术考虑。这将确保您的贡献与 GitLab 产品保持一致，并最小化返工和合并到主分支的延迟。
应用 ~"Seeking community contributions" 标签的 GitLab 团队成员应更新问题描述，注明负责的产品经理，邀请任何潜在社区贡献者按上述方式 @-mention。
管理标签
对于与 GitLab 开源管理相关的问题，有 ~"stewardship" 标签。
此标签用于讨论 GitLab 管理的问题。例如，如果 GitLab Inc. 计划将 GitLab EE 的功能添加到 GitLab CE，相关问题将被标记为 ~"stewardship"。
最近的例子是 将时间跟踪 API 引入 GitLab CE 的问题。
技术债务和延迟的 UX
为跟踪 GitLab 代码库中可改进的内容，我们在 GitLab 问题跟踪器 中使用 ~"technical debt" 标签。当我们选择偏离 MVC 且损害用户体验时，使用 ~"Deferred UX" 标签。
这些标签应添加到描述可改进内容、已采取的捷径、需要额外关注的功能，以及因开发速度过快而遗留的所有其他问题中。例如，需要重构的代码应使用 ~"technical debt" 标签，未按设计系统指南发布的内容应使用 ~"Deferred UX" 标签。
任何人都可以创建问题，但如果您无权自行添加特定标签，可能需要请求他人添加。可以结合其他标签使用这些标签，以便更容易安排改进的发布。
标记这些标签的问题与描述 GitLab 新功能的问题具有相同优先级，应由合适的人员安排到发布中。
确保在问题描述中提及与 ~"technical debt" 或 ~"Deferred UX" 问题关联的合并请求。