How to Respond to and Fix A Bug

Here’s a small highlight from pestle’s issue tracker. A user ran into a situation I hadn’t considered when I created a command. I wrote my command assuming there wasn’t already a di.xml file in place, or if there was that it would already have a certain set of nodes. This user already had a di.xml file they’d created manually.

Key parts of this response

• Respond as quickly as possible to acknowledge you’ve received the issue. Do this in a human way, not a robotic way. Even if the issue’s going to be something you can’t fix, acknowledging the effort with a human response is key if you want future participation of this user.

• Interact with the user to get a reproducible test case. Do not give up if the user seems to be unhelpful – not everyone works on systems software all day.

• Try to triage the issue in a day or two and decide if it’s something you’re going to fix. If the issue is a problem with the code/system, state explicitly that it’s not the user’s problem, that it is a bug.

• If possible, provide the user with some work arounds while you’re working on the issue. If you’re not going to fix the issue, apologize and suggest some other possible solutions.

• Set clear expectations on whether you’re going to 1. Fix the issue; 2. Leave the issue but you’re open to pull requests from other 3. Not going to address the issue, because it falls outside your scope-of-vision for the project.

• Follow up on your expectations

• Regardless of your choice, thank the user for their involvement is as human a way as possible

The most important part of this is to remove boilerplate responses (or include personalization in your boilerplate). Users aren’t dumb – if you’ve got a robo-script to respond to issues (or an employee who’s acting like a robo-script) that’s going to turn people off. When users are getting personalized attention, they’ll return that personalized attention to you or your project.