极狐 GitLab

标签

为了支持异步的议题处理，我们使用里程碑和标签。项目主管和产品经理负责将大部分工作安排到里程碑中。打标签是每个人的任务。（对于某些项目，只有极狐GitLab 团队成员可以设置标签，社区贡献者无法设置）。

大多数议题在适用情况下至少会有以下各类别中的一个标签：

  • 类型。例如：~"type::feature"、~"type::bug" 或 ~"type::maintenance"。
  • 版块。例如：~"section::dev" 或 ~"section::ai"。
  • 阶段。例如：~"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"。
  • 功能状态：~"Feature state::Experiment"、~"Feature state::Beta" 或 ~"Feature state::GA"
  • 部门。例如：~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" 标签。

如果议题与应用安全相关，请添加 ~security 标签。

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

如果你遇到一个没有任何这些标签的议题，并且你有权限设置标签，你总是可以添加类型、阶段、群组，以及通常的类别/功能标签。

类型标签#

类型标签非常重要。它们定义了议题的类型。每个议题都应该有一个且只有一个类型标签。

类型和子类型标签的 SSOT 可在手册中查阅。

许多类型标签都分配了优先级，这会使它们根据重要性自动置顶。

类型标签始终为小写，并且可以使用除蓝色（已预留给类别标签）外的任何颜色。

标签页面上的描述解释了每种类型标签所涵盖的内容。

极狐GitLab 手册中记录了什么是错误以及什么是功能请求。

阶段标签#

阶段标签指明了议题所属的阶段。

命名和颜色约定#

阶段标签遵循 devops::<stage_key> 命名约定。<stage_key> 是阶段的键值，与 https://jihulab.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://jihulab.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:: 标签来实现这一点。

类别标签#

来自手册的产品阶段、群组和类别页面：

类别是高层级的功能，在另一家公司可能就是独立的产品，例如组合管理。

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

如果你是某个领域的专家，这将使你更容易找到要处理的议题。你也可以订阅这些标签，以便每次有议题被标记上与你专业领域相对应的类别标签时收到电子邮件。

命名和颜色约定#

类别标签遵循 Category:<Category Name> 命名约定，颜色为 #428BCA。<Category Name> 是类别名称，与 https://jihulab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 中单一可信源的名称一致。

例如，“DevOps Reports” 类别在 gitlab-org 群组中由 ~"Category:DevOps Reports" 标签表示，因为其 devops_reports.name 值为 “DevOps Reports”。

如果类别的标签不遵循此命名约定，则应通过 https://jihulab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml 中的 label 属性进行指定。

功能标签#

来自手册的产品阶段、群组和类别页面：

功能：小的、离散的功能点，例如议题权重。一些常见功能会列在括号内，以便通过关键词找到对应的产品经理。

如果没有适用的类别标签，强烈建议添加功能标签，因为我们的分类自动化会利用它来推断正确的群组和阶段标签。

如果你是某个领域的专家，这将使你更容易找到要处理的议题。你也可以订阅这些标签，以便每次有议题被标记上与你专业领域相对应的功能标签时收到电子邮件。

功能标签的示例包括 ~wiki、~ldap、~api、~issues 和 ~"merge requests"。

命名和颜色约定#

功能标签全部为小写。

功能状态标签#

添加一个与发布时功能状态相匹配的功能状态标签。该标签应与工作项标题一致。虽然标题中的功能状态已经传达了目标状态，但标签对于筛选是必需的。

例如，你有一个希望在测试版中发布的功能史诗。该史诗的标题是 “Your Feature (Beta)”。添加 ~"Feature state::Beta" 标签以匹配。

对于已经正式发布的（GA 后）功能的工作项，不需要功能状态标签。

工作流标签#

议题使用以下工作流标签来标明当前的议题状态：

  • ~"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" 标签具有特殊含义。它指向的变更：

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

我们希望避免这样一种情况：贡献者选择了一个标记为 ~"Seeking community contributions" 的议题，然后他们的合并请求被关闭，因为我们意识到它不符合我们的愿景，或者我们想用不同的方式解决它。

我们会手动将 ~"Seeking community contributions" 标签添加到符合上述标准的议题上。我们不会自动添加此标签，因为这需要人工评估。

我们建议从未参与过任何开源项目的人优先查找标记了 ~"Seeking community contributions"、权重为 1 或带有 ~"quick win" 标签的议题。更资深的贡献者非常欢迎去解决其中任何一个。

对于权重为 2 或更高、范围明确的更复杂的功能，我们建议查看带有 ~"Community Challenge" 标签的议题。如果你针对 ~"Community Challenge" 议题的合并请求被合入，你还有机会赢得极狐GitLab 定制礼品。

如果你决定要解决某个议题，请尽快 @ 提及相应的产品经理。产品经理随后会引入合适的极狐GitLab 团队成员，以进一步讨论范围、设计和技术考量。这将确保你的贡献与极狐GitLab 产品保持一致，并最大限度地减少返工以及合入主干的延迟。

为议题添加 ~"Seeking community contributions" 标签的极狐GitLab 团队成员应在议题描述中更新一位负责的产品经理，并邀请任何潜在的社区贡献者按照上述方式 @ 提及。

管理标签#

对于与极狐GitLab 开源管理相关的议题，有一个 ~"stewardship" 标签。

此标签用于那些以极狐GitLab 管理为讨论主题的议题。例如，如果极狐GitLab Inc. 计划将功能从极狐GitLab 旗舰版引入极狐GitLab 基础版，相关议题将标记为 ~"stewardship"。

近期的一个例子是关于将时间追踪 API 引入极狐GitLab 基础版的议题。

技术债务和延迟用户体验#

为了追踪极狐GitLab 代码库中可以改进的事项，我们在极狐GitLab 议题跟踪器中使用 ~"technical debt" 标签。当我们选择偏离 MVC 并损害用户体验时，我们使用 ~"Deferred UX" 标签。

这些标签应添加到描述可改进之处、已采取的捷径、需要额外关注的功能以及所有因高速开发而被遗留事项的议题上。例如，需要重构的代码应使用 ~"technical debt" 标签，未按照我们设计系统指南发布的内容应使用 ~"Deferred UX" 标签。

每个人都可以创建议题，但如果你没有自己添加特定标签的权限，你可能需要请求帮助添加。可以将其他标签与这些标签组合使用，以便更容易地安排改进在某个发布中完成。

标记了这些标签的议题与描述在极狐GitLab 中引入新功能的议题具有相同的优先级，并应由相应人员安排到发布中。

请务必在 ~"technical debt" 议题或 ~"Deferred UX" 议题的描述中提及相关联的合并请求。