Feature vs. Bug Writing
Classifying issues correctly and writing Won't Fix, By Design, and reopen comments
Classification vocabulary
- Bug — software behaves differently from its specification or documented intent
- Feature request / Enhancement — software works as designed; user wants different behaviour
- By Design — behaviour is documented and intentional; reference the spec or ADR
- Won't Fix — fix cost/risk outweighs impact; always explain the reason with data
- Regression — a previously working feature broken by a recent change
Question 0 of 5
A user reports: "The search results only show 10 items per page. I want to see 50." How should this be classified?
- Bug: the software behaves differently from its specification or documented intent
- Feature request: the software works as designed, but the user wants it to work differently
You write a "Won't Fix" response to a bug. Which response is most professional and informative?
- Reference: link to spec, ADR, or product decision
- Data: "0.1% of users" — quantify the impact
- Risk analysis: "restructuring auth flow" — explains why fixing is costly
- Open door: "If this becomes more impactful, please reopen" — shows good faith
A developer says: "The API returns a 200 status code even when the email address format is invalid." A PM says: "We designed it to return 200 always to not expose internal validation errors." How should this be classified?
- Does the API spec (OpenAPI, README) say what status to return on validation failure? If yes, it's the source of truth.
- Was there a formal ADR (Architecture Decision Record) documenting the always-200 choice? If yes, it's By Design.
- If it was an undocumented decision in someone's head, it should be captured in the spec first before closing as By Design.
You need to reopen a previously closed bug because the fix introduced a regression. Which language is most appropriate?
- Reopen statement: "Reopening"
- Fix reference: "The fix in PR #347" — links to the change that caused the regression
- New symptom: precise description of the new bug
- New title if needed: the regression may deserve its own ticket
- Label: "regression" tag helps triage
A product manager says a behaviour is "by design" but users are frequently confused by it. What is the best course of action?
- Keeps the bug tracker accurate — it is not a bug if it is intended behaviour
- Does not discard valid user feedback — it gets its own ticket with proper context
- Links the two tickets so the context is preserved
- Quantify user confusion: "5 support tickets in 2 weeks", "mentioned in 3 user interviews" — gives PM data to reprioritise