Severity and Priority of Issues

Tags are provided to rate both the severity and priority of issues for the Maqetta development team:

• Severity is used to indicate how "bad" a problem is. It's a more objective rating that in theory should typically stay constant throughout the life of the issue.
• Priority is used as a project management tool to indicate how important an issue is for the current release, milestone, and/or sprint. Because it's used for planning, the priority value is more likely than severity to be dynamic over the life of the issue.

Severity

The available tags for severity are as follows:

• Severity 1

  • Critical customer/product impact. This indicates you are unable to use the overall product resulting in a critical impact on operations. This condition requires an immediate solution.
  • The product is unable to operate or the product caused other critical software to fail and there is no acceptable way to work around the problem.

• Severity 2

  • Significant customer/product impact. This indicates the product is usable but is severely limited.
  • Severely limited can mean that a task is unable to operate, the task caused other critical software to fail, or the task is usable but not without severe difficulty.
  • A serious performance degradation might fall into this category unless it was so bad as to render the system completely inoperative.
  • This can mean that function which you were attempting to use failed to function, but a temporary work-around is available.

• Severity 3

  • Some product impact. This indicates the program is usable but a task runs with minor issues/limitations.
  • The task that you were attempting to use behaved in a manner which is incorrect and/or unexpected, or presented misleading or confusing information.
  • This can include documentation which was incomplete or incorrect, making it difficult to know how to use a task.
  • This can include poor or unexplained log messages where no clear error was evident.
  • This can include situations where some side effect is observed which does not significantly harm operations.
  • Documentation that causes the customer to perform some operation which damaged data (unintentional deletion, corruption, etc.) would more likely be listed as a severity 2 problem.
  • This can not include cases where customer data is inaccurately stored, or retrieved. Data integrity problems require a severity of 2 or higher.

• Severity 4

  • Minimal product impact. This indicates the problem causes little impact on operations or that a reasonable circumvention to the problem has been implemented.
  • The function you were attempting to use suffers from usability quirks, requires minor documentation updates, or could be enhance with some minor changes to the function.
  • This is also the place for general Help/DOC suggestions where data is NOT missing or incorrect.

Priority

The available tags for priority are as follows:

• Priority Critical
  • Cannot ship the release/milestone until completed.
  • Should be addressed immediately before any lower priority items.
• Priority High
  • Part of the "must-include" plan for the given milestone
• Priority Medium
  • Highly desirable but not essential for given milestone.
• Priority Low
  • Desirable for given milestone but not essential, should be pursued if opportunity arises to address in a safe and timely manner

Bugzilla Mappings

Bugzilla comes with its own terms for handling severity and priority. Below is a table showing how we will map those to the terms used above:

Severity

Bugzilla	GitHub: Maqetta
blocker critical	Severity 1
major	Severity 2
normal	Severity 3
minor	Severity 4
enhancement	do not use*

* NOTE: Do not use the enhancement severity in Bugzilla, as it does not accurately denote a level of severity.

Priority

Bugzilla	GitHub: Maqetta
P1	Priority Critical
P2	Priority High
P3	Priority Med
P4 P5	Priority Low