In the world of software quality engineering ("SQE"), we have a notion of "steps to repro", or "how can i reproduce this bug?".
This means a meticulous, exhaustive list of steps, even ones considered obvious, that, if followed by grandma, will create the bug in question.
for example, a user might say "kjams crashes when i play a song", so then i go play a song and it doesn't crash, well, the problem is they left out some steps. the steps might actually be:
- the computer has 1 GB of RAM
- the library has 100,000 song in it
- run kjams lite
- play the song "foobar" which is an MPEG1 file (included in bug report)
- at the 25 second mark, kjams will crash
Do you see the difference? I didn't have ANY of those steps. I have an 8 gig computer, my library has 10,000 songs, i'm running kJams Pro, i was playing a random song, and it was an MP3+G file, not an MPEG1, and i only waited 1 second and did not see a crash. In this case i didn't come any where close to "reproducing" the conditions in which the crash occurs.
So, when i ask you for "repro steps", i'm really asking for every single bit of information necessary to re-create the environment in which the bug occurred, and i'm asking for the file that it happened on too (if that's required), including your prefs files and "kJams Library" if necessary, as well as the list of steps i must follow to get to the bug, which may involve several steps.
Also remember that i may not get to look at the bug for a while, so imagine i'm going to look at it a year from now and that i will not remember any conversations we've had about it. the bug report should include EVERYTHING necessary to get a tester from absolute scratch to causing the bug to happen.
Also read this about just saying "it doesn't work"