特定のプロジェクトでは、合計 10 人のチーム メンバーと協力しています。
プロジェクトに約 1 年取り組んだ後 (それ以来、Mantis をバグ/機能トラッカーとして使用)、新しいタスクの作成方法、コメントの仕方を説明する標準が設定されていないため、バグトラッカーの使用はますます難しくなっています。これにより、同じバグに対して複数のエントリが作成されたり、検索時にバグを簡単に見つけることができなくなったりします。
バグトラッカーをどのように整理していますか? アプリケーションのさまざまな部分 (GUI、バックエンドなど) に多くの (サブ) カテゴリを使用していますか? タスクのタイトルにタグを使用していますか (つまり、「[GUI][OptionPage] エラー」)?
あなたのチームの誰かが新しいタスクを導入することを許可されていますか、それともこのステップは 1 人の「カマキリマスター」 (新しいレポートが重複しているかまったく新しいエントリであるかを知ることができる) を介して行われていますか?
どのコミットがどの問題を解決し、なぜ特定のコミットが行われたのかがわかるように、常にバージョン管理システムのコミットを課題にリンクしてください。
私たちが行ったことは、バグトラッカーへのエントリを承認するための役割を導入することです。この役割は、さまざまな人が共有できます。このプロセスは、承認するか、小さな編集で承認するか、さらに編集または明確化を要求してエントリを拒否するかのいずれかです。
（コア）チームで働く人々に役割が与えられていない場合は、一般的な理解のためにより良いです。
オープンウェブ上の「大規模な」カマキリシステムでは、ルールが次のようになるのを見てきました
新規: 誰でもバグを入力できます。
承認済み: このレベルにアップグレードできるのは、ごく一部のユーザーのみです。これらの人々は、しばらくの間すべての新しいバグを見てきたので、それが重複しているかどうかを知っています。または、この仕事を行うのに十分なほどよく理解できるまで、明確にするためにレポーターに戻すことができます。
確認済み: 基本的に「これを行います」と言う意思決定者によって設定されます。
どこにあったかは覚えていません。