Maintainers triage issues like ER doctors triage patients: fast, by first impression. A report with a clear title, a minimal repro, and clean writing gets read. A rambling one with typos in the critical sentence ("the token retuns 500 instead of 401") gets skimmed, misread, and closed. The grammar of your bug report is part of its content.
Anatomy of a Bug Report That Gets Fixed
- Title = symptom + scope. "POST /v1/orders returns 500 when currency is JPY" - not "order API broken!!"
- Expected vs. actual, in that order. The reader needs the contract before the violation.
- Minimal reproduction. Ten lines that always fail beat two hundred that sometimes do.
- Versions and environment, in a fixed order, every time.
- One bug per report. Two bugs in one issue means both wait for the other.
The Grammar Errors That Cause Misreading
Bug reports are written fast, often by non-native speakers, about error text full of code - exactly the combination generic checkers mangle. Flagging AssertionError as a typo or rewriting your repro into "proper sentences" turns the checker into noise.
A code-aware checker like Lint leaves stack traces and identifiers untouched while fixing the prose - "retuns" becomes "returns", your HTTPError survives intact. The diff view keeps the report in your voice.
A 3-Minute Pass Before You Hit Submit
- Grammar-check the prose (not the snippets) with a code-aware, diff-based tool
- Re-read the title only - would a maintainer know where to look?
- Delete the backstory. Cut to the symptom.
Your bug report is a document competing for scarce attention. Structure it like a report, grammar-check it like one.
👉 Try Lint free - 3 checks/day, no signup. BYOK: unlimited, $0.
Top comments (0)