GitHub Issue Triage and Transparency

The Firefox DevTools debugger.html project lives on GitHub. Earlier in the year we moved to the debugger to GitHub in an effort make development simpler and more transparent. But in this new GitHub world we needed to reinvent a lot of things that were done in our old world of bugzilla and mercurial.

The first thing we needed in GitHub was a system to track and triage incoming bugs. In part I want to share what we are doing in hopes it helps others, but also I’d love feedback and suggestions that could help improve our own process.

On New GitHub Issues

All new issues with the debugger are filed in GitHub issues; mind blowing, right?

As they come in we tend to do a quick triage with labels to categorize them, labels like bug, enhancement, or discussion. This part of the process is intended to be a quick set it and forget it so you can get back to whatever else you’re doing. A bug is a bug, are you unsure… its a bug.

One reason this categorization process can be quick because we’ll perform an issue triage later in one of our meetings, either the daily standup or longer weekly meeting. This also allows us to process things that could be critical, stop the presses, kind of issues but leave the rest to not interrupt our current priorities.

Issue Triage

We are using the GitHub Project interface for our triage process and this is the part that’s really worth diving into.

We created three boards to handle issue triage, Requires Investigation, Priority Ordered, and Low Priority. These boards are filled during our triage sessions and here’s how that works.

Clear the fixed issues. Triage starts with one of the most rewarding aspects, which is clearing out the issues we’ve already fixed. I really enjoy this manual process because we get a chance to quickly discuss the issue in case there is anything to learn about how it came about.

Remove each card (marked red) that has been closed and fixed

Add new cards. Now its time to turn to all the incoming issues which have been flagged as a bug. Click the Add cards button to get this dialog with the latest incoming issues.

The great part here is that the Add cards search shows only the issues / bugs which match the search but are not yet shown in the board.

And now you can begin your triage. Drag each of the cards into one of the boards depending on their status. Try not to spend too much time investigating the issues right now, just quickly determine if they need more investigation or their priority level.

When you’re finished or if there were no new bugs to triage you’ll be left with an empty popup and you’re done the triage.

Low Priority

For all issues you’ve placed in the low priority board of your project there is an simple signal that can be seen from within the issue itself.

The Bug Triage project indicates to others that this did go through the triage process and that it has been placed in the Low Priority bucket or other buckets.

For other issues you’ll see similar indicators for either of the boards High Priority or Requires Investigation.

La Fin

If you’re using the projects boards in a similar way I’d love to get your feedback so we can improve our process. And if this helps you improve your own process I’m glad to have shared it.


I’m the Product Manager for Firefox Developer Tools. I love making great tools that people can use and share.

I’ll be posting more here about our road map and future plans.

Show your support

Clapping shows how much you appreciated Bryan Clark’s story.