Help us learn about your current experience with the documentation. Take the survey.

问题工作流

创建问题

在提交问题前，请先在问题跟踪器中搜索类似条目。 其他人可能已经遇到过相同的 bug 或功能建议。 如果你找到现有问题，请用表情符号反应表示支持，并在讨论中添加你的备注。

Bug 报告

要提交 bug：

不要为疑似安全漏洞创建公开可见的问题。

功能建议

要创建功能建议，请在问题跟踪器中使用 功能建议 - 详细问题模板打开一个问题。

为了帮助跟踪功能建议，我们使用 ~"type::feature" 标签。 非项目成员的用户无法通过 UI 添加标签。 请使用 响应式标签命令。

尽量保持功能建议简小精悍，复杂的功能建议可能会被编辑以使其更加简明。

对于用户界面（UI）的更改，请遵循我们的 设计和 UI 指南， 并包含视觉示例（截图、线框图或原型图）。这类问题应该 使用 响应式标签命令 添加 ~UX" 标签，以便产品设计团队提供输入和指导。

寻找可处理的问题

GitLab 有超过 75,000 个可供你处理的问题。 你可以使用 标签 来筛选和查找适合处理的问题。 新贡献者可以寻找带有 quick win 标签的 问题。

frontend 和 backend 标签也是细化问题列表的好选择。

明确/验证问题

许多问题最近没有被访问或验证。 在尝试解决问题之前，请执行以下步骤：

  • 询问作者该问题是否仍然相关。
  • 询问社区该问题是否仍然相关。
  • 尝试验证是否：
    • 是否已经创建了合并请求（请参阅相关合并请求部分）。 有时问题未被关闭/更新。
    • type::bug 是否仍然存在（通过重现它）。
    • type::feature 是否已经实现（通过尝试使用）。

处理问题

留下备注表明你希望处理该问题并希望被分配 （提及作者和/或 @gitlab-org/coaches）。

如果你遇到困难或没有正确理解问题，可以向作者或 社区寻求帮助。

问题分类

我们的问题分类政策在 手册中有描述。 我们非常欢迎你帮助 GitLab 团队进行问题分类。

最重要的是确保有效的问题能收到开发团队的反馈。 因此，优先提及能够帮助解决这些问题的开发者。 从 GitLab 团队 中选择具有相关经验的人。 如果没有提到具有该专业知识的人，请查看受影响文件的提交历史以找到合适的人。

我们也有分类自动化，在 手册中有描述。

有关应将哪些标签应用于问题的信息，请参阅 标签。

问题权重

问题权重让我们能够了解解决一个或多个问题所需的工作量。 这使得更准确地安排工作成为可能。

我们鼓励你为任何问题设置权重。遵循以下指南将有助于轻松管理， 而不会带来不必要的开销。

  1. 尽早为任何问题设置权重
  2. 如果你不认同已设置的权重，与其他开发者讨论直到 就权重达成共识
  3. 问题权重是对问题复杂性的抽象度量。不要 将问题权重直接与时间关联。这被称为 锚定效应， 是你需要避免的。
  4. 权重为 1（或无权重）的问题非常小且简单。 权重为 9 的问题则是重写 GitLab 的重要部分， 可能会导致许多难以解决的问题。更改 GitLab 中的一些文本 可能是 1，添加新的 Git Hook 可能是 4 或 5，大型功能是 7-9。
  5. 如果某个问题非常大，应该将其拆分为多个 问题或块。你不能为父问题设置权重， 然后为子问题设置权重。

回归问题

每个月的发布在 CE 问题跟踪器上都有一个相应的问题，用于跟踪 该发布破坏的功能以及需要包含在补丁发布中的任何修复 （请参阅 8.3 回归问题 作为示例）。

如问题描述中所述，预期的工作流程是发布一条备注， 引用描述回归的问题，然后在修复它的合并请求可用时 更新该备注引用。

如果你是没有更新其他用户备注所需权限的贡献者， 请发布一条新备注，同时引用问题 和合并请求。

发布经理将在修复问题时 更新备注。

后续问题中的技术债务

在开发新功能时发现技术债务是很常见的。本着"最小可行变更"的精神， 解决方案通常会被推迟到后续问题中。然而，这不能作为合并 本不会通过审查的低质量代码的借口，或者忽视那些不值得独立安排， 最好在原始合并请求中解决的问题——或者根本不跟踪！

安排的开销以及 GitLab 代码库的变更率意味着， 琐碎的技术债务问题的成本可能会很快超过跟踪它的价值。 这通常意味着我们应该在原始合并请求中解决这些问题—— 或者根本不创建后续问题。

例如，在文件间复制的注释中的拼写错误值得在同一个 MR 中修复， 但不值得为此创建后续问题。重用一个在多处使用的方法以使其意图 稍微清晰可能值得修复，但这不应该在同一个 MR 中进行， 并且通常不值得为其创建单独问题的开销。如果我们创建这些问题， 它们将被标记为 ~P4 ~S4。

更严重的技术债务可能影响开发速度。如果 不能及时解决，代码库会变得不必要地难以更改， 新功能变得难以添加，回归问题层出不穷。

这类技术债务的发现应被认真对待，虽然 在后续问题中解决可能是合适的，但维护者通常应该 从原始 MR 的作者或相关领域的工程或产品经理那里获得调度承诺。 这可能表现为在问题上设置适当的优先级/严重性标签， 或明确指定里程碑和负责人。

在以这种方式解决未解决的讨论之前，维护者必须始终同意， 并且将是创建问题的人。标题和描述的质量应与 通常方式 创建的问题相同—— 特别是，问题标题绝对不能以 Follow-up 开头！ 创建问题的维护者还应期望在后续问题的工作开始时 以某种方式参与其中。