What does 'won't fix' mean for a bug?

That the team has deliberately decided not to fix it, because its impact is too low to justify the effort, the fix is too risky or costly, it is working as intended, or it is out of scope. The key word is 'decided', it is a conscious cost-benefit choice, not a bug that was forgotten or ignored.

Is it okay to mark bugs as 'won't fix'?

Yes, it is healthy prioritization. You cannot fix every bug, and some cost more to fix than they cost players, so consciously declining the ones that are not worth it frees you to focus on the ones that are. The key is that the decision is deliberate and recorded with a reason, not an accidental omission.

What is the difference between 'won't fix' and ignoring a bug?

'Won't fix' is a deliberate, recorded decision with a reason that you can revisit if circumstances change; ignoring a bug is an accidental omission that will resurface as a surprise. The status makes the choice explicit and keeps the backlog honest, and keeping the bug tracked means you can reopen it if more reports change the calculus.

What Does 'Won't Fix' Mean in Bug Tracking?

Quick answer: 'Won't fix' (or 'not planned') is a status used to close a bug that the team has deliberately decided not to address. It is a legitimate resolution applied when a bug's impact does not justify the cost or risk of fixing it, when it is working as intended, or when it falls outside scope. It marks a conscious choice rather than a forgotten or ignored issue.

'Won't fix' sounds dismissive, but it is one of the most important and healthy resolutions in bug tracking. It represents a deliberate decision: this bug is real, we have considered it, and we are choosing not to fix it. Far from being neglect, a well-used 'won't fix' is how good teams keep their finite effort focused on what matters. Understanding when and how to use it, and how it differs from simply ignoring a bug, is part of mature bug management.

What 'Won't Fix' Actually Means

'Won't fix' is a closing resolution that says: we have evaluated this bug and decided not to fix it. The crucial word is 'decided', it is a conscious choice, distinguishing it from a bug that is simply forgotten or untriaged. The bug is acknowledged as real (or as not-a-bug); the team has just concluded that fixing it is not worth doing. It is the endpoint of a deliberate cost-benefit judgment.

Common reasons include: the impact is too low to justify the effort (a cosmetic issue almost no one notices), the fix is too risky or costly relative to the benefit (a small bug requiring a dangerous change to core systems), the behavior is actually working as intended (a 'bug' that is really a feature), or it is out of scope (not something this game will address). Each is a valid reason to close without fixing.

Why 'Won't Fix' Is Healthy

You cannot fix every bug, your time is finite, and some bugs cost more to fix than they cost your players. Treating every bug as mandatory leads to either burnout or to high-impact bugs waiting while you polish trivial ones. 'Won't fix' is the mechanism for consciously declining the bugs that are not worth it, which is what frees you to focus on the ones that are. A backlog with deliberate 'won't fix' decisions in it is a sign of healthy prioritization.

The key is that the decision is deliberate and recorded, not accidental. A bug closed as 'won't fix' with a reason is a managed decision you can revisit if circumstances change; a bug silently forgotten is a liability that will resurface as a surprise. The status makes the choice explicit and keeps the backlog honest.

Using 'Won't Fix' Well

Use 'won't fix' with a reason, both for your own future reference and for any player who reported the bug. Recording why you declined ('low impact, high risk to fix' or 'working as intended because...') makes the decision reviewable and lets you respond honestly to reporters. And keep the bug in your tracker rather than deleting it, so if its impact grows (more reports arrive), you can reopen it with the original context intact.

Bugnet lets you close issues with a resolution and reason while keeping their history, so a 'won't fix' decision is recorded, not lost, and the issue can be reopened if new occurrences change the calculus. This turns 'won't fix' into what it should be, a deliberate, reversible, documented choice that keeps your finite effort focused, rather than either a dismissal of reporters or a bug quietly falling through the cracks.

'Won't fix' isn't neglect, it's a decision. Recording why you're declining a bug keeps your effort focused and the choice reversible.