GitHub の sub-issue を試してみる
GitHub Issues が入れ子にできるようになるらしいので試してみた。
Evolving GitHub Issues (Public Preview) - GitHub Changelog
https://github.blog/changelog/2024-10-01-evolving-github-issues-public-preview/
とりあえず Public Preview を申し込みしてすぐ使えるようになった気がする。
これまでも Tasklist をつかうことで入れ子っぽい感じだったり、まとめて Issue を管理するような事はできた。
sub-issue を作ってみる
issue を作るとこんな感じで sub-issue を作ることができる
Adding sub-issues - GitHub Docs
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues
新規で作るか、既存の物をぶら下げるか。
issue を連続で作成する
issue を連続で作りやすくもなった
入れ子も複数階層いける
これはありがたい。
親は1つのみ
入れ子はできるけど親にできるのは1つのみ。
Tasklist もこれまで通り使えそう
Tasklist と組み合わせても使えそうなので、そのあたりは使い分けでやっていくといいんだろうな。
ある issue があって、何かもっとやることがあったり、細分化して sub-issue を追加していくという流れになりそう。
親issueは子issueに依存している、と言う感じにはなるだろうから子issueが終われば、親へとあがって対応していく感じといったところか？
そうなったときに issue を見ていく流れ（上から下）と、進めていく流れ（下から上）が逆なのが気になったりしないだろうか、と書き始めて思った。
issue を複数の面から分類する
あと、issue をグルーピングしたいと思うときには、色々軸があるとは思っていて。
A,Bという要望があったとして。
- 検証
- 要件整理
- 実装
- テスト
- 確認
- ドキュメント
みたいなのがあるときに、
- 要望A
- 要望A：検証
- 要望A：要件整理
- 要望A：実装
- 要望A：テスト
- 要望A：確認
- 要望A：ドキュメント
- 要望B
- 要望B：検証
- 要望B：要件整理
- 要望B：実装
- 要望B：テスト
- 要望B：確認
- 要望B：ドキュメント
みたいな入れ子になることもあれば、
- 検証
- 検証：要望A
- 検証：要望B
- 要件整理
- 要件整理：要望A
- 要件整理：要望B
- 実装
- 以下略
- テスト
- 確認
- ドキュメント
見たいな入れ子になることもありそう。
何を優先した基準にするかは場合によるとは思うが、このような感じで issue にはいくつかの面から見ていく事がある気がしている。
複数の面からみたいのは状況把握という面が多いかもしれないが、ある切り口によっては担当する人が先を見通しやすい感じになっているとかもありそう。
Assign 自体は基本の属性としてあるからそれで事足りるだろうけど。
Tasklist で分類すれば色々と紐付けられるから、機能をだしつつ issue を関連づける感じがいいのだろうか。
若干登録するというのが手間かかりそうな気はするが。
粛々と issue を処理すれば状況が把握しやすくなるから良さそうな気がするなぁ。
粒度は様々だろうけど、最低限 issue をつくっておく。
その中に担当者がチェックボックスをつくってTodoを細分化したり、Tasklistで細分化したり、 sub-issue で細分化したりがしやすくなった。
色々な使い方ができるとある程度ルールも必要になったりしそうな気がする。
とりあえず GitHub のリポジトリを用意しておけば色々と使う事ができて便利だろうなぁ。
Discussion