sub-issueの一般公開に合わせて、GitHubのエンジニア Shaun Wong氏が階層的なissue構造をサポートするようになった経緯や、開発中に学んだ教訓、ワークフローにおいてsub-issueが果たした重要なロールについての知見をシェアした。
数ヶ月前にプレビュー版がローンチされたGitHub sub-issueは、開発者が親子階層を用いてタスクを整理できるようにするものである。この構造は複雑なタスクをより小さく、管理しやすいコンポーネントに分解するのに役立つ。さらに関連するアクティビティを階層形式でグループ化することで、チームはより効率的に進捗を追跡し、各サブタスクがプロジェクト全体にどのように貢献しているかを詳細に把握することができる。
例えば親となるissueを個別のサブタスクに分解し、それぞれを組織内の異なるチーム－マーケティング、UI/UX設計、バックエンド開発、フロントエンド開発などに割り当てることができる。
GitHubのエンジニアが最初に直面した決断は、既存のタスクリスト機能を修正するか、まったく新しい階層構造をデザインするかだった。彼らは最終的に後者を選んだが、そのためには基礎となるデータモデルとレンダリングロジックに大幅な変更を加える必要があった。
データモデリングの観点から、sub-issueテーブルが親と子のissue間の関係を保存します。例えばissue Xがissue Yの親である場合、sub-issueテーブルがこのリンクを保存し、階層的な関係が維持されるようにします。
重要な機能の1つはsub-issueリストテーブルを用いて、親issueの進捗をそのsub-issueに基づいて自動的に更新することである。これによりステータスを監視するために手動で階層をチェックしたり、ナビゲートしたりする必要がなくなった。
実装レベルではsub-issueはMySQLのリレーションシップを使ってモデル化され、効率的かつ柔軟なデータ取得を可能にするためにGraphQLエンドポイントを介して公開されている。
Wong氏によると複数のプロジェクトでsub-issueを社内利用した結果、プロジェクト管理の簡素化と迅速化に効果的であることが証明された。
我々のチームはsub-issueが大規模プロジェクトの管理能力を大幅に向上させることを発見しました。タスクを細分化し、実行可能な項目にすることで、作業の可視性とコントロールが向上しました。また階層構造により依存関係の特定が容易になり、見落としがなくなりました。
sub-issueと一緒にGitHubは他のプレビュー機能も一般公開した。これにはissueをバグ、機能、タスクなどに分類できるissueタイプ；andやorを使う複雑なクエリをサポートする高度な検索；GitHub Projectsのissue上限が増加し、現在は最大50,000 issueまでサポートされるようになったこと、が含まれる。