0.2 Submitting bug reports

Introduction

"it doesn't work"

Give the creators of the tool a little credit for some basic intelligence: if the program really didn't work at all, they would probably have noticed. Since they haven't noticed, it must be working for them. Therefore, either you are doing something differently from them, or your environment is different from theirs. They need information; providing this information is the purpose of a bug report. More information is almost always better than less.

Many programs, particularly free ones, publish their list of known bugs. Check this to see if the bug you've just found is already known or not. If it's already known, it isn't worth reporting again as a new bug . However, if you think you have more information than the report in the bug list, you might want to contact the developers anyway to add to the bug report. The new information you have may enable them to fix the bug more easily/sooner.

Specific developers / companies / groups have particular ways they like bugs to be reported. If the tool comes with its own set of bug-reporting guidelines, read and follow them!

"show me", or "show me how to show myself"

One of the very best ways you can report a bug is by showing it directly to the developer - either in person, or via a remote support session (like webex). Demonstrate the exact thing that goes wrong. Let them watch you run the software, watch how you interact with the software, and watch what the software does in response to your inputs.

They [should] know that software like the back of their hand: which parts they trust, and which parts are most likely to have faults. Intuitively, they know what to watch for. By the time the software does something obviously wrong, they may well have already noticed something subtly wrong earlier which might give them a clue. They can observe [almost]everything the system does during the test run, and they can pick out the important bits for themselves.

This may not be enough. They may decide they need more information, and ask you to show them the same thing again. They may ask you to talk them through the procedure, so that they can reproduce the bug for themselves as many times as they want. They might try varying the procedure a few times, to see whether the problem occurs in only one case or in a family of related cases. If you're unlucky, they may need to sit down for a couple of hours with a set of development tools and really start investigating. But the most important thing is to have the programmer looking at the computer when it goes wrong. Once they can see the problem happening, they can usually take it from there and start trying to fix it.