GitHub 元数据建议

为了在 Mozilla Central、Bugzilla 和 GitHub 之间实现代码和任务跟踪的一致性，我们请求您在项目中使用一组通用的标签。改进我们约定的一致性带来的好处包括

  • 一致性使整个组织内流程的度量更加简单

  • 一致性使编写可重用流程工具变得更容易

  • 一致性提高了需要跨不同存储库和 Bug 追踪器工作的用户的清晰度

  • 一致性减少了项目之间工程流动性的摩擦

我们建议您在项目中创建一组标签来实现此目的。

Bug 类型

在 Bugzilla 中，Bug 通过类型进行区分：defect、enhancement 和 tasks。使用标签在您的项目中进行此区分。

状态

GitHub 问题中的 Bug 具有两种状态：关闭和打开。Bugzilla 具有更丰富的状态集。

关闭 Bug 时，添加一个标签指示解决方案。

  • 已修复 (fixed)

    • Bug 的更改集已合并到 Mozilla-Central 中。

    • GitHub 问题可能已关闭，但更改集尚未合并，因此从 Bugzilla 的角度来看它仍被视为打开状态。

  • 无效 (invalid)

    • 描述的问题不是 Bug。

  • 不完整 (incomplete)

    • 问题描述模糊，没有可重现步骤，或者是一个支持请求。

  • 不会修复 (wontfix)

    • 描述的问题是一个永远不会修复的 Bug。

  • 重复 (duplicate)

    • 问题是现有 Bug 的重复。请务必链接此重复的 Bug。

  • 对我来说没问题 (worksforme)

    • 所有重现此 Bug 的尝试都失败了，并且阅读代码也无法找到导致描述行为的原因。

严重程度 (必填)

Bugzilla 中 Firefox Bug 的分类流程需要 Bug 的严重程度 (定义)具有非默认值。

发布状态标志

打开的 Firefox Bug 也可能具有状态标志（status_firefoxNN）设置为 Nightly、Beta、Release 或 ESR。

优先级

Bugzilla 中的 Firefox 项目可以使用优先级字段来指示何时处理 Bug。

关键词

在 GitHub 问题中，元数据要么是标签，要么是 Bug 的打开/关闭状态。

一些 Bugzilla 元数据表现得像标签，但您需要小心使用它，以免混淆 QA。

回归

在 Bugzilla 中，regression 关键词表示代码更改引入的现有行为的回归。

当 Bug 在 GitHub 中被标记为回归时，它是否意味着回归发生在 GitHub 中的代码模块中，还是已合并到 Mozilla Central 的模块中？使用标签 regression-internal 将向 QA 发出信号，表明回归在您的开发周期内部，而不是引入到 Mozilla Central 树中。

如果不清楚哪个拉取请求导致了回归，请添加 regressionwindow-wanted 标签。

其他关键词

其他有用的标签包括 enhancement 用于区分功能请求，以及 good first issue 用于向贡献者发出信号（以及足够的文档）。

摘要

要表示 Bugzilla 字段，请使用以下方案的标签。

  • Bug 类型

    • defect、enhancement、task

  • 解决方案状态

    • invalid、duplicate、incomplete、worksforme、wontfix

  • 回归

    • regression、regressionwindow-wanted、regression-internal

  • 严重程度（必填）

    • S1、S2、S3、S4、N/A（保留给类型为 task 或 enhancement 的 Bug）

  • 状态标志

    • status_firefoxNN:<status>（例如 status_firefox77:affected）

  • 优先级

    • P1、P2、P3、P5

  • 其他关键词

    • good first bug、perf 等。

您可能已经有一组标签，因此请进行编辑以转换它们或使用GitHub 设置应用程序。