>I'm NOT saying that MS should come up with dialogue between submitters and debuggers (though that would be most sensible) when MS can't reproduce a reported bug. I am saying that MS needs to find a way to INFORM a submitter of one fo the two possible outcomes: reproduced and logged, *or* DROPPED. That way a submitter could at least submit another, with more information.
>
>Surely the wizards of MS can come up with a nice clean simple way to achieve this without unduly burdening their people with 'excessive' paper work!
>

Jim,
I'm going to disagree with you.

1. I don't think a bug EVER gets dropped. With systems I deploy, I keep track of all bugs reported. The reports with reproducible steps get higher priority than the ones where I have to guess and/or go back to the user. When I get to a point where the reproducible bugs are corrected and I have time, I go back and try to work through the others. I think many developers work this way.

2. MS has posted (and I agree with it) that bug reports should contain steps or code to reproduce the "buggy" behavior. The onus is put on the developer to do this. If they don't/won't, I don't think they have have much say in the matter. If someone took the time to 1) figure out what they did and 2) write it down, it makes it easier all the way around. If a user simply fires off a bug report saying "This is broke, fix it", that gets put in the LOW priority bucket.

Whil Hentzen spoke a few years ago to a group within the company I was working for. His stance was a bug was not a bug if it couldn't be reproduced. If you can make it bomb, just tell MS how you did it. You know the most about what you did to make it not work.