How to define the priority of a bug

Some time ago a tester told me we didn't have a formal criteria to define the priority of a bug, and that the few criteria he know were not easy to use. After some thoughts, we decided to work together to define a criteria that would be good for us.

The result was a compact definition for five priority levels for bug fixes:

• Minimal: A bug is said to be of minimal priority when its occurrence:
• Do not cause any damage to the stored data;
• Do not interrupt the usage of the software;
• Is hard to be observed* and does not bother the user.
• Low: A bug is said to be of low priority when its occurrence:
• Do not cause any damage to the stored data;
• Do not interrupt the usage of the software;
• Is easy to be observed but does not bother the user.
• Normal: A bug is said to be of normal priority when its occurrence:
• Do not cause any damage to the stored data;
• Do not interrupt the usage of the software;
• Is easy to be observed and bothers the user.
• High: A bug is said to be of high priority when its occurrence:
• Causes some damage to the stored data or interrupts the usage of the software;
• Is hard to be observed.
• Maximal: A bug is said to be of maximal priority when its occurrence:
• Causes some damage to the stored data or interrupts the usage of the software;
• Is easy to be observed.

* A bug is said to be of hard observation when it only occurs in extraordinary use cases, it means, in situations that are rarely provoked by the user.