doc/ISSUE_TRIAGE.md
Contents
<!-- END doctoc generated TOC please keep comment here to allow auto update -->Triage is a process of sanity checking and prioritizing issues. The term is adopted from medical contexts where patients are briefly examined to decide whether they need immediate care, or if their issue can wait until patients at greater risk can be handled first. Software issue triage is not life-or-death, but it does address the same fundamental problem, which is that there is a limited amount of attention and skill that can be brought to bear on issues at any given time, and some issues have higher impact than others.
If issues are properly triaged, contributors with time available can focus on getting things done instead of searching through issues for something to work on and fix.
Look at new issues or revisit old issues after a while and apply various labels:
Sometimes this is simple, is the game crashing, is it losing save data? If so it's definitely a bug. Likewise, new content or new ways to interact with the game are always feature requests. Other times this is a surprisingly tricky question. "The game isn't working like I expect it to" doesn't actually mean the game is doing anything wrong, and even if it is (i.e. it sets up an expectation but doesn't meet it), the problem might be where the expectation is set rather than the point where the expectation is (not) met.
At the end of the day, this is a judgement call about what the triager understands the game to be designed to do vs what it's actually doing. If the game's behavior is consistent with the design of the game, we'd call that a request to change it a feature request, if the game is not acting as designed, then it's a bug.
Roughly our priority ordering is:
This is a bit more granular than necessary, 1, 2 and 3 are critical, 4 and 5 are important and everything else is null priority.
The reason for priority triage is in part to surface the highest priority issues for more attention, and partially to guide how much effort we spend on tracking the bug.
Bugs can be reported based on some kind of misunderstanding of how the game works and sometimes even not exist at all. It's terribly easy to blame some unrelated feature or change for behavior someone doesn't like. Ideally all bug reports come with a clear statement of how to reproduce the behavior being reported and a clear statement of what should have happened instead. Unfortunately many bug reports don't have these basic elements, and the triage outcome needs to be to reply in the issue that these elements are missing. You CAN add those details yourself if you are able to and so inclined, but it's not a necessary part of the process. If an issue does not have these elements, and especially if no one else is able to reproduce the issue other than the reporter, that issue is unfortunately just noise, and the eventual outcome is closing the issue until someone can provide those details.
Feature requests should be specific, achievable and relevant (some of you might be thinking "SMART goals" and you'd be right, but Measurable and Time-bound aren't applicable).
Feature requests don't get triaged for priority the way bugs do, but what can happen is a feature request is "too small to track", i.e. it's more effort to open an issue and fix it than to just make a PR, so just make a PR. i.e. if you want to fix typos, don't make an issue reporting the typos, just crack open the file in question and make the typo fix. Likewise if you want a specific new item in the game, or change the stats of a specific item slightly, either do it in a PR or cheerlead for it elsewhere.