鯖缶 » 人生管理運用

無効化といっても実態としてはワークフローのチェックボックスをﾎﾟﾁﾎﾟﾁすることになるので、一時的に無効化したり簡単に復旧させたりといったことがしづらい。
もし万が一にも他人のアカウントをこのサーバに作るようなことがあるなら、ワークフローから消すべきではない。

custom CSS か custom script 何かでどうにかできるかもしれないので、それも選択肢。

参考までに、デフォルトの状態だとロール「報告者」がステータス「解決」から「フィードバック」と「終了」へと遷移させられるようになっている。
逆に「フィードバック」からは「解決」へ戻せず、「終了」への変更しかできない (「終了」への変更は「却下」以外の任意の状態から可能。)

これを見た限りでは、「フィードバック」は「報告者によるフィードバック中」であることを意味しており、ゆえに「開発者による解決策の適用が完了した」を意味する「解決」から報告者が変更できるようになっているように読み取れる。
その場合、フィードバックを確認してステータスを「進行中」に戻したり「終了」にしたりするのは開発者の役目ということになる。

この辺りは人によって解釈が揺れそうなのでプロジェクトごとに自前で定義されるべきだと思うし、であれば削除してしまっていいか……

Bugzilla だが参考になりそうな情報があった。

• Re: Bugzilla RESOLVED vs CLOSED-Apache Mail Archives

簡単にまとめると以下のようになる。

• RESOLVED: 修正できて QA 待ち。ここから REOPENED になるか VERIFIED になるか CLOSED になりうる。
• VERIFIED: QA で問題なさそうと確認された。リリースされるまでこの状態。
• CLOSED: 修正が正しく、バグはもはや存在しなくなった。このチケットを動かすなら REOPEN する必要がある。

つまり「開発側での修正作業完了」「アクティブなコードベースでの作業完了」「市場でのバグの消滅」を区別しているということになる。

Redmine の resolved / feedback / closed も3段階だし、概ね似たような見方をして良いのではないかと思われる。
たとえば修正作業の完了が resolved、内部的に何らかの「確認」が済んだがユーザにとってはまだ終了していない状態が feedback、ユーザにとっても終了したといえる状態が closed といった具合である。
ただし、この捉え方だと "feedback" は起票したユーザによる feedback を要請していると捉えるべきで、リリースされた後に個別の確認によって閉じられるということになるため、この点で Bugzilla の VERIFIED→CLOSED の遷移とは条件が異なる。