0

私たちのグループでは、Bugzillaの「議論が必要」という状態をモデル化する必要があります。

そのため、カスタムRESOLVED-議論されるステータスが導入されました。適切なグループの人々が、この種の「解決」ステータスを持つ問題を検索し、これらをオフラインで話し合います。

私の意見では、まだ議論の必要がある場合、バグ/機能は明らかに解決されないため、これは適切な方法ではありません。これは、バグの標準的なライフサイクルにも反映されます。解決されたバグのリストに「ディスカッションが必要」な項目が表示されるため、誤解を招く可能性があります。

バグのBugzillaライフサイクル

私が考えることができる1つの方法は、議論に関与しなければならないグループを表す一種の「仮想ユーザー」を作成することです。これには、バグを簡単に検索できるという利点があります。ユーザーに通知するためのメーリングリストを設定することもできます。

Bugzilla3.0.xのバグの議論状態を適切にモデル化するにはどうすればよいのでしょうか。（そして：Mozilla-wayソリューションとは何ですか？）

4

1 に答える 1

1

他のソフトウェア システムと同様に、さまざまな方法でニーズに対応できます。

メカニズムを始める前に、要件について考えておくとよいでしょう。

議論が必要なバグをまだ「未解決」としてカウントするか、それとも「解決済み」と見なしますか。そのような種類のメトリックも収集しますか?

あなたの質問から導き出される要件は

  1. 通常の検索では見たくない
  2. 明示的に見たときにそれらを見ることができるようにしたいですか
  3. 議論を終わらせ、「バグを元に戻す」ことができる必要がある
  4. 開催される議論があることを人々に通知したい
  5. バグが解決されたように見えないようにしたい

それらが本当に要件であり、「議論用」のバグがメトリックなどで解決済みとして表示されることを気にしない場合は、ポイント 5 を除いて、おそらく十分であると思います。

いくつかの他の選択肢

  1. 「ディスカッション」製品 (またはコンポーネント) を作成します。
  2. カスタム ライフサイクルを作成します (ただし、お勧めしません)。
  3. 「Discuss-me」グループ/ユーザーに割り当てます
  4. 「スーパー バグ」を使用し、バグに「ディスカッション スーパー バグ」をブロックするマークを付けます。
  5. 「この問題について議論する」バグを作成し、議論によってブロックされたバグとしてマークします (これは現実を最もよく反映していますが、最良の選択肢にはなりません)。

しかし、私が言ったように、まず何を達成しようとしているのかを考え、次にそれに基づいてメカニズムを選択してください。それらをすべて機能させるためにしなければならないバグいじりの量については、さまざまなトレードオフがあります:-)。

于 2012-09-13T04:30:07.713 に答える