Which bug report opening is most useful to a maintainer?
Effective bug report titles/openings: name the specific endpoint or function, describe the exact symptom (HTTP 500), specify the trigger condition (Unicode username), and note what works (ASCII). A maintainer reading this knows immediately what is broken, where to look, and what to test. "Broken", "bug found", and "something wrong" tell the maintainer nothing actionable.
2 / 5
What does "steps to reproduce" mean in a bug report, and which example is correct?
Steps to reproduce must be: numbered, exact (include the precise request, input, or action), complete (starting from a clean state), and deterministic (reproducible by someone with no knowledge of your specific setup). A maintainer should be able to follow the steps and see the same bug without any guesswork.
3 / 5
A bug report template asks for "Expected behaviour" and "Actual behaviour". Which pair is most useful?
The expected/actual pair should be specific enough that a maintainer can write a failing test from it. Include: the exact HTTP method and path, status code, response body, and any relevant log output. "It should work" vs "it does not work" gives zero information for debugging. The log snippet in the actual behaviour is especially valuable — it often reveals the root cause immediately.
4 / 5
The bug report template asks for "Environment". Which response is most useful?
Environment details help maintainers reproduce and isolate bugs. Include: OS + version, runtime + version, package version (exact — not "latest"), execution context (browser/server), and environments tested. "My computer" and "Windows" are too vague. "Latest version" is actively harmful — maintainers need to know whether the bug exists in the version they just released.
5 / 5
You are reporting a bug in an open source library. You have not investigated the root cause but you have a reliable reproduction. Which statement best describes your responsibility?
A reliable reproduction is the most valuable thing a bug reporter can provide. Many maintainers say "a reproducible bug report is already 80% of the fix." Root cause analysis and fixes are welcome additions but are not prerequisites. Demanding that reporters fix bugs before filing them is a community anti-pattern that reduces bug reporting and leaves maintainers without visibility into real-world issues.