Which is the best bug title for a crash that happens when opening a 0-byte file?
A good title is specific, concise, and searchable. Option B follows the pattern [what fails] [when/under what condition]: the symptom (app crashes), the exact trigger (opening a 0-byte file), and the path (File → Open).
Lead with the component or symptom so the title scans well in a list.
Include the distinguishing condition that makes this bug unique.
Keep it to ~8–12 words; details go in the body, not the title.
"Crash bug" (A) is unsearchable. Option C adds emotion ("really bad") instead of facts. Option D describes intent to fix, not the defect. A future engineer searching "0-byte file crash" will find only Option B.
2 / 5
A title reads: "Button doesn't work." Which rewrite is most specific?
Name the exact element and the exact failure. Option C identifies which button ("Save draft"), where it is (editor toolbar), and the precise behaviour (nothing on first click, works on second) — a classic double-click/state bug that is now instantly recognisable.
Quote the visible label in quotation marks so it is searchable.
Describe the failure mode, not just "broken".
Edge details like "works on second click" often reveal the root cause.
Options A, B, and D all say "some button, some problem" — none would help a developer or appear in a useful search. Specificity is what makes a title actionable.
3 / 5
Which one-line summary best opens a bug report about slow API responses?
A strong summary front-loads the measurable facts. Option C gives the since-when (v5.1 deploy), the exact endpoint (GET /api/orders), the metric (p95 latency), the before/after numbers (180ms → 2.4s), and the conditions (normal load).
Cite a percentile (p50/p95/p99), not just "slow".
Anchor the change to a release or date.
Show before vs after so the regression is undeniable.
Options A, B, and D substitute complaints and exclamation marks for data. A reviewer can act on Option C immediately and even bisect from v5.1; the others trigger a round of "can you be more specific?".
4 / 5
Why is this title problematic? "Fix the thing on the dashboard that broke after the merge."
A bug title should describe the defect, not phrase a to-do. Option B nails both faults: it is written as an imperative task ("Fix the thing") and it is vague (the thing, broke), so nobody can tell what is wrong or find it by search.
Prefer a noun-phrase symptom: "Dashboard totals show NaN after CSV import".
Avoid task verbs like Fix/Update/Change in the title — that belongs to the resolution.
Replace placeholders (thing, stuff, broke) with the actual component and behaviour.
Option C is wrong because "dashboard" alone is not enough; Option D mistakes urgency for clarity.
5 / 5
You are about to file a bug. What should you do first to keep titles searchable and avoid duplicates?
Search before you file, and write the title you would have wanted to find. Option B describes the professional habit: search existing issues for the symptom and version, then craft a concise, specific title using those same keywords.
Searching prevents duplicate issues and surfaces related discussion.
Mirror the searchable terms (component, error text, version) in your title.
Keep it tight — a 40-word title (Option A) is unscannable; a generic one (Option C) collides with everything.
Filing without checking (Option D) creates duplicate noise that slows the whole team. The goal: one bug, one clearly named, easily found issue.