在一个特定的项目中，我们正在与10位团队成员合作。

经过大约一年的项目工作(并使用Mantis作为错误/功能跟踪器)，错误跟踪器变得越来越难以使用，因为尚未建立解释如何创建新任务，如何注释的标准任务等。这会导致多个条目输入相同的错误，无法在搜索错误时轻松找到错误等。

我们如何组织Bugtracker？我们是否对应用程序的不同部分(GUI，后端等)使用了很多(子)类别，是否在任务标题中使用了标签(即" [GUI] [OptionPage]错误")？

团队中的任何人都可以引入新任务吗？或者通过一个"螳螂大师"(然后他会知道新报告是重复的报告还是全新的条目)引导了这一步骤？

解决方案

始终将版本控制系统的提交链接到问题，然后再链接回去，这样我们就知道做出了哪些提交可以解决哪个问题以及为什么要执行某个提交。

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

如果不将角色分配给(核心)团队中的人员，则对于一般理解会更好。

在开放式网络上的"大型"螳螂系统中，我看到规则像

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

致谢：少数人可以将其升级到此级别。这些人已经看到每一个新错误了一段时间，因此他们会知道它是否重复。或者，他们可以将其传递给报告者进行澄清，直到他们对它足够了解以完成此工作为止。

确认：由决策者确定，他们基本上说"我们将这样做"。

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