以下内容转载自：阮一峰 科技爱好者周刊（第 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 一条都没做到。
- 项目管理功能太弱。
- 状态只能靠标签。
- 任务可以分配给多个人。
- 视图默认按创建时间排序，且只能切换成标签视图。
在这方面，GitHub 甚至不如 Gitea。
举例来说，GitHub 没有办法让最重要的 Bug（P0 级别），自动出现在第一位（下图），除非手动置顶。
相比之下，Gitea（包括分叉的 Forgejo）提供了”标签集“（label set），允许一个标签有多个值，并可以按同一个标签的值排序。
上图中，标签”Priority”（优先级）有多个值，然后系统允许按照 Priority 的值排序。
留言