Issue Manager は、特定のアクションが実行されたときに問題の状態が変化した理由を説明する、省略可能でカスタマイズ可能なキーワードです。
異なるアクションによって問題が同じ状態に移動する場合があります。 たとえば、問題が完了するには、再現不能、重複、非バグなどさまざまな理由があります。 理由コードによって追加情報が提供されないと、ユーザーは問題のライフ サイクルを完全に把握できません。
理由コードは、ワークフローの状態数をできる限り少なくするのにも役立ちます。 たとえば、複数の最終状態 (非バグ、再現不能、重複) を定義する代わりに、対応完了 という名前の最終状態を 1 つ用意して、問題が完了した理由を示すさまざまな理由コードと組み合わせれば十分です (たとえば、対応完了/非バグ)。
理由コードは、問題の詳細 ページおよびアクション ダイアログに表示されます。 たとえば、テクニカル ライターの Judy が、ドキュメントの問題を自分の受信箱で受け取ったとします。 説明を読んだ彼女は、問題が既に報告されていたことを思い出します。 そして、その問題に重複の印を付けます。 重複として指定 ダイアログ ボックスを開くと、問題が 対応中ドキュメント から 対応完了/重複 に移動していることがわかります。 対応完了 が新しい状態で、重複 は理由コードです。
特定のアクションが実行されると、Issue Manager は理由コードをそのアクションに割り当てて、問題を新しい状態に渡します。 それ以降のアクションでは、その理由コードをクリアするか、または単にその理由コードを維持します。 一般に、いったん設定された理由コードは、ワークフローの最終状態に達するまで問題と共に移動します。
開発者がバグを解決した後に、解決 アクションを実行してバグが解決されたことを主張する場合について考えます。 このアクションにより、バグは 開発準備完了 から QA 準備完了 に移動し、理由コードには 解決 が設定されます。 開発者の主張を検証する QA エンジニアは、検証 アクションを実行してバグ修正を承認します。 このアクションにより 解決 理由コードは維持され、バグと共に 対応完了 状態に移動します。
ただし、たとえば問題が最終状態に向かって先に進むのではなくワークフローの前の状態に戻るような場合は、理由コードをクリアできます。 たとえば、QA エンジニアが開発者の主張に異議を唱えて 却下 アクションを実行すると、問題は 開発準備完了 状態に差し戻されます。 解決 理由コードは意味がなくなるので、却下 アクションに対しては理由コードをクリアできます。
理由コードが、割り当てられるか、クリアされるか、維持されるかは、状態 "<状態名>" のアクションの新規作成 ダイアログの設定で決まります。 このダイアログについては、「理由コード」で説明します。 状態 "<状態名>" のアクションの新規作成 ダイアログ ボックスを表示するには、 をクリックしてから アクションの追加 をクリックします。