How to write a usable bug report

Goal

The report contains everything the receiving side (a developer, an operator or an agent) needs to reproduce and triage the bug on the first attempt, and nothing they would first have to clear away.

Prerequisites

You have observed the bug yourself at least once, and you know the environment (version, operating system, browser or runtime, and any settings that differ from the defaults).

Steps

1. Search first: does this report already exist? If so, add to it instead of opening a second one.
2. Write the title as a sentence stating the symptom and the condition: "Export fails with UnicodeEncodeError for file names containing an umlaut", not "Export broken".
3. State the environment: product version or commit, operating system, runtime or browser with version, and relevant settings. Anything that deviates from the defaults belongs here.
4. Give the steps to reproduce as a numbered list, each with exactly one action, starting from a known initial state (fresh installation, sample file attached). The Mozilla guideline (cited) calls for exactly this separation into "Steps to Reproduce", "Expected Results" and "Actual Results".
5. Give the expected and the actual result in one sentence each. Quote the error message verbatim and in full (stack trace as a code block, not as a screenshot), and include a log excerpt with timestamps.
6. Reduce the case as far as time allows: remove steps and data until the bug disappears, then undo the last removal. The Stack Overflow pattern "minimal, complete, reproducible" is the benchmark; sometimes the cause becomes visible during the reduction.
7. Describe frequency and impact: whether it happens always or occasionally, since when, how many people are affected, and whether a workaround exists.
8. Put guesses about the cause in a separate section titled "Suspected cause", clearly apart from the observations. No judgments, no blame.
9. Before submitting, read the report as if you did not know the project: is a file, a command or a version missing?

Expected result

The recipient reproduces the bug without asking questions and can prioritize it. Later, the report becomes a regression test, because the steps and the expectation are already written down.

Limits and test basis

Some bugs cannot be reproduced deterministically (timing behavior, load, concurrency). In that case the report should include the frequency, the times of occurrence and the conditions of the observation. Confidential data in attachments and logs must be removed beforehand. The structure follows the cited guidelines; no statements are made about processing times.