Bug Tracking As Communication

June 7, 2011

Chapter 10 – Written Communication

The Mozilla Labs Ubiquity team tracks bugs with the Trac issue tracker, and they also use it to educate their team about user experience design. As an open source project, Ubiquity gets contributions from people outside of the team in the form of enhancement requests and patches. Each patch needs to be evaluated to make sure that it fits with the existing user experience.

Enhancement requests cause debates. This debate gives the person entering the request a chance to understand the priorities of the team. They need to discuss the feature and how it will fit into the product before it will be added to the release. This process allows the Ubiquity team to educate potential new members about their particular views on user experience.

Your bug tracking system is probably the most versatile piece of software in your organization. It tracks bugs, but it also handles backlog management, task assignments, release planning, and design discussions. Systems like Bugzilla also support the coordination of code reviews and other team-oriented tasks.

Your bug tracking system is where you should talk about specific issues and specific solutions. Working remotely means you can’t talk about a bug in the hallway so you will need to rely on your bug tracking system more than usual.

The comments in your bug tracking system can be used to communicate issues and review decisions. The bug tracking system is also another opportunity to show other people how you work. Writing more of a comment than “fixed” will give you the chance to talk about what you changed and why you changed it.

When you write comments in a bug it is important to talk about the changes you made, but also why you made them. Explain your thinking about the way you fixed a bug. Why did you change this particular API or UI the way you did? You should also reference the files you changed when making the bug fix.