機能 #118
完了[Redmine] チケットのステータスそのものに属性を追加したい (2024-01)
nop_thread さんが約1年前に追加. 12ヶ月前に更新.
0%
説明
機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) にも同じことが言えるが、そもそも Redmine のチケットステータスそのものについてのメタデータが「終了したチケット」フラグしか存在しないことが事を面倒にしている。
カスタムフィールドがステータスに全自動で連動して設定されてくれればそれでも良いのだが。
自分で書くしかないか？
チケットのステータス自体に属性を追加できれば、諸々の分類やフィルタリングが捗る。
nop_thread さんが約1年前に更新 · 編集済み
ステータスに従属するカスタムフィールド案:
- type: チケットの性質、あるいは必要とされる assignee の行動
- task: 特定の動作により状況を変化させたり結論を出したりするためのチケット。
- tracking: 状況の追跡が主目的で、特定の小さなタスクと寿命を一にするものではないチケット。
- background: task 相当ではなく、条件を満たしている間、常時遂行しているといえるチケット。
nop_thread さんが約1年前に更新 · 編集済み
使えそう。
→インストールした。使い勝手を試してみる。
nop_thread さんが約1年前に更新 · 編集済み
background かどうかはステータスというよりトラッカーに従属すると捉えるのが適切だろうか？
「新規」や終了系ステータスにまで諸々のカスタムフィールドが設定されてほしいか次第か。
トラッカーも後から増やしたりはするので、ステータスと同じくカスタムフィールドに反映してフィルタリングを間接的にする動機とメリットは十分にある。
nop_thread さんが約1年前に更新 · 編集済み
チケットの活性の管理も必要。
- ?:
- speculation: 検討段階。思索や計画を必要とする。
- → actionable の一種？ デフォルトのステータスセットからは区別が難しそうなので、自動化を考えると分けるべきでないかも
- actionable (default): assignee の行動を要求する。
- waiting for event: 状況の変化、他人の行動、時期の到来などを待っている状況。行動可能ではない。
- suspended: 一時中断中。
- 独立したフラグとして持つべきか、活性の一部にすべきか、悩ましい。独立ではないと思われるが (基本的に行動可能なタスクしか中断しないため)、自動化の阻害要因になりかねない。
- speculation: 検討段階。思索や計画を必要とする。
むしろこの分類こそがステータスの本質な気がしてきた。
一時停止状態用のステータスを各トラッカー用に作らないと駄目か？
しかし検討段階の一時中断と行動段階の一時中断を別々のステータスにするのも冗長が過ぎるように思われる。
検討と行動を分けるべきではないのかもしれないが…… (cf. #89#note-1)
nop_thread さんが約1年前に更新
- 題名 を [Redmine] チケットのステータスそのものに属性を追加したい から [Redmine] チケットのステータスそのものに属性を追加したい (2024-01) に変更
nop_thread さんが12ヶ月前に更新
nop_thread さんは #note-5 で書きました:
- ?:
- speculation: 検討段階。思索や計画を必要とする。
- → actionable の一種？ デフォルトのステータスセットからは区別が難しそうなので、自動化を考えると分けるべきでないかも
- actionable (default): assignee の行動を要求する。
- waiting for event: 状況の変化、他人の行動、時期の到来などを待っている状況。行動可能ではない。
- suspended: 一時中断中。
- 独立したフラグとして持つべきか、活性の一部にすべきか、悩ましい。独立ではないと思われるが (基本的に行動可能なタスクしか中断しないため)、自動化の阻害要因になりかねない。
結局現状だと以下のようになっている。
- speculation: 未実装
- actionable (default): 「進行中」ステータスで表現
- waiting for event: 「待機中」ステータスで表現
- suspended: 「一時中断」カスタムフィールド (boolean) で表現
検討や調査そのものもチケットの目的設定によっては本命のアクションでありうることを考えると、その適切な扱いについては実体験を参考に考えたいところ。
そうすると、それとは独立して残りの3つが表現できている現状はモデルの作りとしては悪くないといえそう。
nop_thread さんが12ヶ月前に更新
nop_thread さんは #note-1 で書きました:
ステータスに従属するカスタムフィールド案:
- type: チケットの性質、あるいは必要とされる assignee の行動
- task: 特定の動作により状況を変化させたり結論を出したりするためのチケット。
- tracking: 状況の追跡が主目的で、特定の小さなタスクと寿命を一にするものではないチケット。
- background: task 相当ではなく、条件を満たしている間、常時遂行しているといえるチケット。
現状での扱いは以下のとおり。
- task: デフォルトの状態の「機能」「バグ」チケット。
- tracking: 機能 #119: [Redmine] tracking issue (メタチケット) の扱い (2024-01)
- background: 機能 #111: [Redmine] 長期潜伏チケットの管理 (2024-01), 機能 #113: [Redmine] 常時遂行・バックグラウンドのタスクの管理 (2024-01)
いずれも未解決・試行段階ではあるが、単一のカスタムフィールドによって表現されるべきかというと、今のところそうすべきという考えにはなっていない。