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

发布于 2024-07-05 07:59:32 字数 316 浏览 7 评论 0原文

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

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

您如何组织您的错误跟踪器? 您是否在应用程序的不同部分(GUI、后端等)使用了很多(子)类别,您是否在任务标题中使用了标签(即“[GUI][OptionPage] 错误”)?

您团队中的任何人是否允许引入新任务,或者此步骤是否通过单个“螳螂大师”进行(然后谁会知道新报告是重复的还是全新的条目)?

On a particular project we're working with a total of 10 team members.

After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.

How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?

Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

弱骨蛰伏 2024-07-12 07:59:32

始终将版本控制系统提交链接到问题并返回,以便您知道进行了哪些提交,解决了哪个问题以及为什么进行某个提交。

Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.

木落 2024-07-12 07:59:32

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

如果不将该角色分配给(核心)团队中的人员,则更有利于总体理解。

What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.

It is better for the general understanding if the role is not given to people working in the (core) team.

转瞬即逝 2024-07-12 07:59:32

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

新规则:任何人都可以输入错误。

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

已确认:由决策者设定,他们基本上会说“我们将这样做”。

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

In a "large" mantis system on the open web, I've seen the rules go something like

New: Anyone can enter a bug.

Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.

Confirmed: Set by decision makers who basically say "We will be doing this".

I don't actually remember where it was, and more importantly I don't know how well it worked.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文