issue-triage

Triage GitHub issues by applying a single state label, assigning accepted work to concrete version milestones, and leaving a short rationale comment to record the decision. This standardized process keeps the backlog legible and ensures every item is either planned or closed.

Manage backlog sweeps by revisiting deferred or needs-info issues to check if they can be resolved or require further action. Update their state labels, assign concrete milestones if accepted, and add a concise rationale comment whenever the triage state or milestone membership changes.

Enforcing a single state label on open GitHub issues prevents conflicting status indicators and keeps the backlog legible. This policy ensures maintainers can quickly identify the current triage state of any item without parsing multiple overlapping labels.

Record rationale by leaving a short comment on the GitHub issue whenever the triage state or milestone membership changes. This practice ensures decisions are documented for future reference and provides context for other maintainers reviewing the backlog.

Yes, you can backfill labels on existing GitHub issues as part of the triage process. Apply appropriate default type labels such as bug, enhancement, or documentation to ensure historical backlog items meet current classification standards.

Close GitHub issues when the work is not planned rather than leaving them in an ambiguous backlog state. The triage process requires deciding whether to assign accepted items to concrete version milestones or close them to keep the backlog actionable.