The Former Weblog of Peter Ahé

Several years ago I wrote a guide for submitting error reports to the Systems Staff back at my University in Denmark. The problem seems to be universal, so I think I will repeat the important elements of a good error report:

• What did you want to do?
• What did you do?
• What happened?
• What did you expect?
• Don't diagnose the problem, stick to reporting.
• Have you included all relevant information so that the problem can be verified and/or reproduced?

Here are some examples of bad error reports:

From an email: I can't read email.

Since the user didn't include any additional contact information, it was quite hard to help him. His email account looked fine and sending an email asking for more information seemed pointless.

My program doesn't compile

Strictly speaking, your program probably shouldn't compile. That's the job of the compiler. ;-) If the compiler rejects your program, you should provide enough information to reproduce the error message. In most cases, this means include the source code of your program and include the error message you saw.