Don’t Confuse a Bug’s Priority with Its Severity
Severity is subjective: those users who are not affected by a bug find it to have low severity (possibly zero). Those who are affected by it, and have no workaround find it a showstopper (high severity).<p>The consequences add to the severity. Not being able to save a document versus having your identity stolen versus an aircraft crashing are different severities. Severity fields that have four or five values can be difficult to use due to the orders of magnitude differences in consequences.<p>Since severity is experienced differently by different users, if only a single severity field is attached to a bug, it is somewhat tricky to use. A guiding principle should be that the bug reporter should imagine the circumstances of the &quot;worst-case user&quot;: the user who is most likely impacted by the bug, with the worst consequences, and set the severity accordingly. It can feel wrong to do this, though, when it seems that such a user is purely imaginary; there is no actual user who is affected in that way or to that extent.<p>Priority is nearly the same thing as severity, but from the perspective of the user being the project itself. A bug has high priority if the project is severely affected. Priority usually drives what gets fixed now, versus later.<p>The project cares about the users, so if a large number of users experience a high severity, that bug will likely be treated with priority. The project may also care about the largest users who bring in the most business, and other things like pride in its good reputation. It might give more priority to a bug that is more embarrassing.  Or it might give priority to a bug that is more widely publicized, such that there is attention on the project&#x27;s handling of it. A bug that creates a blocking situation in the project&#x27;s own development will typically be treated as high priority, even if it hasn&#x27;t been released to any users.