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.