機能 #113
未完了[Redmine] 常時遂行・バックグラウンドのタスクの管理 (2024-01)
0%
説明
一般的な “タスク” と異なり、 daemon のように日常に薄く広がって常時遂行している扱いになるべきチケットがいくらか存在するため、これらについて適した運用を考えたい。
たとえば基本的には放置できる設備・備品の運用のメタチケット (例として #96 等)、行動傾向の調整 (例として #61 等)、中長期目標 (例として #78) 等がある。
これらは扱いとしては確かに「進行中」ではあるものの、何らかの作業を必要としているわけではない場合が多いため、何か隔離する仕組みかカスタムフィールドを考える必要があるかもしれない。
あるいは、せめて作業を要求するタスクよりも目立たせない工夫はしたい。
たとえば優先度を最低にするなどは考えられる。
nop_thread さんが10ヶ月前に更新
- 題名 を [Redmine] 常時遂行・バックグラウンドのタスクの管理 から [Redmine] 常時遂行・バックグラウンドのタスクの管理 (2024-01) に変更
nop_thread さんが10ヶ月前に更新
機能 #112: [Redmine] 設備管理用トラッカーの検討 (2024-01) にも同じことが言えるが、そもそも Redmine のチケットステータスそのものについてのメタデータが「終了したチケット」フラグしか存在しないことが事を面倒にしている。
カスタムフィールドがステータスに全自動で連動して設定されてくれればそれでも良いのだが。
自分で書くしかないか？
nop_thread さんが9ヶ月前に更新 · 編集済み
行動傾向 #136: [今月の趣味] 2024-02 のようなチケットを 03-01 に更新しようとすると「2024/02/29 (1日 遅れ)」と表示されるのは、あまり体験が良くない。
そもそもこのチケットの「適用期間の終了」は 02-29 で、それ以前にチケットを閉じることは基本的に想定しない。
閉じるとしたら必ず適用期間の終了よりも後のはずである。
ところが Redmine 標準の「期限」の意味は、行動の完了期限、また行動完了に伴ってチケットを閉じるまでの期限といえる。
つまり期限よりも前に閉じるのが正常ということになる。
これらの2つの用法は性質が大いに異なるものであり、常時遂行やバックグラウンドの状態管理の終了予定日に「期限」フィールドを使うのはおそらく適切ではない。
「期日」フィールドを使うのをやめて、カスタムフィールドを作るか「確認予定日」 (#148) を流用するなど別の手を考える必要がありそう。
nop_thread さんが9ヶ月前に更新
- 優先度 を 通常 から 高め に変更
月1回まとめて提出する通勤費申請のためのチケット (#156, private) ではコメント機能を使って勤務実績のログを残すなどしており、これは前半が常時遂行タスク「ログ追加」で後半が作業タスク「申請記入と提出」になるというハイブリッドなパターン。
この場合チケットを分割するかは悩ましいところだが、いずれにせよ常時遂行・バックグラウンドのタスクは実用したくなる概念であることがわかったので真面目に考えることにする。
個人的には分割するほどのことではなく単一のチケットで済ませば良いと思うが、そうなるとワークフローをしっかり考える必要がある。
「バックグラウンド」トラッカーのようなものを用意してしまうのは必ずしも適当とは限らないということである。
(トラッカーを途中で変更することをワークフローに組み込むのは流石に暴挙が過ぎると思う。)
nop_thread さんが約1ヶ月前に更新 · 編集済み
サブスクリプションやインフラ等も類似の「有効な間存続」系のチケットで管理できそう。
nop_thread さんが約1ヶ月前に更新
- 前回確認日 を 2024/10/15 にセット
nop_thread さんは #note-11 で書きました:
サブスクリプションやインフラ等も類似の「有効な間存続」系のチケットで管理できそう。
バグ #529: [Redmine] 設備・備品管理の方法を再検討 (2024-10) の description で記述したが、そもそも Redmine のチケットや関連の概念は状況追跡と相性が悪い可能性がある。
ひとまず範囲を限定して設備と備品について #529 で検討するが、おそらくその結果をこのチケット (113) にも反映することになりそう。