...

1. If the system is functioning properly, there should be more issues at a given priority level than at the next higher level.  Think of it this way.  The purpose of priority level n is to find the important stuff out of the pile of issues at priority level n+1.  A priority level can't do that if there is little discrimination against neighboring levels.  Or put another way, if everybody is somebody then nobody's anybody.
2. The distribution of priorities should apply to future releases as well as the current release.  It is not helpful to insist that everything that is not done right away is therefore a low priority.  That just makes it hard to find the important stuff in the future.  This is why priorities are relative to a release.  (This has some limits.)
3. Priorities may change over time.  Neither importance nor urgency are immutable.
4. Priority values are under control of the Assignee.

Processing New Bugs

Issues are created with status New.  Until they have been examined for the first time, nothing about them is known with any certainty.  Thus New issues are not counted in most release or quality metrics.  What is tracked is the number of New issues and how long they have been New.  It is important to move issues out of the New status promptly.

When moving an issue from New to Open status a reviewer should ensure the issue:

• is basically understandable
• has a reasonable Priority
• has a reasonable Project / Component / Assignee
• has a reasonable Fix For version

Priority, Component, Fix For etc. may all be refined in the future based on a more detailed analysis.  What is important is that the initial classification of the issue brings it to the attention of the appropriate people.

It is not necessary to fully understand a bug in order to open it.  The standard, especially during high resistance, is to understand enough about the bug to identify likely showstoppers for the release.  Reproducing the bug, investigating its cause or anything else that increases our understanding of the bug are all good but should not prevent the bug from being opened promptly.

Closing Bugs

Once an issue has been resolved its final transition is to Closed status.  An issue is closed only when its resolution has been verified against the MASTER repository.

Labels (a.k.a. keywords, tags)

In general, teams or individuals may label their issues as they see fit.  There are, however, a set of common labels that are defined project wide.  These labels should be used as defined and should not be used for other purposes.

...