规范组织缺陷跟踪器（如Mantis等）的规则

Question

3

在我们正在进行的一个项目中，我们一共有10个团队成员。大约一年时间里，我们一直使用Mantis作为缺陷/功能跟踪工具，但随着时间推移，这个缺陷跟踪器变得越来越难以使用，因为没有建立起任何标准来解释如何创建新任务，如何评论任务等。这导致同一缺陷出现多次，难以在搜索时轻松找到缺陷等问题。

你们是如何组织你们的缺陷跟踪器的呢？你们是否为应用程序的不同部分（GUI、后端等）使用了许多（子）类别？你们是否在任务标题中使用标签（例如“[GUI] [OptionPage] The error”）？

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

- Grimtron

3个回答

1

在一个“大型”的螳螂系统中，我看到的规则大致如下：

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

确认：只有少数几个人可以将其升级到此级别。这些人已经看过了每一个新的错误报告，因此他们会知道它是否是重复的。或者他们可以将其退回给报告人以进行澄清，直到他们足够理解并能够完成这项工作。

确认：由决策者设定，基本上是说“我们将要做这件事”。

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

- MaHuJa

1

我们所做的是为缺陷跟踪器引入一个批准条目的角色。这个角色可以由不同的人共享。流程要么是批准，要么是带有小编辑的批准，要么是拒绝并要求进一步编辑或澄清。

如果不将该角色授予（核心）团队成员，那么对于一般理解来说会更好。

- akr

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- xmjx · Accepted Answer

始终将版本控制系统提交与问题关联起来，以便您知道哪些提交解决了哪些问题，以及为什么进行某个特定的提交。