鯖缶 » 人生管理運用

JAXA の報告書 (『CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント』) では、「プロジェクト分割の指針は Redmine を使用する組織の性格や考え方により異なると思われるが，」としつつ、以下のように列挙している。
(なお JSS2 は JAXA のスーパーコンピュータ。)

• セキュリティなどの理由により参加メンバーが異なるときは分割する．
• 参加メンバーは同じでもロールを変更する必要があるときは分割する．
• 業務範囲により，フィールドの要・不要が異なったり，更新頻度が大きく異なるときは分割する．
• Redmine の保守関連作業のプロジェクトは分割する．
  • 「これは前項の業務範囲とほぼ同じ要因だが，」
• 「カテゴリ」フィールドの選択肢を業務分野毎に分けて，選択・検索しやすくするときは分割する．

概ね、権限まわりで差が出るかメタデータの扱いに大きな差が出る箇所を切りどころと考えているようである。
また、「カテゴリ」フィールドの値の集合がグローバルではなくプロジェクト毎である点についてはおそらく重要で、これを重視しながら考えるのは良いアイデアなのではないかと思う。

以上のことを参考にすると、プロジェクト分割によって tracking issue の代替とするのは、参加メンバーや権限の割り当てが違う場合には適切と考えられるが、参加メンバーやタスクの性質に大差のない状況では過剰であるように思われる。

— #89#note-2

とはいえ個人で使うことを考えたとき、たとえば「hogehoge旅行」とか「hogehogeゲーム」のような単位でプロジェクトを作りたくなる気持ちがときどきある。
大雑把には以下のような基準が概ね満たされるときにプロジェクトを作りたくなる。

• クラスタ全体に、明確に判定できる終わりがある。期限が切られていたり、チケット全体が完了したのちに「おかわり」が来ることが基本的にない
  • 「おかわり」がクラスタとして来るようであれば別プロジェクトにすればいいし、散発的なら既存の汎用プロジェクトに突っ込めば良い
• チケット群のクラスタが割と独立しており、クラスタ外チケットとの関係が希薄
  • 単にクラスタ外チケットとの参照/被参照関係が少ないというだけでなく、時間方向も含めての話。文脈外から参照されることが少ない (つまり全てが終わった後に検索から除外されていても困りづらい) ことを含意する

日を跨ぐ外出 (#146) については、とりあえずプロジェクトを都度作ってみることにした。

旅行中、特にその工程における外出中は、旅行に無関係なチケットを参照する頻度は劇的に低くなる。
そうなると「進行中の旅行に関係するチケットだけを閲覧できる」というフィルタは非常に有用で使いやすいため、専用のプロジェクトがあると情報へのアクセスが楽になった。
もちろんカスタムフィールドやカテゴリ等で制御することも可能ではあるだろうが、アクティブな状態である時間範囲が限定されているという点で、プロジェクトによってチケットを囲い込むのは管理しやすさの面でも優れている。

「コンテンツ鑑賞」トラッカーのチケットを「趣味・娯楽」プロジェクトにぶちまけているのが気持ち悪かったため、サブプロジェクト「コンテンツ鑑賞」を作成してそちらに移動した。
結局親プロジェクトの「趣味・娯楽」のチケット一覧ではサプブロジェクト内のチケットも一緒に列挙されてしまうが、積みコンテンツ以外のチケットが分離されていることが後々利便性に貢献することもあるかもしれない。
もし分離するだけ無駄であることが判明すれば戻すかも。