Some Data that should be incorporated in a Effective Bug report, this is not exhaustive but yet informational.....
The first aim of a bug report is to let the programmer see thefailure with their own eyes. If you can't be with them to make itfail in front of them, give them detailed instructions so that theycan make it fail for themselves.
In case the first aim doesn't succeed, and the programmercan't see it failing themselves, the second aim of a bugreport is to describe what went wrong. Describe everything indetail. State what you saw, and also state what you expected to see.Write down the error messages, especially if they havenumbers in.
When your computer does something unexpected, freeze. Donothing until you're calm, and don't do anything that you thinkmight be dangerous.
By all means try to diagnose the fault yourself if you think youcan, but if you do, you should still report the symptoms as well.
Be ready to provide extra information if the programmer needs it. Ifthey didn't need it, they wouldn't be asking for it. They aren'tbeing deliberately awkward. Have version numbers at your fingertips,because they will probably be needed.
Write clearly. Say what you mean, and make sure it can't bemisinterpreted.
Above all, be precise. Programmers like precision.