在一个特定的项目中，我们总共与 10 名团队成员合作。
在项目上工作了大约一年之后（并且一直使用 Mantis 作为 bug-/feature-tracker），bugtracker 变得越来越难以使用，因为没有设置标准来解释如何创建新任务，如何评论任务等。这会导致相同错误的多个条目，在搜索错误时无法轻松找到错误等。
你如何组织你的 bugtracker？您是否对应用程序的不同部分（GUI、后端等）使用了很多（子）类别，是否在任务标题中使用标签（即“[GUI][OptionPage] 错误”）？
是否允许团队中的任何人引入新任务，或者此步骤是否通过单个“Mantis-master”引导（然后谁会知道新报告是重复的还是全新的条目）？
始终将版本控制系统提交链接到问题并返回，以便您知道进行了哪些提交确实解决了哪个问题以及完成某个提交的原因。
我们所做的是将批准条目的角色引入错误跟踪器。这个角色可以由不同的人分担。该过程要么是批准，要么是通过小幅编辑批准，要么是拒绝条目并要求进一步编辑或澄清。
如果该角色不授予在（核心）团队中工作的人员，则更好地进行一般理解。
在开放网络上的“大型”螳螂系统中，我看到规则类似于
新：任何人都可以输入错误。
已确认：少数人可以将其升级到此级别。这些人已经看到了每个新的错误一段时间，因此他们会知道它是否是重复的。或者他们可以将其传回给记者进行澄清，直到他们充分理解以完成这项工作。
确认：由基本上说“我们将这样做”的决策者设定。
我实际上不记得它在哪里，更重要的是我不知道它的效果如何。