I read a blog post from the authors of the CMS I use in several sites a couple of months ago about bug reporting. The post originated from its forum, where the core developer responded to criticism about bug report/feature request rejections.
He wrote a big rant about how users should do some research before filling bug reports, so the reports will be done right. Also, this developer wrote how he is fed up with those reports which are missing some critical information he needs. Asking, those information of course consumes time, which he does not have.
I have something in mind which I want to share with you.
First of all, if you want some information, you have to ask it. Currently, in the reporting form of the system they use, contains fields for
- software version
- Who is it assigned for (how the hell end user would know that?)
- version of the module (if it’s a bug of the module)
- severity (I don’t think that user necessary knows this)
There are no hints about what kind of information needs to be to written into the description field or any link to such documentation. So why do you blame your end users for crappy reports? How about looking in the mirror? You have to educate your users for writing better reports and guide them through the process. Just putting link to an example of “perfect report” may be enough. Or even better, show it side-by-side on the form. If you need a lot of technical details, you could (and should) use some kind of an automatic error report system.
Secondly, there was a point that the developer doesn’t have time to check all existing combinations of settings, plugins and software. All I have to say is that, don’t make such combinations possible then. Don’t allow users to set any settings, or install any plugins. Of course it has impacts to your user base, but does it matter? At least you don’t get stupid and imperfect reports! Of course, there could be thousands of combinations and you cannot test them all. That’s why you may have to deal with incomplete reports and ask for more details. It’s the trade-off you need to take (in my opinion).
I also like to point out that customer service is part of our job in these days as a developer. So if you don’t want to do that, hire someone to do it for you.