Bug Triaging Guidelines

= What is Triaging? =

Bug triaging refers to assuring the quality of existing bug reports. The job of a bug triager is to:


 * Work towards Bug Reporting Guidelines being met.
 * Confirm or Reject issues.
 * Categorize and prioritise reports.
 * Find duplicates.

Lifting these tasks off of the hands of developers will ensure they can easily find things to work on and generally be as productive as possible. Awesome!

= How do I start? =

No coding knowledge is required! Anyone who is somewhat familiar with the structure and functionality of our project, its history, and/or follows the development process on Github / forums, is a great candidate for helping with Bug Triaging.

If you're up to the challenge, check out the following links to find something to work on:


 * Activity feed
 * Unconfirmed bugs
 * Uncategorised issues
 * Bugs not updated for a long time - check if they still apply

= Improving fields =

Note: Some fields may require additional permissions to be able to edit them. You can request these permissions on the forum. In any case and in the meantime, you can always post a comment with your suggested changes, a member of the project will shortly apply them if we agree.

Subject
A summary of the symptoms and/or the causes of the issue. Preferably just the symptoms, as causes are more difficult to ascertain and easy to get wrong.

Additional information / tags like environment, versions, components, etc. should be removed from the summary and communicated through other fields.

Any typos or grammatical errors in the subject should be fixed - they might not seem like much of an issue, but over time will add up to a significant amount of time wasted as every reader has to mentally pause for a second. Misspellings will also trip up the search function.

Description
While it may be tempting to 'clean up' the reporter's description, it would be difficult to keep track of the changes to it, or make sense of the following discussion once the original topic has been altered. It can also be frustrating for the original reporter to have part of what they reported be removed or changed without their consent.

For these reasons, editing the original description is generally discouraged. On particularly long issues, a header or footnote can be added to the description that summarizes the current state and/or resolution of the issue.

Category
The Category field refers to the code component that contains, or is suspected to contain the defect.

If more than one category applies, always choose the most specific category.

Priority / Severity
Severity refers to the impact of the defect on the software and the user.

Priority is chosen based on the importance of fixing said defect. For example, a crash that only occurs under an unsupported environment would have a High Severity, but a Low Priority.

Indicators for a lower priority:
 * Only occurs under very specific conditions that can be worked around by the user.
 * Compatibility issue that occurs due to OpenMW handling content file errors more strictly, and can be easily worked around by fixing said content.

Indicators for a higher priority:
 * Regression from a previous release that is likely to make users angry
 * Possibility of data loss or breaking workflows

OS
The operating system (OS) should initially be set to the OS of the reporter. If the issue gets Confirmed under another OS, set the OS to 'Other' to communicate the issue as non-OS specific.

= Finding duplicates =

Most of the time, duplicates are caught immediately after being reported, by a member of the project that recalls the original issue. However, due to our fading memory and the growing number of issues this is not going to be a sustainable solution over the long run.

To manually find duplicates, the first tool to use is the search function. This function is somewhat clunky and only matches exact keywords. You may need to come up with many different wordings to find the actual duplicate, assuming you can find it that way at all. Failing that, you may have to read through the list of all issues of that particular category (assuming the category is non-ambiguous and the original issue was categorized).