Every case in the system is given a priority from 1 to 7, where 1 is the highest priority. The default for new cases is 3.
You can rename the text labels to suit your preferences.
To change the labels:
The best way to use priorities is to have a single, global priority scheme across all your projects, bugs, and features, so that every team member can always work down their list of cases in order of priority.
Here is a typical scheme you might use:
The Evidence-Based Scheduling reports assumes that you are going to implement features in order of priority, and they can show you different schedules based on how many priorities you choose to do. Assuming you have estimates, it will let you see how much it would affect your schedule to do those "fix if time" features.
Many older bug tracking systems had two fields, priority and severity.
Like most modern bug tracking systems, FogBugz only stores the priority.
Priority represents the importance of fixing a bug, and reflects a business decision as to how soon that bug should be fixed: all priority 1 bugs should be fixed before priority 2 bugs, etc.
Severity represents "how bad a bug is." For example, a bug that causes the program to crash would be considered high severity, while a small spelling error might be low severity.
But wait a minute ... if that spelling error is in a frequently-used part of the program, it might give an overall bad impression that hurts the product's sales. And if the crashing bug happens extremely rarely and only under very unusual circumstances, you may decide that the spelling error is actually more important. So you could imagine having a high severity bug with a low priority, or vice versa.
The FogBugz designers, though, decided that the only thing you need to enter and store is the priority. You need to decide which bugs are going to get done first, and you need to be able to search for high priority bugs or sort bugs by priority. But if a bug is low priority, the additional piece of information that it is "high severity" is merely confusing, since you're still not going to fix it until all the higher priority bugs are done.
FogBugz has a general principle of never asking users to input data that's not going to be used later. If we required bug submitters to decide both the severity and the priority of a bug, that would increase the amount of thought and work it takes to enter and manage that bug. Each time you enter a bug, you would have to make two hard decisions, only one of which really matters in the long run. Most of the time, the priority and severity are the same; when they're not, the severity is not worth keeping track of.
Our years of experience with bug tracking software have taught us that the most important factor in successful bug tracking is getting every bug captured in the system. We've found that in the real world, anything which increases the mental friction of inputting a bug will dramatically reduce the number of bugs entered. In this case, we strongly believe that requiring the person who inputs a bug to think about both the priority and the severity is more of a hindrance than a benefit to successful bug tracking, and the fewer required fields you have, the easier it is to enter bugs and the more useful FogBugz will be.