issueのステータス定義 - Snak0201/fpb-wwwsite GitHub Wiki

ほしのなか政府広報サイトの開発では、GitHub Projectを用いてIssueの管理を行っている。Project上のステータスはIssueの状態を表しており、どのように運用するかを記載する。

前提として、各Issueは次の項目を持つ。

1. 理由（不具合として何が起こっているか）
2. 詳細
3. 受け入れ条件
4. 優先度
5. Backlogステータス
6. 実装方針
7. 見積もり

ステータスの遷移は次のように行われる

• 依頼者がアイデア等をひとまず書きとめておく状態
• 依頼者がIssueを切るとワークフローによりProjectのNew issueに追加される
• 開発者はIssueを軽く確認し、Product Backlogに入れる

• Issueが開発予定である状態
• 受け入れ条件がタスクのIssue2つ以上になる場合、開発者はEpicとして取り扱ってタスク単位で子Issueを切っていく
  • 親IssueはEpicに移動し、milestoneを作成する
  • Epic issueテンプレートを使って子Issueを切り、milestoneに入れる
  • Epicは子Issueが全てCloseした段階でReleased/Closedに移動する
• 5.まで記載が終わった段階でReady条件の確認を行い、見積もりを行ってReadyに移動する

• Issueの理由を読み、考慮のうえで各項目が記載されている
• 実装方針に参考になるファイル・部分や外部記事などが記載されている
• 既存実行の変更の際は、実装方針に変更するファイルが記載されている

• Issueの6.まで記載が終わっていて、すぐに実装開始可能である状態
• 実装の前にIssueを最終確認する
  • Issueの内容に不十分な部分がある場合はBacklogに戻す
  • 開発しない場合、IssueをNot planned（グレーの斜線）にしてReleased/Closedに移動する
• 開発を始めた場合、In progressに移動する

• Issueの実装中である状態
• 開発ブランチは原則下書きのプルリクエストを出し、Issueに紐づける
• テストを書き、CIを通して、Pull Requestに必要な記載をおこなったら、In reviewに移動する
  • Issueの受け入れ条件に対応した動作を確認し、該当の条件にチェックをつけ、Pull Requestに動作のチェックリストを作成する

• レビューを受けている状態
• Pull Requestの動作を確認し、確認できた動作にチェックをつける
• レビューで問題がない場合、プルリクエストをマージしてIssueをDoneに移動する

• mainにマージが行われ、リリース待ちの状態
• IssueはすでにCloseしている
• リリースが行われた段階で、Released/Closedに移動する

• リリースされた／Issueに対応しないことが決められた状態
  • Released: リリースが行われた段階
    • Epicは子Issueが全てClose/Not plannedになった段階
  • Closed: Not plannedになった段階
• Closedは理由のラベルを付ける
  • duplicate: 実装済みなどですでにある
  • invalid: 内容が間違えている
  • wontfix: これは実装しないと決めた