第352期：Bug 追踪系统的正确样子

上周的话题是 GitHub Issues，把它当作笔记工具，很强悍。但是，有些话来不及说。它的本职工作——Bug 追踪系统——并不好用。你用它来管理 Bug，就会发现有设计缺陷，用起来不顺手。现在还活着的、历史最悠久的 Bug 追踪系统是 Bugzilla。它的一个早期工程师，前不久写了一篇文章，介绍 Bugzilla 的四条设计原则。

他说，只有满足这四点，才是一个好的 Bug 追踪系统（bug tracking system），我感到很有启发。（1）所有任务都要列入 Bug 追踪。不仅包括代码 Bug，还包括待开发的新功能、缺失的文档、令人困惑的用户体验、糟糕的性能等等。换言之，Bug 追踪系统本质是任务管理，应该当作项目管理系统来用。（2）Bug 的状态有多种，不只“打开”和“关闭”两种。

大公司的 Bug 处理流程，可能很复杂，下面是一张从 Bugzilla 文档拷贝的流程图。Bug 追踪系统应该足够灵活，可以自定义优先级、严重程度、是否已分配、是否有依赖等等，以便适配各种流程。（3）每个 Bug 只能由一人负责。这样才能明确责任，方便查看每个人正在做什么、接下来要做什么、以及最近做了什么。这也有利于培养开发者的归属感和成就感。（4）支持自定义视图。

由于 Bug 有多种状态，追踪系统必须支持自定义视图查看，拥有强大的查询功能。系统的默认视图：按照优先级，列出当前版本的所有没有关闭的 Bug。开发者的个人视图：列出分配给他们的所有 Bug，同样按优先级排序。另外，用户可以保存自己的自定义视图。以上四条，就是好的 Bug 追踪系统的标准。问题是 GitHub Issues 一条都没做到。1. 项目管理功能太弱。1. 状态只能靠标签。1. 任务可以分配给多个人。

1. 视图默认按创建时间排序，且只能切换成标签视图。在这方面，GitHub 甚至不如 Gitea。举例来说，GitHub 没有办法让最重要的 Bug（P0 级别），自动出现在第一位（下图），除非手动置顶。相比之下，Gitea（包括分叉的 Forgejo）提供了“标签集”（label set），允许一个标签有多个值，并可以按同一个标签的值排序。

上图中，标签“Priority”（优先级）有多个值，然后系统允许按照 Priority 的值排序。