Some days ago I posted a message, titled "The art of bug reporting", which gave some tips to fill good bug reports. Today, I'm going to review this same process from the developer's point of view, who has to handle these reports.
Developers are often organized in workgroups; this way new bug reports can be easily assigned to one of these groups. This classification is done automatically, based on what the submitter specified in the respective field. Even though they can be reclassified (in case of bogus choices) by a team specially designed to review bugs (or individual developers). For example, GNOME has the Bugsquad team (which you can start to help now!), while NetBSD has no such workgroup (yet).
When the bug is assigned to a team within the project, it will easily catch the eye of one of its members. That developer can either do nothing (because the report is incomplete, doesn't have enough time to work at the moment, doesn't know how to solve it...), fix it immediately (if it's trivial) or assign it to himself (to deal with it in the future, and to note other developers that he's working on it).
If a report you are reading misses information or is incorrectly written, request more information from the submitter (putting the report in the appropiate state, like NEEDINFO or feedback). Remember to be polite, even if the report seems "useless" to you (I.e., it lacks a lot of details, points out an obvious thing, etc.). It's important to get collaboration from submitters, and bashing them won't help.
If you are going to fix it, do whatever is appropiate (you are a developer of that project, so you are supposted to know what's good or not ;). Note that if the submitter sent a proposed patch to fix the problem, and you used it, you should give credit where possible. This will make contributors feel better (which implies that they will send more patches).
And, at last, try to fix bugs as soon as possible. Forgetting about them will only make your bugs database grow; patches attached to bugs will become obsolete, some will not be reproducible any more (although the problem will still be there), the reporter may not be available any more to provide more information, etc.
