Most defect management systems have a field called Priority. It's usually a simple field with three to five possible settings that indicate how important an issue is. However, like Lady Gaga's wardrobe, the logic involved in choosing the best setting can be quite complicated.
I like to think of there being four components to determining priority: Severity, Exposure, Business Need, and Timeframe. Evaluating each component in sequence is a good process to use to reach a logical conclusion. However, each issue is unique and should also be evaluated on its sum total.
Severity addresses the prevalence and penetration of the issue. Prevalence is how widespread the issue is—perhaps it occurs in multiple modules in the application. Penetration is how much the issue hurts—can the user easily work around it or does it cause a system failure?
Exposure indicates who can see the issue. Is it restricted to just the internal development environment? Is the client exposed to the issue? Are end users able to experience the issue?
Business need is an evaluation of the effect of the issue upon productivity, relationships, and reputations. Does the issue cause lost productivity for one person or many or the client? Does the issue pose a potential for damage to the developer-client relationship; perhaps through missed deadlines? Does the issue pose a potential for damage to the client-end user relationship through the exposure of the issue to the end user?
Considering Severity, Exposure, and Business Need, Timeframe is how soon the gears should start turning to resolve the issue. A good rule of thumb is to establish a timeframe that correlates directly with each priority. In the context of pre-production environment, think of natural milestones in the development lifecycle to establish timelines such as in time for a build, within an iteration, or before release to production.