Most places evolve their own process based on their needs, but it will generally look something like this:
- Reproduce - No matter what, if the team can't reproduce it, it's going to be challenging to fix. It's not uncommon for team members to need to expand on the information in a help desk tickets so that a developer can reproduce and then fix the problem.
- Assign severity - This will usually be a 1 - 5 ranking but could be a different scale. It will usually have crashes, data loss, or something rendering the application unusable as the highest level, down to cosmetics and inconspicuous typos at the lowest. Some of the rules I've used are:
- Severity 1 - worst bugs - The program crashes, corrupts data, or can't be used for essential functionality.
- Severity 2 - bad - Major features can't be used without extensive, painful workarounds, intermittent crashes under some circumstances, the program becomes slow but not unresponsive. Invalid data being saved can also fall into this category.
- Severity 3 - normal - This is the garden-variety bug. It's annoying but there's a workaround that isn't too much of a hassle. Something more severe in part of the applications that's rarely if every used can also fall into this category.
- Severity 4 - minor - Splash page or other obvious and embarrassing typos, bugs with simple workarounds or non-buggy alternative ways to perform the same function can all fall into this category.
- Severity 5 - trivial - These are the minor gui issues, the typos in rarely used parts of the system and the like.
- Assign priority - Again, this is usually a 1 - 5 scale that indicates how likely it is that customers will be affected by the bug. The ranking will usually relate to how often customers use the task that triggers the bug, whether it's in a feature used by all customers or only some of them, whether there are viable workarounds or not, and so forth. How important specific customers are to your organization can also impact your priority ranking: in one of my previous jobs one of our customers was an extremely large amusement park chain. Any bug known to impact then was automatically a higher priority than it would otherwise be because they were extremely careful with their acceptance testing and anything we missed would bite us. Some examples I've used:
- Priority 1 - Fix immediately - Anything that impacts customer financials can fall into this category, as well as anything that leaves the system inoperable. It's not uncommon for embarrassing front-page typos to hit this category, too. Something that is making a major customer unhappy can land in this category if the major customer is important enough to your employer.
- Priority 2 - Fix quickly - Generally I've mostly used this category for things that don't have to be done yesterday but should be fixed as soon as is reasonably possible because it is causing the customer and other users to spend extra time and have extra hassle.
- Priority 3 - Normal - It's not urgent, but it should be fixed in the next major release.
- Priority 4 - Minor - This is for the bugs that don't really bother anyone. These are the ones that will typically get fixed when someone on the team has a bit of extra time after finishing the 1, 2, and 3 bugs.
- Priority 5 - Wishlist - In my experience bugs at this level generally don't get fixed unless someone is really bored or there's an intern in need of some easy tasks or someone fixes them while working on something else. They're in the system because they've been reported, but the organization and the customers don't really care about them.
All these guidelines depend a lot on how your organization works and what they consider most important for their customers. Your team will give the Help Desk tickets their views on priority and severity, then someone who is more intimately involved with the overall business process will rank them for prioritization for developers to fix.
Your part in the process is primarily to provide enough information to allow the business stakeholders to make an informed decision.