Release Planning using GitHub Projects

Release Planning using GitHub Projects

The HDF Group tracks all publicly visible features and issues (excluding internal refactoring) on GitHub to ensure transparency and allow the community to monitor release progress.

This is managed through the HDF5 Triage & Track GitHub Project. This project framework organizes issues by software components and groups them under high-level parent issues representing broader work areas.

See details below.

Release Milestone Framework

• Release Milestone: Captures the scope and timeline of a release.
• Release Scope: Defined by GitHub issues tagged with the milestone label.
• Release 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
Release_Blocker	Hard requirement for the release. Cannot proceed until resolved, regardless of priority.	100%
Release_Nice to Have	Not required; can be deferred if needed. Critical issues cannot be marked as Nice to Have.	70%
Release_Deferred	Deferred issues for future consideration.	N/A
Release_Missed	Issues missed in the current release cycle.	N/A

---

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. It’s a dependency, not a rank of urgency.

Examples:

• A high-priority issue that isn’t a blocker (e.g., a bug in a non-critical feature).
• A medium-priority issue that is a blocker because it affects something in the release scope (e.g., a new API that must land before tagging).

Separate Labels:

• One set of labels or tags 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:
  • Open issues under the release milestone are moved to the next milestone for planning into a future release.
  • The current release milestone is closed.
• During a new release planning cycle:
  • Technical Leads, together with the Product Owner, re-evaluate the size and priority of:
    • Issues tagged with backlog status.
    • Issues tagged as release_missed, release_deferred, and release_nice_to_have.
  • This grooming process identifies issues for the next release.
  • The planning lead collaborates with the product and technical leads to allocate resources and schedule the next release's timeline and scope

---

Policy Summary

• All releases must have a defined milestone, scope, and timeline.
• Issues must be prioritized using the P0–P3 scale and tagged accordingly.
• Blocker issues must be resolved before release; Nice to Have items may be deferred.
• Internal HDFG issues are mandatory for inclusion in the release.
• Priority and blocker status are tracked separately to clarify urgency vs. dependency.