Skip to content

Instantly share code, notes, and snippets.

@crittermike
Last active April 16, 2026 18:46
Show Gist options
  • Select an option

  • Save crittermike/4f0636cf3dbf27aa079c7f6c96bde42b to your computer and use it in GitHub Desktop.

Select an option

Save crittermike/4f0636cf3dbf27aa079c7f6c96bde42b to your computer and use it in GitHub Desktop.
Proposal: split epic checklists into phased issues

Proposal: split mega checklist into more, smaller checklists lol

The problem

Our current epic planning process uses a single issue with ~41 checkboxes across 5 sections. Most DRIs don't keep up with this, and most of the checkboxes end up unchecked, meaning some important stuff can get missed.

Example of the current format: https://github.com/github/security-products-enablement/issues/2283

Proposal

Replace the single mega-checklist issue template with 3 smaller issue templates, one per phase. This gives us three natural review points instead of one (or none) and clearly marks the end of one phase and the start of the next.

Issue 1: Planning & prep

Everything before code starts. Merges the current Requirements, Architecture, and Planning sections.

  • Schedule weekly epic sync meeting with DRI/EM/PM/designer
  • Ensure that epic links to product spec and Figma designs (if applicable)
  • Define success metrics with PM
  • Identify resources and staffing needs
  • Identify dependencies on other teams
  • Identify scaling/performance considerations
  • Identify billing implications
  • Identify GHES implications
  • Identify API surface changes
  • Write ADR
  • Run team ADR walkthrough meeting
  • Complete security review (if applicable)
  • Complete privacy review (if applicable)
  • Create high level iterative milestone issues as Batch issues under the epic
  • Define testing scenarios per milestone
  • Add milestone by milestone timeline to the main epic
  • Set target date(s) for the ship(s)
  • Create the Implementation issue from template

Issue 2: Implementation

Tracks the creation of all the sub-issues that make up the actual work.

  • Create core development issues
  • Create billing issues (if applicable)
  • Create GHES issues (if applicable)
  • Create API/webhook issues (if applicable)
  • Create EMU issues (if applicable)
  • Create audit logging issues (if applicable)
  • Create stafftools issues (if applicable)
  • Create Proxima issues (if applicable)
  • Create Kusto dashboard issues with PM (if applicable)
  • All implementation issues assigned to owners
  • Create the Verification & ship issue from template

Issue 3: Verification & ship

Everything after code is written, through rollout and retro.

  • Set up Datadog dashboards/monitoring
  • Verify error handling and alerting
  • Run bug bash
  • Define rollout plan (flag %, stages, timeline)
  • Define SLOs
  • Execute rollout
  • Post-deploy cleanup (remove flags, close milestone)
  • Schedule and run the epic retro
  • Close the epic tracking issue/discussion

But what's to keep this from being ignored?

That's a major problem we have right now: the issue gets created and a few checkboxes get checked and then nobody looks at it again.

To fix that, we'll review the status of the current checklist issue at the start of each of the weekly epic sync meetings, always, forever, no matter what, or else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment