Bugzilla 问题分类

预期

所有使用 Mozilla-central 和/或 Bugzilla 开发 Firefox 的团队都应遵循以下流程。

组件

您应该了解您的团队负责的组件列表。每个组件都必须有一个问题分类负责人。（提交 Bug 来更新组件的问题分类负责人，或查看此表单以设置问题分类轮换）。

问题分类负责人

问题分类负责人负责确保在预期时间范围内对 Bug 进行分类，以及作为与问题分类相关问题的首要联系人。虽然确保分类是他们的责任，但这并不一定意味着只有他们才能或应该执行分类。

一个好的起点是让团队中足够资深的人员在 Bug 提交时进行分类，将需要讨论的 Bug 保持未分类状态。然后安排每周的分类会议来讨论和分类所需的 Bug。

分类

新提交的 Bug 可能很严重，我们可能需要快速做出反应。投入时间告知我们 Bug 的用户希望感受到我们正在倾听。

  • 所有新的 Bug 应每天快速评估，以确保安全 Bug 可以快速处理。

  • 所有新的 Bug 应在创建后一周内完成分类或处于积极调查中。

重要 Bug 的监控和修复

Bug 严重程度是有原因的。跟踪的 Bug 也必须特别认真对待。回归问题对用户来说很重要，功能回归表明产品正在变得更糟而不是更好。理想情况下，它们永远不应该出现在正式版中，而应该在测试版中修复。

  • 所有新的 S1 和 sec-critical Bug 应获得任何能够合理提供帮助的人的充分关注

  • 所有新的 S2 和 sec-high Bug 应被分配（有保留意见）并密切监控（每周团队会议）

  • 跟踪的 Bug 应密切监控（每周团队会议）

  • 回归问题应密切监控（每周团队会议）

所有这些都可以在 https://bugdash.moz.tools/ 的“重要”选项卡中找到（选择您的组件后）。

*::通用组件

我们不能期望用户了解我们的组件结构的详细信息，因此我们可能需要帮助将 Bug 路由到正确的位置。

  • 一些团队拥有 *::通用组件。这些组件中的新 Bug 应在一周内分类到更具体的组件中（除非我们正在积极收集信息以决定它属于哪里）。另请注意，有时元 Bug 没有更好的组件，在这种情况下，*::通用是一个合适的长期归属。

  • （Core::General 有自己的 问题分类负责人轮换定义）

积压工作

积压工作是所有软件项目的一个特点，我们永远无法达到零 Bug。但是，鉴于我们已经相当庞大的积压工作，我们至少应该确保我们的积压工作不会变得更糟。我们在 https://bugdash.moz.tools/ 上有一些工具来跟踪这一点。它有一个“概述”选项卡，显示维护趋势。理想情况下，在过去 12 周内，“维护效果”（即 维护效率）应超过 100%，并且“燃尽”（即达到零 Bug 的时间）不应为“∞”。

什么是已分类 Bug

已分类的新定义将是类型为 defect 且组件不为 UNTRIAGED 的 Firefox 相关 Bug，以及 严重程度 值不等于 -- 或 N/A。

类型为任务或增强功能的 Bug 可能具有 N/A 的严重程度，但缺陷必须具有既不为 -- 也不为 N/A 的严重程度。

为什么要分类

我们希望确保我们查看了每个缺陷并定义了严重程度。这样，我们确保在开发和稳定周期中没有错过任何关键问题。

掌握组件中的 Bug 意味着

  • 您可以提前发现关键的回归和崩溃，这些问题如果未被发现可能会触发点发布

    • 并且您不希望在假期与发布管理团队一起度过（并不是说他们不喜欢你）

  • 您的 Bug 队列不会不堪重负

    • 您的团队成员不会看到 Bug 队列并感到沮丧

谁来分类

工程经理和总监负责指定负责对组件中 所有类型的 Bug 进行分类的人员。

我们使用 Bugzilla 来管理此操作。请参阅 问题分类负责人列表。

如果您需要更改谁负责对组件中的 Bug 进行分类，请 对 bugzilla.mozilla.org 中的管理组件提交 Bug。创建新组件时，**必须**指定问题分类负责人。

轮换分类

某些组件由分类人员轮换监控。在这些情况下，Bugzilla 上的问题分类负责人将自动更新以反映轮换中的人员。轮换以日历的形式管理。

如果您希望为一个或多个组件设置轮换分类，请在 问题分类轮换电子表格 中添加指向您的轮换日历的链接。

Firefox::General 和 Toolkit::General

Firefox::General 中的 Bug 使用 Bug Bug 的模型来查看是否有其他组件具有很高的匹配可能性，如果达到阈值置信度，则将 Bug 移动到该组件。

社区成员也会审查此组件中的 Bug 并尝试移动它们。

你分类什么

作为问题分类负责人，您应该为您的组件关注以下查询

  • 所有开放的 Bug，在您的组件中，没有挂起的 needinfo 标志，并且没有设置有效的严重程度值

  • 所有在您的组件中具有活动审查请求且五天内未修改的 Bug

  • 所有在您的组件中具有已审查但未合并的补丁的 Bug

  • 所有未回复超过 10 天的 needinfo 请求的 Bug

有一个工具包含这些查询，可以帮助您查找 Bug https://bugdash.moz.tools/，源代码位于 https://github.com/mozilla/bugdash/。

