6

I have an issue tracking system, but sometimes users report bugs directly to me in an email.

If I'm responding to a bug report in an email, what's a good etiquette to use? Do I thank them for reporting the bug? Do I apologize for it ? Is there a good template anywhere?

Improve this question

3 Answers 3

Reset to default
16
  1. Thank them for bringing it up to your attention.
  2. Reply back with the defect number from the bug tracker. Yes, that means you need to enter the bug yourself.
  3. Verify that you have all the details you need to recreate the bug.
  4. Bonus points if you can give them an estimate of its priority and when you might be able to fix it. It's also fair to explain your prioritization process and state that you'll update the defect ticket after investigation and prioritization.
  5. Double bonus points for politely pointing out that there is a bug tracker that they could use in case they didn't want to wait on an email reply.
Improve this answer
6
  • 9
    I wouldn't do 4. Once it's in the issue tracker and if they have access to the tracker, I'd just provide them with a link so they can follow status. I also don't want to be too hasty with prioritizing or estimating a defect until after I've had a chance to think it through. Once more information is available, the issue tracker can be updated to provide it. If it's not a public issue tracker, I don't want to expose too much about my internal processes.
    – Thomas Owens ♦
    Commented Oct 12, 2012 at 14:28
  • 2
    @ThomasOwens - I kind of struggled with that one as I don't like to pin down specific delivery times unless I absolutely have to. I was trying to balance open communication vs. overcommitment. If you can, I think it's fair to give an idea of the overall priority in order to help the end user set their expectations correctly. But there's no doubt that this is an area that can be abused by end users.
    – user53019
    Commented Oct 12, 2012 at 15:15
  • 3
    My thoughts might be a little reactionary. I've worked in environments where the customer(s) have tried to micromanage engineering projects. I prefer to have well-defined interfaces into the development process, but try to hide the implementation details as much as possible (exposing relevant parts to the relevant stakeholders). It does depend on who you are working with and the project culture.
    – Thomas Owens ♦
    Commented Oct 12, 2012 at 15:19
  • 1
    @ThomasOwens - you're spot on with those comments, and I couldn't agree more. I've had internal clients from other divisions try to micromanage my team's strictly internal documentation. That attempt to "assist" us got knocked down quickly. Likewise, I've had clients that really appreciated knowing that yes they found a bug, but it simply didn't make the priority cut. They understood the limited time available and agreed with the decision.
    – user53019
    Commented Oct 12, 2012 at 15:59
  • Interesting. We struggle with 4. But we have a complication because we have a partner ->* customer structure, and we inform the partner who informs their customers. This means that we give the partner quite an informed status including priority, and of course, they have their own view, and often question the priority we have given, and in comes the micro management especially if they have significant connections with the executives. I have come to thinking that less information is best.
    – Gavin Howden
    Commented Oct 13, 2012 at 20:14
4

Thank them for reporting the bug.

And perhaps:

  • Point them at the issue tracker, explaining to them that although bug reports via email are welcome, reporting them in the issue tracker is more efficient (you'd get to them faster),
  • If the bug is known, tell them about it (in layman's terms). If it's already in the issue tracker, point them at it.
  • If the bug is brand new, register it in the issue tracker yourself and explain to them how they can follow its progress.
Improve this answer
3

This depends greatly on whether you mean an internal user, an external user or paying customer.

You can't point some people at issue trackers. I think the first two answers are good and a combination of elements is set by the user and how they are related to what you do.

  • Thank them for bringing it to your attention
  • build as full a picture as possible about the bug (if it's via email forms, you can grab their environment vars through the browser - which helps)
  • Assure them that the bug/issues will be attended to by the team ("we're always looking to improve our user experience"...)
  • NOTE: If they are a paying customer, then priority is likely to be high if money/transactions are involved.
  • Add it to an internal tracker (if you have one)
  • Assign it a priority based on the severity/importance
  • Once its been through testing, QA and released, contact the user who found it and let them know its fixed and thank them again

This is generalised, but liaison with users of any sort is really important.

Hope this helps.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.