Bug report

How to use it well

• →Repro steps only count if a stranger with no context can follow them and hit the bug - if a step relies on knowledge only you have, it isn't a reproduction, it's a memory.
• →Justify the severity in the report itself. "P1" without a sentence explaining who it blocks and whether there's a workaround gets triaged on vibes and re-litigated later.
• →One piece of concrete evidence - a recording, a log line, a stack trace - resolves more severity arguments than three paragraphs of description.

Part by part

**Environment:** {{environment}}

In the header, because it determines whether anyone can reproduce it. A bug that only appears on one browser is a different bug from one that appears everywhere.

## Steps to reproduce

The section that decides whether the report is actionable. Everything else can be inferred; this cannot.

## Why this severity

Justifies the rating rather than asserting it. A severity with reasoning can be argued with and adjusted; one without it is either accepted or ignored.

## Evidence

Screenshots, logs, a recording. Evidence is what converts a report someone believes into one they can start from.

Common mistakes

• Steps that assume knowledge of the setup.

  A reproduction starting from a state only you have is not reproducible. Steps should begin from something anyone can reach — a fresh login, a known account, a specific URL.

• Marking everything critical.

  Severity inflation destroys triage. If every report is critical, the genuinely critical one waits behind four that are not, and the person who inflated is the one who suffers.

• Describing the expected behaviour and omitting the actual.

  Both are needed, because a surprising number of bugs turn out to be a disagreement about what should happen. Stating them separately surfaces that immediately.

Questions