如果 Bug 是增强功能，则需要设置优先级和目标发布或程序里程碑。这些 Bug 通常由产品经理审查。增强功能可能导致发布说明和 QA 需要我们了解的信息

如果 Bug 是导致更改集的任务，则发布经理需要知道这项工作何时完成。重构脆弱代码等任务可能存在风险。

每周或更频繁地（取决于组件）查找您分类的组件中的未分类 Bug。

确定每个未分类 Bug 的 严重程度（您可以覆盖已设置的内容）。

这些 Bug 在每周的回归问题分类会议中进行审查

  • 类型为 defect 且带有 regression 关键字但没有 status-firefoxNN 决策的 Bug

  • 类型为 defect 且带有 regression 关键字但没有回归范围的 Bug

自动 Bug 更新

当 Bug 被跟踪到某个版本时，即 tracking_firefoxNN 标志设置为 + 或 blocking，问题分类决策将被覆盖或如下进行

  • 如果 Bug 被跟踪到测试版、正式版或 ESR 或阻止它们发布，则其优先级将设置为 P1

  • 如果 Bug 被跟踪到 nightly 或阻止它发布，则其优先级将设置为 P2

由于 Bug 的优先级可能会被提升，因此问题分类负责人必须经常查看其 P1 和 P2 Bug。

假设

如果 Bug 在 Firefox 版本 N 中的发布状态为 affected 或 wontfix，其严重程度为 S3 或 S4，其优先级为 P3 或更低（积压工作），则如果 Bug 仍然处于打开状态，则它在 Firefox 版本 N+1 中的发布状态被认为是 wontfix。

问题和特殊情况

此 Bug 是功能请求

将 Bug 的类型设置为 enhancement，如果相关，则添加 feature 关键字，并将状态设置为 NEW。将 Bug 的严重程度设置为 N/A。此 Bug 将从未来的分类查询中排除。

此 Bug 是任务，而不是缺陷

将 Bug 的类型设置为 task，并将状态设置为 NEW。将 Bug 的严重程度设置为 N/A。此 Bug 将从未来的分类查询中排除。

如果您不确定 Bug 的类型，请查看 我们关于 Bug 类型的规则。

此 Bug 的状态为 UNCONFIRMED

是否存在复现步骤？如果没有，则需要向提交 Bug 的人员索取复现步骤。你没有义务无限期等待回复，对于信息请求未得到答复的 Bug 可以被 RESOLVED 为 INCOMPLETE。

我需要帮助复现 Bug

为 QA 经理、Softvision 项目经理或 Bug 所属组件的 QA 负责人设置 needinfo。

我没有足够的信息来做出决定

如果你没有复现步骤或确认信息，或者对如何继续有疑问，请 needinfo 提交 Bug 的人员或可以回答问题的人。

“stalled” 关键词

信息不足的极端情况是无法通过 needinfo 请求解决的情况。报告人已分享了他们所知道的所有关于 Bug 的信息，我们已经用尽了所有可用的解决策略，但 Bug 应该保持开放状态。

通过向 Bug 添加 stalled 关键词将其标记为已暂停。该关键词会将其从需要进行分类的 Bug 列表中移除。

如果一个补丁应用于一个 stalled 的 Bug，自动化系统会移除该关键词。否则，当 keyword 被移除时，Bug 的优先级将重置为 --，并且自动化系统会通知组件分类负责人。

应定期审查长时间处于 stalled 状态的 Bug，并在必要时关闭它们。

Bug 所属组件错误

如果 Bug 的严重程度为 S3、S4 或 N/A，请将其移动到您认为正确的组件，或 needinfo 负责该组件的人员并询问他们。

如果 Bug 的严重程度为 S1 或 S2，则通知发布管理团队并联系您认为其所属组件的分类负责人。我们不能因为 Bug 位于错误的组件而忽略高严重性 Bug。

我的项目在 GitHub 上

我们在进行分类时遵循了 GitHub 项目指南。（注意：本指南需要更新。）

摘要

每周多次

使用 https://github.com/mozilla/bugdash/ 中您负责的组件的查询来查找需要分类的 Bug。

对于每个未分类的 Bug

  • 分配严重程度

  • **不要**将 defect 的严重程度分配为 N/A

您可以设置 Bug 的 优先级，但并非强制要求。

关注未解决的 needinfo 标记

不要让未解决的 needinfo 标记持续超过两周。

关闭未回复 needinfo 标记的小 Bug。

跟进 needinfo 标记请求。

BugDash 将帮助您找到这些标记。

迭代/发布周期结束

发布周期结束时，任何未关闭的 S1 或 S2 Bug 将需要由工程团队和发布管理团队进行审查。相关的政策即将发布。

可选

（Bug 优先级指南正在审查中。）

是否存在未关闭的 P1 Bug？重新审视其优先级，并将它们移动到待办事项列表 (P3) 或 P2。

是否存在应在下一个周期提升为 P1 的 P2 Bug？

是否存在您现在知道优先级较低的 P2 Bug？将其移动到 P3。

是否存在您现在知道无法处理的 P3 Bug？将其降级为 P5（将接受补丁）或将其解决为 WONTFIX。

获取帮助

  • 在 chat.mozilla.org 上的 #bug-handling 频道提问