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