Hmm

So here are my personal thoughts on bug reporting, in general. I normally wouldn't say much, but it's a good blogging topic for me today.

Please, if you're going to take the time to file a bug report, at least attempt to make good use of that time. If the report is really vague or otherwise unhelpful, it will probably just be closed due to not being "reproducible." Then you've wasted your own time in submitting the report, and the time of the person who has to review the report.

What I mean by "unhelpful" or "vague" would be a report like this (imaginary report, but I'm stealing ideas from ones I've seen before):

Summary: "XXX does not work"
Description: "XXX does not work, I can't believe you missed this!"
Steps to Reproduce: "Try it!"

If your report looks anything even marginally close to this, it's a pretty safe bet that you won't see much action on it. Even if you think it's mind-bogglingly simple to see the issue, do NOT assume that's the case.

I realize that not everyone is going to be providing ideal reports, nor do I think they should have to. But if your report doesn't contain certain things, then it's not really a good use of anyone's time. Your reports should have at least these three things in it:

1) A good description of the problem. Just saying "XXX doesn't work" is unhelpful. Abusing the person who's reading the report is unhelpful. Telling us what the feature is, how you expected it to work, and how it actually worked is helpful. That lets us know a) what feature(s) are involved in the bug, b) where the break from what you expected and what you got actually happened. By doing this, you can help us determine whether it really even is a bug at all or not. There are plenty of times when someone reports a bug, and after a number of exchanges we finally figure out that the user thinks the behavior they're seeing is a bug when in fact, that's the behavior they should be seeing. For instance, I recall once having a long discussion with a user about how some of their text strings weren't showing up visually correct only to find out that they didn't understand keyboard mnemonics. If they had said what they expected to see and what they actually saw, it would have saved me a ton of time.

2) Good steps to reproduce. This field should never be blank, nor should it ever say "just run/try my project." If you aren't attaching a project, then you need to explain exactly what steps to take to see the issue. Also describe the configuration of your IDE, platform, etc. If you are attaching a project, then you need to describe what we have to do to see the issue when running the project. I can't count how many times I've closed reports as not reproducible because of this stuff! I closed one before because a user was claiming visual glitches would happen when they did an action. Turns out that the glitches only happen if the toolbar icons are set to show the small icons only. Took a lot of frustration and time on both ends before that report could be verified. And I've also closed a number of reports with attached projects because I couldn't figure out how to see the problem. Turns out that I needed to use the keyboard instead of the mouse to see the issue (or something along those lines).

3) Whenever possible, attach a simple sample project. If it's a visual issue, take screenshots. Something, anything! The reports which do this tend to get fixed the fastest from what I've seen. I attribute it to the fact that it's easy to reproduce the issue, and when it's easy to reproduce the issue, a lot of times we've gotten something narrowed down to a particular section of code, so it's easier to fix. Huge projects, or no projects mean that there's been no effort to figure out where the issue is, so it takes a lot longer to fix the bug. I know that for myself, I'm more apt to fix bugs in my "spare time" when they're narrowed down like that. If it only takes me 5 minutes from start to finish, I tend to nail those while waiting for something else to happen (lunch to finish cooking, etc). But if it takes more than 5 minutes, I move on.

So if you're wondering what it is we really need when you're filing bug reports... or perhaps you're wondering how to best jockey for your bug to be fixed.... then really, what you need to do is provide as much information as possible. The more information you can give us, the easier it is for us to get the bug fixed.

Speaking for myself, I'm always happy to fix bugs. The faster I can fix them, the happier I am about it. I usually browse the incoming bugs list and assign the ones that look easy to myself and fix them during my "in-between" time even though it's not scheduled for me to do so. So it's not like this is some sort of official edict which says "unless you do these things, no one will care! Muhahahahaha!" This is more my way of saying "hey, I know that I, personally, look at the bugs which appear easiest to reproduce and fix -- so follow these steps if you really wanna catch my attention." However, I think it's safe to say that these sort of quasi-rules will catch other's attention as well and certainly helps us in getting issues resolved quickly.