Canned responses: a great and a terrible thing

I’ve begun doing a lot of bug triage lately for Ubuntu, because it really needs it. New bugs are reported faster than they’re fixed, and the number of bugs is rather staggering. Many of these were never assigned a package, and so no particular bug-fixing crew is even aware of them. So I dive in and do what I can to decide which bugs should go where, and I try not to make a mess of things. Many bugs have nowhere near enough information in them to have a hope of finding the bug and fixing it.
This is where the “canned response” often comes in. I may not know much about sound problems, or hardware detection, but I can go to the bugs/responses page and get a canned response that will tell the bug reporter what we need to know so that we can find the bug and make everybody’s life better. Great, fantastic tool, right? Of course it is! But a problem exists that is really endemic to canned responses everywhere: they sound like canned responses, and give the user/customer/bug-reporter the impression (subtle or not so subtle) that we don’t particularly care.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can’t fix it, because your description didn’t include enough information.

Please include the information requested at https://help.ubuntu.com/community/DebuggingUSBStorage as separate attachments.

Horrible. It starts well, by thanking the user and acknowledging that they have spent a precious thing, their time, in reporting a bug to us, but if you get more than a couple of these responses, you’ll know it for what it is: canned. There’s nothing worse than an insincere “thank you”, and when every “thank you” is worded exactly the same, it sounds insincere whether it is or not.

The canned response gets worse from there:

1. “Unfortunately we can’t fix it”. Whoa. What? Talk about a defeatist attitude! Who says we can’t fix it? We don’t even know what it is yet!
2. “because your description didn’t include enough information”. It’s not bad enough that we’re already defeated before we’ve begun, but it’s all your fault! Yes, you. The person we just thanked. We can’t fix the problem, and it’s all because of you. Now… this statement may be true, but that’s certainly not the best way to encourage participation. We don’t want finger-pointing, we want to fix bugs.
3. “Please include the information requested at [URL]“. So we can’t fix it, it’s your fault, and we know what info we need, but rather than tell you, we’re going to make you do extra work to find out what we need so you can give it to us. Granted, sometimes what we need is far too wordy to fit neatly into the bug tracking system, and the URL saves a lot of space, but it can be rather off-putting to somebody who just wanted to let us know there’s a problem, and is now being asked to do all sorts of work. For the canned response I’ve chosen for my example, the steps at the URL are not all that long, and it would be far friendlier of us to simply copy and paste those steps into the bug report. Save the user some time, increase the likelihood that they’ll respond with the info. Everybody’s happy.

What to do? Well, the “obvious solution” is to rewrite the canned responses so that they’re friendlier. That would help, but it wouldn’t resolve the core problem, which is that canned responses end up sounding like canned responses, and will give people the impression we don’t particularly care. The only real solution is for bug triagers to use the canned responses without actually using them. OK, I know, sounds awfully zen and full of BS when I put it like that, but what I mean is, you have to copy and paste the canned response, but then *edit* it.

1. Change the thank you to something personal, or even omit it entirely.
2. Never, ever say “we can’t fix it”. You can say “we need more information”, or “we need to know how to recreate the problem”, or even “that’s a wishlist item, we’re not going to fix it”, but never tell the user (or yourself) that you can’t fix it. Because most of the time that’s simply not true.
3. Don’t blame the user. Ever. Even if they are at fault. Asking them to “please provide more information to help us solve this” is infinitely better than “because you didn’t provide enough information”. Always make the user feel like you are asking for a favor rather than requiring them to perform specific steps.
4. Look at the URL you are giving the user. Is the information short enough to be included entirely? Do it! Is the information at the URL even applicable? I’ve found that some of the canned response URLs are horribly GNOME-specific. That’s fine for most users, but I like triaging Kubuntu bugs, and asking somebody running kdm to stop their gdm is just going to be confusing, frustrating, and a poor experience for all involved (including yourself).
5. Be human. Ubuntu brands itself as “Linux for human beings”. Don’t act like a robot, and don’t treat the bug reporter like a robot. Canned responses fail utterly in both these respects. Even if you just change a couple words in the canned response, it makes a difference.