適當組織bugtracker的規則（Mantis et al）

Question

在一個特定的項目中，我們共有10名團隊成員。

經過大約一年的項目工作（並使用Mantis作爲錯誤/功能跟蹤器eversince），錯誤跟蹤器越來越難以使用，因爲沒有設置標準來解釋如何創建新任務，如何評論任務等。這導致多個條目相同的錯誤，搜索時無法輕鬆找到錯誤等。

如何組織你的錯誤跟蹤器？你是否在應用程序的不同部分使用了很多（子）類別（GUI，後端等），你在任務標題中使用了標籤（即「[GUI] [OptionPage]錯誤」）？

你的團隊中是否有人允許引入新任務，或者是通過單一的「Mantis-master」（誰知道新報告是重複還是全新條目）引導這一步？

Answer 1

始終將版本控制系統提交鏈接到一個問題並返回，以便您知道進行了哪些提交確實解決了哪個問題以及爲什麼執行了某個提交。

Answer 2

我們所做的是爲批准條目引入bug追蹤器。這個角色可以由不同的人共享。該流程要麼批准，要麼通過小的編輯來批准，要麼拒絕具有進一步編輯或澄清請求的條目。

如果沒有給在（核心）團隊中工作的人員提供角色，對於一般理解來說更好。

Answer 3

在開放的網絡上「大」螳螂系統，我見過的規則去像

新：任何人都可以進入的錯誤。

已確認：少數人可以將其升級至此級別。這些人已經看到了每一個新的bug，因此他們會知道它是否是重複的。或者他們可以將其傳回給記者澄清，直到他們理解這件事情爲止。

確認：由基本上說「我們會這樣做」的決策者設定。

我其實不記得它在哪裏，更重要的是我不知道它的工作效果如何。