Triaging Bugs
Overview
Turn an unclear bug report into an actionable ticket by clarifying impact, reproducibility, scope, and ownership of next steps.
When to Use
- The report lacks repro steps or expected vs. actual behavior
- Severity/priority is unclear or disputed
- You need to route the issue (frontend/backend/data/infra) with minimal back-and-forth
When NOT to use
- The bug is already well-scoped with reliable repro steps and clear fix owner
Core Pattern
Classify first, then investigate:
- Impact: who is affected and how badly
- Scope: how widespread (all users vs. subset)
- Repro: steps, environment, frequency
- Regressed?: did it work before
- Next step: one concrete action to reduce uncertainty
Quick Reference
Ask for (or infer) these fields:
- Title: short + specific (feature + symptom)
- Environment: prod/stage/local, browser/device, version/commit
- Expected vs. Actual
- Repro steps + frequency
- Logs/IDs: request IDs, user IDs, timestamps, screenshots
- Severity (impact) and Priority (when to do it)
Implementation
- Rewrite the report into Expected vs. Actual plus minimal repro.
- Assign a severity (impact-based) and priority (schedule-based) with a one-line rationale.
- Decide the next step:
- Need repro → ask targeted questions and request artifacts - Repro exists → identify likely component boundary and assign owner - Production-only → request request IDs/timestamps and add logging/metrics task
Common Mistakes
- Conflating severity and priority: high severity can still be low priority if rare and mitigated.
- Asking vague questions: “can you provide more details?” → ask for environment + exact steps + frequency.