新しい状態リスト

名前
問題に対してこのアクションを取ったときの、ワークフローにおける次の状態の名前。 たとえば、デフォルト ワークフローでは、レビュー未完了 の問題は、バグとして確認されると、Issue Manager では 開発準備完了 という次の状態に移行します。
[理由コード]
このアクションを取ったときに問題が現在の状態から新しい状態に変化する理由を説明するキーワード (省略可能)。 該当するオプションを選択します。
[変更なし]
[変更なし] は、問題が新しい状態に移行してもキーワードがそのまま変わらないことを示します。 このキーワードは、問題の詳細ページの [理由コード] フィールドに表示されます。 たとえば、以下のワークフローでは、あるバグを修正したと開発者が主張すると、そのバグは解決という理由コードで QA 準備完了状態に移行することを示しています。 その主張が正しいことを QA エンジニアが確認すると、バグは解決という理由コードのまま対応完了状態に移行します。 問題を閲覧するユーザーは誰でも、理由コードを見ることで、バグの対応完了理由が簡単にわかります。
[クリア]
問題が新しい状態に移行するときに現在の状態の理由コードが削除されることを示します。 問題がワークフローにおける前の状態に戻るときは、[クリア] を選択するのが妥当です。 たとえば、バグを修正したと開発者が主張すると、バグは [解決] という理由コードで QA 準備完了 状態に移行します。 しかし、その "修正" が却下されると、問題は開発 (開発準備完了) 状態に差し戻されます。 また、主張に異議が唱えられたため、解決 という理由コードは削除されます。 クリア を選択すると、ワークフロー ページの 理由コード フィールドには クリア と表示されます。 ただし、問題の詳細 ページの 理由コード フィールドには何も表示されません。
設定

このアクションに理由コードを関連付けることができることを示します。 20 文字以内でキーワードを入力します。 英字の場合は、すべて大文字にすることをお勧めします。 アクションの結果、理由コードの必要な新しい状態に問題が移行する場合は、[設定] を使用して理由コードを指定します。 一般に、開発者が取るすべてのアクションには理由コードを割り当てなければなりません。

たとえば、デフォルト ワークフローでは、開発準備完了 状態で 解決 アクションを取ると、問題は 解決 という理由コードで QA 準備完了 状態に移行します。 人間行動の点から見ると、これは、バグを修正したと開発者が主張し、それを QA エンジニアに渡すと、QA エンジニアのほうでは、問題の詳細 ページをざっと見て、自分の受信箱にそのバグが入っている理由をたやすく知ることができるということです (他には、開発者がバグを修正できない、あるいはソフトウェアが設計どおりに動作しているという理由でその受信箱にバグが入っている場合もあるでしょう)。

理由コードを使用しない場合

理由コードは、ワークフローにおける状態の数をできるだけ少なくするのに役立つキーワード (省略可能) です。 たとえば、問題が 対応完了 状態になっている理由を説明するのに理由コードが役に立つので、複数の対応完了状態 (非バグ再現不能再現不能重複として指定) を定義しなくても、1 つの最終状態で十分です。 理由コードを使用しないことにした場合は、複数の最終状態を定義する必要があるかもしれません。 ある状態を最終状態にするには、状態のプロパティ ダイアログで、状態所有者 の選択肢として表示される 所有者なし (最終状態) ラジオ ボタンを選択します。