Free bug report templates

Title: [Area] What goes wrong, in a few words

Steps to reproduce
1. Where you start (page, screen, command)
2. What you do
3. What you do next
4. The step where it goes wrong

Expected
What should have happened.

Actual
What happened instead, including the message shown.

Environment
Version or build, platform, browser or operating system,
account type, and how often it happens.

Evidence
Log excerpt, screenshot, request id or a short recording.

Severity and reason
How bad it is and who it affects.

Related
Tickets that look similar or touch the same area.

Steps to reproduce
1. Where you start (page, screen, command)
2. What you do
3. What you do next
4. The step where it goes wrong

Expected
What should have happened.

Actual
What happened instead, including the message shown.

Environment
Version or build, platform, browser or operating system,
account type, and how often it happens.

Evidence
Log excerpt, screenshot, request id or a short recording.

Severity and reason
How bad it is and who it affects.

Related
Tickets that look similar or touch the same area.

name: Bug report
description: Report something that does not work as expected
title: "[Bug]: "
labels: ["bug"]
body:
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
      description: Numbered steps that start somewhere a stranger can reach.
      placeholder: |
        1. Open the page or run the command
        2. Do this
        3. Then this
        4. The step where it goes wrong
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: Expected
      description: What should have happened.
    validations:
      required: true
  - type: textarea
    id: actual
    attributes:
      label: Actual
      description: What happened instead, including any message shown.
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: Version or build
      description: The release, commit or build you saw this on.
    validations:
      required: true
  - type: textarea
    id: environment
    attributes:
      label: Environment
      description: Platform, browser or operating system, and how often it happens.
  - type: textarea
    id: evidence
    attributes:
      label: Evidence
      description: Log excerpt, request id or a screenshot. Remove personal data first.
      render: shell
  - type: dropdown
    id: severity
    attributes:
      label: Severity
      options:
        - Blocks work
        - Wrong result
        - Cosmetic

Title
[Area] What goes wrong, in a few words

Repro Steps
1. Where you start
2. What you do
3. What you do next
4. The step where it goes wrong
Expected: what should have happened.
Actual: what happened instead, including the message shown.

System Info (or the Environment area of your form)
Build, platform, browser or operating system, how often it happens.

Attachments
Trimmed log, screenshot or recording.

Severity
Pick the value that matches the impact, and say why in the discussion.

Related
Link similar work items with the Related link type.

# Steps to reproduce: checklist and template

Read each line and ask whether your steps pass.

- They start somewhere a stranger can reach. Name the page, the screen or the command, and the account type if it matters.
- Each action gets its own step. Number the steps so you can refer to a step by its number.
- They use the real values: the promo code, the file name, the amount or the setting you used.
- They include the waits and the clicks that are easy to forget, such as "wait for the list to load" or "close the dialog".
- They end at the moment it goes wrong. Everything after it belongs in Actual.
- They say what you expected and what happened, including the message shown.
- They name the build and the environment: the version, the platform and how often it happens.
- You ran them once more from a clean start. If the bug does not repeat, say so and say how often it did.
- Evidence is attached and trimmed: a short log excerpt, a cropped screenshot or a brief recording, with personal data removed.

## Template

Steps to reproduce
1. Where you start, and which account or setup
2. What you do, with the real values
3. What you do next
4. The step where it goes wrong

Expected
What should have happened.

Actual
What happened instead, including the message shown.

Environment
Build, platform, and how often it happens.

I ran these steps again: yes or no, and what happened.

# Severity and priority: a guide for bug triage

Severity is how bad the bug is. Priority is how soon it should be fixed. Score them separately.

## Severity

- Critical: data is lost or corrupted, the product will not start, a payment is wrong, or there is a security hole. There is no workaround.
- High: a main feature does not work and the workaround is painful or unknown.
- Medium: a feature misbehaves but a reasonable workaround exists.
- Low: cosmetic issues, small text errors, and anything a user would not notice or mind.

## Priority

- Now: stop other work. Fix and release as soon as it is safe.
- This release: fix before the next release goes out.
- Next: plan it for the following cycle.
- Later: keep it on the list and look again when the list is reviewed.

## Severity and priority together

- High severity, high priority: fix first. Example: checkout charges the wrong amount.
- High severity, low priority: rare, so ask whether the severity is right. Example: a crash in a feature few people use.
- Low severity, high priority: the case people forget. Example: the company name is misspelled on the home page the day before a launch.
- Low severity, low priority: backlog. Example: a button sits slightly out of line in an older browser.

## Settling a disagreement

1. Does it lose data, money or trust? If yes, treat the severity as high, even when it is rare.
2. How many people hit it, and how often? A bug in a path most people use outranks a bug in a path few people use.
3. Is there a workaround that a user will find without help? If not, move it up.

Write the answer in the ticket so the next person does not reopen the argument.