issue-triage

name	issue-triage
description	Use when triaging, diagnosing, and registering bugs or issues. Covers classification, reproduction, severity, and registration.

issue-triage

SDLC Phase: Maintenance

Triage, diagnose, and register issues.

Principles

• Reproduce first — Before classifying, confirm the issue exists. A non-reproducible issue cannot be fixed.
• Check for duplicates — Search existing issues before filing a new one.
• Be precise — A good issue report includes: exact steps to reproduce, expected vs actual behaviour, environment details.
• Link from code — When an issue is discovered during code review or refactoring, reference it in the code with a comment.

Classification

Type	Characteristics	Label
Bug	Incorrect behaviour, crash, regression	bug
Security	Vulnerability, unsafe code, dependency CVE	security
Feature request	New capability, enhancement	enhancement
Documentation	Missing/incorrect docs, broken links	documentation
Technical debt	Code smell, refactoring need, test gap	technical-debt

Severity Assessment

Severity	Definition	Action
Critical	Data loss, security breach, crash in hot path	Fix immediately, no confirmation needed
High	Feature broken, no workaround available	Fast-track through pipeline
Medium	Feature broken, workaround exists	Normal schedule
Low	Cosmetic, enhancement, nice-to-have	Next release or backlog

Reproduction Steps

1. Identify the exact crate and version where the issue occurs.
2. Write a minimal reproduction: a self-contained code snippet or test case.
3. If the issue is a regression, determine the introducing commit through git bisect.
4. Note the environment: Rust version, OS, relevant dependency versions.

Registration

When filing an issue, include:

• Title: {type}: {short description} — clear and searchable
• Labels: One or more from the Classification table
• Body:
  • Description of the problem
  • Steps to reproduce
  • Expected vs actual behaviour
  • Environment details
  • Severity assessment
  • Suggested fix (if known)

Always check for duplicates before filing. If a related issue exists, add a comment rather than opening a new one.

From Code to Issue

If an issue is discovered during development (e.g., a design flaw found during refactoring), register it and add a code comment:

// See https://github.com/reasvyn/rvlibs/issues/{N}

This creates a traceable link between the code and its known limitations.

Human Confirmation

After classification and registration, stop and wait for human confirmation before fixing. The exception is critical severity issues, which may be fixed immediately.

Output Requirements

• Issue registered with title, labels, description, reproduction steps, and severity
• Code comment linking to the issue (if discovered during development)
• Confirmation to the user that the issue has been filed