機能 #148
未完了[Redmine] 「確認予定日」フィールドの試験運用 (2024-02)
0%
説明
#145#note-1 で考えていたこと。
一部のチケットは、 Redmine 外部での状況の変化を待つことになったり、特定の日付になるまで放置することになったりする。
このような場合にリマインダがないと再訪を忘れる可能性が高いので、システムで管理する必要がある。
かといって「期日」もこの用途で必ずしも適切とはいえない。
まず、子チケットから自動算出する設定のとき親チケットの「期日」が子チケットの「期日」のうち最も遅い日になってしまうが、確認日の用途であれば最も早い日になることが望ましい。
また、「期日」はチケットを resolve あるいは close する目標日として使いたくなることが想定されるため、「確認タスクの着手目標日」と混同はしたくない。
「開始日」も同様に、チケット全体の開始日 (履歴) あるいは開始目標日として使いたくなることが想定される。
これらの理由から、「確認予定日」フィールドを作成して試験的に運用し、有効性を評価する。
nop_thread さんが9ヶ月前に更新
#145#note-2 的には「確認予定日」は「状況」であって、「履歴」ではない。
つまり、このフィールドは都度更新されるか、あるいは将来の確認予定がないならば積極的に unset されるべきものである。
完了/終了したチケットであれば、このフィールドは (よほど変な用途でもなければ) 必ず空になっているはず。
nop_thread さんが9ヶ月前に更新
- 題名 を [Redmine] 「確認予定日」フィールドの試験運用 (2024-01) から [Redmine] 「確認予定日」フィールドの試験運用 (2024-02) に変更
nop_thread さんが9ヶ月前に更新
予定日というと期日よりも前倒しの許容度が低いように感じるので、命名については要検討。
「確認期日」とかでもいいが……あまりしっくりこない。
nop_thread さんが8ヶ月前に更新
- 確認予定日 を 2024/03/18 から 2024/06/07 に変更
今のところの感触としては、悪くないように思う。
4〜6月にかけてまた何かしらの手続などがいくつも生えてきそうなので、その辺りのラッシュを乗り切れるかどうか確認してみる。
nop_thread さんが6ヶ月前に更新
nop_thread さんは #note-6 で書きました:
予定日というと期日よりも前倒しの許容度が低いように感じるので、命名については要検討。
「確認期日」とかでもいいが……あまりしっくりこない。
そもそも「確認が意味を持つようになる/確認しようと思える最初の日」と「確認の期日」は真逆でしかも両方とも有用なので、別で作るべき気がしてきている。
単なる「期日」はチケットのクローズ期限なので「この日までに確認しておくべき」の意味で使うべきではなく、別のフィールドを用意する意味はある。
nop_thread さんが6ヶ月前に更新
Redmine のカスタムフィールドに「期間」型 (半開も可) みたいなものがあれば良いのだが、たぶんないよな?
日付2つの組で表現できるし。
validation を Custom Workflows プラグインにやらせれば問題ないか。
nop_thread さんが6ヶ月前に更新
#note-9 が気になりすぎて使えなくなってきた。やはり何か考えるべきか。
とはいえただでさえ日付フィールドが複数 (トラッカーとプロジェクト次第だが現時点では4つくらい) あるのにこれ以上増やすと操作しづらくなってくるので、日付×2で期間を表現するのではなく何か工夫がほしいところ。
nop_thread さんが3ヶ月前に更新
- 確認予定日 を 2024/06/29 から 2024/11/02 に変更
- 前回確認日 を 2024/05/28 から 2024/09/01 に変更
- 管理外残件あり を いいえ にセット
nop_thread さんが約1ヶ月前に更新
- 前回確認日 を 2024/09/01 から 2024/10/15 に変更
機能 #528: Redmine のチケットを bot にリマインドさせたい での要件とロジックを先に考えると、 Redmine 側でどうデータを持つべきか決められるかもしれない。