Release Planning using GitHub Projects

Release Milestone Framework

• Release Milestone: Captures the scope and timeline of a release.
• Scope: Defined by GitHub issues tagged with the milestone label.
• Timeline: Defined by the milestone date.

---

Issue Priority Levels

Priority	Description	Release Target
P0 – Critical	Blocks core functionality, causes memory loss, crashes, or prevents users from proceeding. MUST be addressed immediately.	80%
P1 – High	High impact; should be resolved soon but doesn’t block the entire system. May affect key features or cause major inconvenience.	50%
P2 – Medium	Important but not urgent. Improves user experience, stability, or maintainability. Can be postponed or scheduled when resources are available.	N/A
P3 – Low	Nice to have; unlikely to cause real problems. Can be postponed or scheduled when resources are available.	N/A
HDFG_Internal	Internally coded for HDFG use.	100%

---

Release Gating

Type	Description	Release Target
Blocker	Hard requirement for the release. Cannot proceed until resolved, regardless of priority.	100%
Nice to Have	Not required; can be deferred if needed. Critical issues cannot be marked as Nice to Have.	70%

---

Priority and Release Blocker Status

• Priority (P0, P1, P2, etc.): Reflects urgency and importance relative to other work. Guides sequencing and resource allocation.
• Blocker (e.g., release-blocker): Indicates a hard requirement for the release. The release cannot proceed until resolved, regardless of priority.

Examples:

• High-priority issue that isn’t a blocker (e.g., bug in a non-critical feature).
• Medium-priority issue that is a blocker because it affects release scope (e.g., new API required before tagging).

Separate Labels:

• One set of labels for priority (P0, P1, P2, etc.).
• A separate tag for release blockers (e.g., release-blocker, must-merge).

---

Release Closure and Future Planning

• At the time of release:
  • Close the milestone.
  • Move any release_nice_to_have issues to the next milestone for future planning.
• During a new release planning cycle:
  • Technical Leads and Product Owner re-evaluate:
    • Backlog of issues.
    • Product roadmap.
    • Issues tagged as release_missed, release_deferred, and release_nice_to_have.
  • Groom and tag issues for the next release.

---

Policy Summary

• All releases must have a defined milestone, scope, and timeline.
• Issues prioritized using P0–P3 scale and tagged accordingly.
• Blocker issues resolved before release; Nice to Have items may be deferred.
• Priority and blocker status tracked separately.
• Post-release, milestones closed and deferred issues re-evaluated during next planning cycle.