代码之家 › 专栏 › 技术社区 › Grimtron

正确组织的bugtracker规则(Mantis等人)

mantis bug-tracking

3

Grimtron · 技术社区 · 16 年前

在一个特定的项目中,我们总共有10名团队成员。

在这个项目上工作了大约一年之后(从那以后一直使用Mantis作为bug-/featuretracker),bugtracker的使用变得越来越困难,因为没有一个标准来解释如何创建新的任务,如何注释任务等。这导致同一个bug有多个条目,在搜索它们时无法轻松地找到bug等。

你如何组织你的bugtracker?您是否在应用程序的不同部分(GUI、后端等)使用许多(子)类别,是否在任务标题中使用标记(即“[GUI][OptionPage]the error”)?

你的团队中是否允许任何人引入新的任务,或者这一步是通过一个“螳螂大师”来引导的(他会知道新报告是重复的还是全新的)?

3 回复 | 直到 16 年前

1

2

xmjx 16 年前

总是将版本控制系统的提交链接到某个问题,然后再链接回去,这样您就知道哪些提交可以解决哪个问题,以及为什么要执行某个提交。

2

1

Andreas Kraft Vinod Joshi 16 年前

我们所做的是为bug跟踪器引入一个角色来批准条目。这个角色可以由不同的人共享。这个过程要么是批准,要么是通过小编辑来批准,要么是通过要求进一步编辑或澄清而拒绝条目。

如果不把这个角色交给(核心)团队中的人,对大家的理解会更好。

3

1

MaHuJa 14 年前

在一个开放网络上的“大型”螳螂系统中,我看到了一些规则

新:任何人都可以输入bug。

承认:少数人可以升级到这个级别。这些人已经看到每一个新的bug一段时间了,因此他们会知道它是否是重复的。或者他们可以把它传给记者澄清,直到他们足够理解它来做这项工作。

确认:由基本上说“我们将要这样做”的决策者设定。

我不记得它在哪里,更重要的是 我不知道效果如何 .