I'll probably turn this into a wiki page once we're in agreement, but I wanted to get some feedback, especially from the "old timers" on the project, how to treat the common categories of imperfect defect reports we receive.
1) Obviously, a well-written defect report that describes how to reproduce the problem, and where the steps work as described, for those we simply mark the defect as "confirmed", indicate our test platform and maybe adjust the severity as appropriate. We're done. 2) In some cases we need to stare at the bug report a little longer, but we figure it out eventually. We do it like #1, but maybe add some additional explanation in the comment, to make it easier for the developers to reproduce the problem. Maybe we attach a test document if that would save time for them. 3) In some cases we see a bug report where the user misunderstood a feature. The user is obviously incorrect and the thing they are reporting is "working as designed". In such cases I add a kind note explaining that this is working correctly, point to documentation if readily available, and mark the bug report as Resolved/Invalid. It is "Invalid" because it is not a bug. 4) In some cases the reporter of the bug gives partial detail, but not enough to reproduce. We need more info from them, maybe their document, maybe more details. In that case I request more info in the comment field and set the "needmoreinfo" keyword. I'll then wait a couple of weeks -- no rush -- and if the user has not provided the needed info, then I'll close the bug as Resolved/Irreproducible. If more info comes later we can always reopen it. But we don't want to keep unconfirmed bugs in the queue forever. 5) In some cases you see a report that is giving a vague report of a crash, but absolutely no useful detail on what caused it. They are not reporting on an action that crashes OpenOffice. They are merely saying that there are "random" crashes. I send these users to the support forums and close the issue as Resolved/Irreproducible. But I'm open to persuasion if someone thinks they should be marked as Resolved/Invalid ??? 6) Similar to #5, in some cases it is clear the user is looking for support. They are asking "how to" type questions. Or they are expressing urgency, "Please help quickly, since my paper is due on Monday". Do them a favor and send them to support and then resolve the issue per #5 7) In some cases the report is not really a bug, but a request for an enhancement or even a new feature. I leave these unconfirmed but change the Issue type field from "Defect" to "Enhancement" or "Feature". Any other common cases we should talk about? -Rob
