trac - trac のカスタマイズ可能なチケット ワークフローの不変条件

Question

Trac の (0.12) カスタマイズ可能なチケット ワークフローのドキュメントを調べてみました。

著者は、完全にカスタマイズ可能であると主張していますが、私には理解できないことがあります。チケットが始まる「初期状態」があるはずです。これは「新規」としてハードコードされていますか?

Answer 1

私が思い出したように、これは trac では変更できません。ワークフローへの「新規」状態のエントリ ポイントが修正されました。しかし、それに反対するのではなく、協力することはできます。

trac の設計方法、割り当てられていない "New" 状態から開始するという意図はかなり論理的だと思いますが、常に明示的に述べられているとは限らない特定の観点から物事を見る必要があります。

バグのライフサイクルについて考えてみましょう。それがコードに導入され、ユーザーがそれを発見し、ユーザーがそれを報告し、開発者が割り当てられ、開発者が作業を開始する、などです。「新規」状態は、バグが存在し、報告されたばかりの部分と考えるのが好きです。

開発チームにバグを通知しても、通常、すぐに作業を開始することはありません。たとえば、バグの重大度と技術的な深さを評価する必要があります。バグを報告した後も、開発チームはレポートを消化して、バグ解決プロセスに導入する方法を知る必要があります。私の考えでは、これが trac の「新しい」状態の意図です。

私が設計して使用した trac ワークフローでは、「承認済み」の初期状態でチケットを開発コーディネーターに割り当て、チケットの資格を取得し、レポーターとやり取りしてレポートの品質を向上させ、問題を解決するのが好きでした。次に送信する場所、割り当てるマイルストーンなど。

したがって、Assigned 状態のチケットは、開発コーディネーターが取り組んでいるチケットです。New 状態のチケットは、開発コーディネーターがまだ処理していないチケットです。

Answer 2

「新規」だけでなく、「終了」もハードコードされた Trac チケットのステータスです。

これは以前も今もさまざまな理由でそうです。特に、これらのラベルは固定名の CSS クラスで条件付き書式を設定するために使用され、デフォルト レポートではオープン チケットの同義語として「非クローズ」が使用されます。

関連する注記として、この制限を将来のバージョン (Trac 1.2 以降) で解除する可能性があるいくつかの作業があります。JosefAssadが言ったように、それまでは「それに反対するよりも協力する」方が本当に良い.