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 to make sure the relevant developer sees it.
 * Find duplicates.

= How do I start? =

Look at the Activity feed for recent updates or work on the list of unconfirmed bugs.

= Detailed explanation of fields =

Summary
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.

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 there happens to be an overlap between categories, 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.