What Is the Difference Between a Bug Report and a Feature Request?

Player feedback arrives mixed together: some of it is 'this is broken,' some is 'I wish it did this.' The first is a bug report, the second a feature request, and telling them apart is one of the first decisions in triage. They are both valuable, but they are fundamentally different kinds of input that need different evaluation, different prioritization, and often different people. Understanding the distinction keeps your feedback organized and your responses appropriate.

Broken vs Wanted

The core distinction is whether something is working incorrectly or simply absent or different from what someone wants. A bug report identifies a defect: the game does X when it should do Y, a mismatch between actual and intended behavior. A feature request identifies a desire: the game does not do Z, but the player would like it to, where 'not doing Z' is not a defect because Z was never intended in the first place.

The test is intent. If the behavior violates how the game is supposed to work, it is a bug. If the behavior is as designed but the player wants something more or different, it is a feature request. This is also why some reports are tricky: a player may report intended behavior as a 'bug' because it surprised them, which is really feedback that your design is unclear, a third category worth recognizing.

Why the Distinction Matters

Bugs and features need different handling. Bugs are about restoring correctness, they have a notion of 'right' to return to, are evaluated on impact and severity, and often carry urgency (a broken thing is actively hurting players). Feature requests are about adding value, they are evaluated on desirability and fit with your vision, rarely carry the same urgency, and involve product judgment about what the game should become rather than fixing what it is.

Mixing them muddles both. A feature request triaged as a bug clutters your defect list and distorts your quality metrics; a bug dismissed as 'just a request' leaves a real problem unaddressed. Separating them, often with a label or category at intake, keeps each stream clean: your bug backlog reflects actual defects, and your feature requests inform your roadmap.

Handling Both Streams

Good practice is to categorize incoming feedback into bugs and feature requests (and design-confusion, the tricky third case) at triage, then route each to its appropriate workflow. Bugs go into your defect tracking, prioritized by impact. Feature requests go into a separate consideration, often feeding a roadmap, weighed against your product direction. Both deserve acknowledgement to the player, but the evaluation differs.

Bugnet helps keep the streams organized: bug reports flow into your tracker with the technical context that makes defects actionable, while you can use labels to separate genuine bugs from feature requests, and feed the latter toward your public roadmap where players can see what is planned. Distinguishing the two at intake, then handling each appropriately, ensures bugs get the impact-driven urgency they need and feature requests get the product-judgment consideration they deserve, rather than the two contaminating each other in one undifferentiated pile.

A bug report is 'this is broken'; a feature request is 'I wish it did this.' Broken versus wanted, and they go to different workflows.