Tuesday, December 28, 2010

Triaging Issues: The Wave-y Way

Note: This blog post was originally written to be posted on the Google Wave blog, but did not make it out before the cancellation of Wave. I am posting it here in case it is useful to Wave open-source developers in the future.

In developer relations, one of our core roles is to respond to the bugs and feature requests for our APIs, and we do it both because hearing what developers want helps us shape our APIs, and because understanding the bugs that developers encounter is one of the best ways to deeply understand an API. As a general rule, we try to respond to all new issues within a week of their filing, and we usually accomplish this by holding a weekly triage meeting with colleagues to review new issues. Back when I worked on the Maps APIs, we were all in the same office, so we'd just crowd around a table with our laptops and mash through the bugs. But, now, on the Wave APIs team, my colleagues are spread entirely across the world, with me in Australia and them in both coasts of the United States. So, we needed a new way to triage, and being on the Wave team, we went the obvious route: use Wave!

For our first weekly meeting, we simply met in a wave and pasted the untriaged issues ("Status-New") from our Google code issue tracker into the wave. Then we'd look at the issues and reply beneath the ones we were checking out to lay dibs on them, so we worked on whatever bugs were most up our technical alleys. While we were researching a particular bug and had questions about it, we could start an inline conversation beneath the bug, so in the end, we could both work in parallel and in collaboration. This way, we were able to both triage many bugs and feel confident in our triaging, since we could bounce ideas off colleagues easily during the process.

After the first meeting, I started thinking that I could probably whip something together with our APIs that would streamline the triage process even more, and maybe make it possible for other teams to follow the same process. Around the same time, the project hosting team announced an Issue Tracker data API - perfect timing!

So, with the powers of the Wave Robots API and Issue Tracker API Python client libraries combined, I wrote the Bug Triagey robot. When you add Triagey to a wave, the bot titles the wave with the current date and inserts a configuration gadget. That gadget lets you pick a triage template, or create a new one. In a template, you just need to specify the Google code project, the Status label, and optionally, a label to sort by. For example, my Wave APIs template specifies "google-wave-resources", "New", and "ApiType", as we try to categorize our issues by sub-APIs, and each of us specialize in different APIs.

After you're happy with the template, the bot loads the sorted issues into the wave, and puts dibs buttons under each one, so you can indicate if you're "Looking at" or if you've "Responded to" an issue. After clicking a button, Triagey changes the button to show your username, and after clicking the "respond" button, Triagey strikes the issue out. That way, it's easy for you to review the issues in the wave and immediately see which issues haven't been triaged yet, and who's working on what. And just like before, you can start inline conversations to discuss the bugs you're working on.

Triagey is one of my favorite examples of how you can use Wave to combine automation and conversation to make collaboration easier and more efficient, and of how you can hold multiple structured conversations in a wave. To try it out yourself, install it from this wave. To modify it for your own use (like to triage other items) or to see how it was built, grab the code from the samples gallery.

No comments: