How do I decide which bugs to fix first?

Fix the bugs with the highest combination of severity and reach first, working down a priority list ordered by severity times reach. Priority combines two things: severity (how bad the bug is for a player who hits it, a crash or game-breaker is severe, a cosmetic glitch is not) and reach (how many players are affected). The bugs to fix first are those high in both, severe and widespread (a game-breaker or crash affecting many players), since they do the most total harm. To set this up, group duplicate reports of the same bug so its reach (affected-player count) is accurate, capturing crashes from the field with affected-player counts gives you the reach for crashes directly, then weigh that reach against the bug's severity to get its priority. Work the top of the resulting list (highest severity-times-reach), since that's where fixing delivers the biggest improvement to your game for your limited time, and consciously defer or decline the low-priority tail (low-severity, low-reach bugs), which keeps your effort concentrated on what matters. The key nuances: a severe bug affecting almost no one may be lower priority than a moderate bug affecting many (reach matters, not just severity), and bugs on critical paths (save, progression, core loop) tend to be both more severe and more widely hit, so they often top the list. So decide what to fix first by ranking bugs by impact (severity times reach), with accurate reach from grouping duplicates and capturing affected-player counts, then work the top of that ranked list, fixing the bugs that do the most total harm first, while deferring the low-impact tail. This impact-based prioritization, rather than fixing by recency, loudness, or severity alone, is what makes your limited fixing time deliver the most improvement, which is the goal of deciding what to fix first.

Is severity or impact more important for prioritizing bugs?

Neither alone, you need both, because priority is the combination of severity (how bad) and reach (how many players), and using either in isolation leads to mis-prioritization. If you prioritize by severity alone, you might over-prioritize a severe bug that affects almost no one (a game-breaker only one player on an obscure configuration can hit) over a moderate bug affecting a large share of your players, even though the latter does more total harm, so severity alone ignores how widespread the problem is. If you prioritize by reach alone, you might over-prioritize a widespread cosmetic issue over a severe but somewhat-less-common game-breaker, even though the game-breaker hurts the affected players far more, so reach alone ignores how bad the problem is per player. The right approach combines them: a bug's priority reflects both how bad it is for a player who hits it (severity) and how many players hit it (reach), often thought of as severity times reach, so the highest-priority bugs are severe and widespread, and you weigh severe-but-narrow against moderate-but-widespread by considering total harm. In practice, the term 'impact' often already captures this combination, impact is the total harm a bug does, which depends on both severity and reach, so prioritizing by impact means weighing both. The reason both matter is that what you're really trying to minimize with your limited fixing time is total harm to your players, which is severity (harm per affected player) times reach (number of affected players), so you can't ignore either dimension. So for prioritizing bugs, combine severity and reach rather than treating either as more important: use severity to capture how bad each bug is and reach to capture how widespread it is, and prioritize by their combination (total impact), which correctly puts the bugs doing the most total harm, severe and widespread, at the top. Field crash capture provides the reach (affected-player counts) for crashes, and a severity system provides the how-bad classification, and combining them gives you the impact-based priority that aims your fixing at the bugs that matter most.

Best Practices for Setting Bug Priorities

Q: What are the best practices for setting bug priorities?

Set priority by combining severity and reach, with accurate reach from grouping, then work the top and defer the tail. Combine severity (how bad a bug is per affected player) and reach (how many players it affects), since priority is essentially severity times reach, a severe bug hitting many players is top priority, while a severe bug hitting almost no one may rank below a moderate bug hitting many (because the latter does more total harm). Group duplicates so each bug's reach (affected-player count) is accurate, since you can't judge reach from the same bug scattered across many reports, and grouping reveals true reach so a widely-hit bug shows its real priority. Work the top of the priority list (highest severity times reach) and consciously defer or decline the low-priority tail, since setting priorities means deciding what not to do too, and explicit deferral keeps your effort on what matters and your backlog honest. Good priority-setting aims your limited fixing time at the bugs that do the most total harm, so the practices serve combining the two priority inputs (severity and reach), getting accurate reach (via grouping), and acting on the priorities (work the top, defer the tail). Capturing crashes from the field with affected-player counts and grouping by signature is what makes accurate reach-based prioritization possible for crashes, the affected-player count is the reach, which you combine with severity to set priority.

Quick answer: Set priority by combining severity and reach, group duplicates so reach is accurate, work the top of the list, and consciously defer the low-priority tail. Good priority-setting aims fixing time at the most harmful bugs.

Setting bug priorities well is what makes your limited fixing time count. Here are the best practices for setting bug priorities.

Combine Severity and Reach

Priority isn't severity alone or reach alone, so combine them, priority is essentially how bad a bug is (severity) times how many players it affects (reach). A severe bug hitting many is top priority; a severe bug hitting almost no one may rank below a moderate bug hitting many.

Bugnet ranks issues by affected players (reach), which you weigh with severity. Combining severity and reach is the core of setting priorities, since the bugs that do the most total harm, severe and widespread, deserve the highest priority.

Group Duplicates So Reach Is Accurate

You can't judge reach if the same bug is scattered across reports, so group duplicates so each bug's reach (affected-player count) is accurate. Grouping reveals true reach, so a widely-hit bug shows its real priority rather than being scattered or hidden.

Bugnet groups crashes by signature with affected-player counts, so reach is accurate. Grouping duplicates is essential to setting priorities accurately, since reach drives priority and you can't judge reach from scattered duplicate reports.

Work the Top and Consciously Defer the Tail

Setting priorities means deciding what not to do too, so work the top of the priority list (highest severity times reach) and consciously defer or decline the low-priority tail. Explicit deferral keeps your effort on what matters and your backlog honest.

Bugnet's impact ranking makes the top and the tail clear. So practice setting bug priorities by combining severity and reach, grouping duplicates so reach is accurate, and working the top while deferring the tail, aiming your limited fixing time at the bugs that do the most total harm.

Set priority by combining severity and reach, group duplicates so reach is accurate, work the top of the list, and consciously defer the low-priority tail. Good priority-setting aims fixing time at the most harmful bugs.