正确组织的 bugtracker 规则（Mantis 等人）答案

【问题标题】：Rules for properly organized bugtracker (Mantis et al)正确组织的 bugtracker 规则（Mantis 等人）
【发布时间】：2008-09-25 12:59:53
【问题描述】：

在一个特定项目中，我们总共与 10 名团队成员合作。

在项目上工作了大约一年后（并且一直使用 Mantis 作为错误/功能跟踪器），错误跟踪器变得越来越难以使用，因为没有设置标准来解释如何创建新任务，如何评论任务等。这会导致相同的错误出现多个条目，搜索时无法轻松找到错误等。

你如何组织你的 bugtracker？您是否对应用程序的不同部分（GUI、后端等）使用了很多（子）类别，是否在任务标题中使用标签（即“[GUI][OptionPage] 错误”）？

您的团队中是否允许任何人引入新任务，或者此步骤是否通过单个“Mantis-master”引导（然后谁会知道新报告是重复的还是全新的条目）？

【问题讨论】：

【解决方案1】：

始终将版本控制系统提交链接到问题并返回，以便您知道进行了哪些提交确实解决了哪个问题以及完成某个提交的原因。

【讨论】：

【解决方案2】：

我们所做的是将批准条目的角色引入错误跟踪器。这个角色可以由不同的人分担。该过程要么是批准，要么是通过小幅编辑批准，要么是拒绝条目并要求进一步编辑或澄清。

如果不将角色分配给在（核心）团队中工作的人，则更好地进行一般理解。

【讨论】：

【解决方案3】：

在开放网络上的“大型”螳螂系统中，我看到规则类似于

新：任何人都可以输入错误。

确认：少数人可以将其升级到此级别。这些人已经看到每个新错误一段时间了，因此他们会知道它是否是重复的。或者他们可以将其传回给记者进行澄清，直到他们充分理解以完成这项工作。

已确认：由基本上说“我们会这样做”的决策者设定。

我实际上不记得它在哪里，更重要的是 我不知道它的效果如何。

【讨论】：