views:

134

answers:

5

We've got a nice (IMHO) setup where users can either use a web-based form or send e-mail to a particular e-mail address so that they can report a bug. If they do this, a record is created in the bug tracking system, and then all of the appropriate developers are notified by e-mail. Our more savvy users actually know how to use the bug tracker and enter their bugs in the system directly. We are thankful for those users.

Unfortunately, some users being the way they are, they are (of course) still sending e-mails directly to us personally, calling us on the phone, or (worst of all) finding us in person to describe the bugs verbally.

What do you do to encourage your users to use the bug reporting system you've arranged for them?

  • Do you refuse to accept bugs unless they are submitted via an approved route?
  • Do you accept bugs reported through other means, but gently (or sternly?) remind the users to instead use proper channels?
  • Do you not even bother with having "accepted routes" for bug reporting, and just take what you get?

And whatever means you use, how do you address the following:

  • Not making the users feel as if you are avoiding work by constraining their contact methods
  • Encouraging bug reporting (it's amazing how many users will just let bugs slide without reporting them until weeks or months later)
  • Cultivating goodwill and trust (cough) between your team and your users

I'm just looking for some general guidance on this issue. We had hoped by making things easier for them it would help the issue, and it has to some extent, but does anyone have some particular successful (or unsuccessful) methods to share?

+4  A: 

Integrate them with the process unsuspectingly

Something I would try is when you get an out-of-band report, formalise it as a bug, cc them in on the bug via email, and leave the bug in a 'needs checking' state and then request they read it to make sure its written right.

Its not a super solution, but Its more likely to coax them into understanding the benefits of the system, and realise their attempts to do it differently will ultimately be harder for them to do than just firing up their web browser and reporting it properly.

Kent Fredric
+4  A: 

I suppose we agree that the worst part are both the calling or personally describing the bugs (an email can be easily forwarded to the bug tracking system).

I usually demand that I need a screenshot or something that requires for them to be at the computer, so it'll be most convenient for them to just use email. If then they sent it to you instead of the tracker, you can gently remind them but there's usually no need to bother, ime.

I demand it by making it clear that I just cannot get it solved without that piece of information. That may be a screenshot as I said, but could also be a logfile or whatever makes sense in your case.

It's not that this information is actually relevant to the bug solving (though it might be), it's just a means to get them accustomed to associate bug reports to sending you some information that just cannot be passed on verbally.

Of course this would be awesome if it could be automatically sent (user presses a button and a proper email is sent to the right address with relevant content), there are tools that can be integrated into your programs to do so.

Oh, and I'd never reject a bug report. It's hard enough as you say to get the reports to reject some. What I do is to ask for further information if the description sucks.

Vinko Vrsalovic
I've had people *fax* screenshots :(
Kent Fredric
I keep lying (or telling the truth, depending) until they get it. "I have a special program that helps me detect the bug but requires the screenshot to be sent by email". And you'll have to accept that some people will never learn.
Vinko Vrsalovic
+3  A: 

Whenever you get a bug on the informal channels

  1. Mention to them that they can use the automated system (Not sternly, but suggest it as option)
  2. File a bug yourself, cc the concerned user and let him watch the discussions on the bug. After a few instances, your users will start using this route, as this gives them enough information and visibility regarding the bug they
    reported.
Krishna Gopalakrishnan
+2  A: 

Whoever reports manually, create an electronic issue for them. Make sure the electronic system tries to make them report electronically the next time, but don't push it too hard. Be happy they care and thank them for their feedback.

If these things are that troubling I suspect your real problem is quality related in some other form.

krosenvold
+2  A: 

Tell your customers that bug reports carry more weight with the PMs when the name on the report is not a company employee. Although you could report the bug yourself, it might just look like something that's only been encountered internally and doesn't actually affect customers, but if it comes from outside, there's a stronger priority to allocate time to work on fixing it because a customer has not only encountered the problem, but been so affected by it as to prompt him or her to go and fill out a formal bug report.

Rob Kennedy
doesn't really work for internal development, but I like this idea.
Draemon