I adapted this post from an internal guide I made for one of our teams. My goal was to demystify bug triage, lay out the basic hows and whys, and get buy-in from the team. I wanted everyone to feel comfortable triaging the issues reported in the team’s GitHub repositories (or other bug trackers).
The term “triage” comes from medicine, where it’s the process of determining the order in which patients will receive treatment based on the severity and urgency of their medical condition. At Automattic we apply the term “triage” to the processes we use to determine the severity and urgency of bug reports (and the potential positive impact of enhancement requests) so we can prioritize open issues. In other words, it’s how we keep our GitHub repos organized and make sure we can identify the next most important thing to work on.
How to Triage
What processes do we use for triage? Triage is primarily the initial review and prioritization of all new issues as they are opened in GitHub:
- Add a label identifying the topic, feature, or epic related to the issue.
- Add a label identifying the type of issue (e.g. bug or enhancement).
- Add a label identifying the priority, if it’s clearly a high or low priority issue.
- Check the issue to see if it’s missing any critical information, such as steps to reproduce or the device or app version where the bug occurs.
- Add the issue to relevant projects or milestones for followup. If it’s a critical/blocking bug, escalate the issue in other ways, such as a direct ping to a team member.
- Especially important when someone outside the team opened the issue: leave a comment to acknowledge the contribution and set expectations for followup.
I also use the term “triage” as an umbrella term for all the processes we use to review issues, and this includes reviewing all open GitHub issues on a regular basis:
- Make sure that open issues are still valid and complete.
- Look for trends, e.g. a group of issues related to a specific feature or component.
- Re-prioritize issues when team goals and priorities change, or in response to trends you identified.
The exact timing for triaging new issues and reviewing existing issues depends on the team and project. If you’re just getting started, I’d suggest triaging new issues at least once per week and reviewing existing issues at least once per quarter (or whenever there’s a larger conversation about what to work on next).
Why to Triage
Why do these processes matter? They make it easier to:
- Identify related issues that can be fixed at the same time, that show a potential weakness in a particular part of the app, or that point to a potential longer-term project.
- Gauge the health of the app, in terms of number of issues and their severity.
- Prioritize issues for regular maintenance.
- Respond to all reports, especially from external contributors and reporters, to make sure nothing falls through the cracks.
If you’re new to triage, here are some next steps you can take to get yourself and your team started:
- Agree on a consistent set of labels and what they’ll be used for. If you’re using GitHub, there is a set of default labels you can start with — but most important is to think of what’s useful for your team and how you work.
- Set up any projects or milestones you have or are planning to use to organize your work.
- Review all open issues (add labels, assign priority, check for completeness, etc.).
- Practice labeling new issues with appropriate topic, type, and priority labels. Hold yourself and your team accountable for doing this on all new issues you open.
- Identify a triage DRI (“Directly Responsible Individual”) and set a cadence for triaging new issues and reviewing existing issues going forward.
As with any work, be prepared to reflect and iterate on your processes. So far this approach has worked well for me and the teams I work with, but you may need to add or subtract steps to make it fit the way you work.
What do you think? Are your teams already doing this kind of triage? Are there any other steps or processes that you use to keep open issues organized and prioritized?
I have always loved a good puzzle. You know there’s a problem, and a solution, and you just have to figure out how to get from one to the other. Lately I’ve been especially enjoying puzzle games where the problem itself is part of the mystery — you’re given some information and have to figure out where to start.
My brother is especially good at finding these kinds of puzzle games. For Christmas, he gave me a subscription to Hunt a Killer. It’s a detective game in a box, but no one tells you what you’re trying to solve. You just get puzzles and clues to put together, and each month (for 6 months) a new box arrives with more details. There are “aha!” moments when you solve an individual puzzle, and the slow burn of fitting together clues and piecing together theories about the underlying story.
Another game that came from my brother is Gorogoa, a computer puzzle game with beautiful illustrations and simple yet incredibly clever gameplay. Once again, you enter the game with no idea of what’s happening, but as it continues you get a sense of the logic and storyline. This one is relatively short but full of enjoyable moments.
In many ways, this is similar to how I approach testing. I want to know just enough about what I’m testing to have a purpose, but not so much that I am just blindly following someone’s directions. I try things out, see where my intuition leads me, and watch for the places where I get stuck. I look for the story, the journey taking me from one screen to another. My challenges turn into opportunities to improve the product, and my “aha!” moments are the places where I see why I’m having trouble. In my testing I may not always arrive at a solution (although I enjoy being part of those discussions, as well!) but the satisfaction is in the hunt, in putting myself in the right frame of mind to uncover what I’m looking for.
Do you enjoy puzzles? Any good ones you’d recommend?
I was recently listening to the Inquiring Minds podcast as they interviewed Daniel Pink about his work on the science of perfect timing. One point that really stood out to me is that you are good at different kinds of work at different times of day.
Previously, I’d thought of my work in two ways: busy/mindless work that I do when my brain isn’t functioning at its best and deep work that I do when my brain is firing on all cylinders. But Pink shared that deep work isn’t all alike — specifically, we are good at creative or insightful work and analytical work at different times of day. The exact time of day depends on your chronotype (I’m a night owl) but, regardless, the type of work aligns with whether you’re in what he calls a trough, peak, or recovery period.
Your trough is the time when you’re sluggish or not so quick — for me that’s first thing in the morning — and is best for busy work like checking email or filing expenses. Your peak is when you’re fully mentally engaged (high mental acuity), and that’s when you’re best at analytical work. But your peak isn’t when you’re best at deeply creative or insightful work — that’s best done during your recovery period, where your mood (but not your mental acuity) improves and you have a little more mental space for thinking laterally or having those “aha!” moments.
I’ve been thinking lately about how I’ve optimized my schedule for smaller chunks of analytical work that I push through at my peak times, but how I have more trouble getting into a flow state with more insightful work. Using Pink’s model, I can try to block out those times when I’m mostly likely to do that work well — for me that should be in the middle of my day, before or after lunch (after I get over my “uhhhh what’s happening?” time but before I hit my “I can do all the things!” burst of mental energy late in the afternoon). I’d really like to build sustainable habits that take into account the creative and insightful work that I find myself doing more of these days.
How about you? Does this model make sense for your work? Any tips or habits that work well for you when you have to switch between these types of work?
I’m happy to share that I’ll be giving a workshop at Support Driven Expo Europe in April! I’ll be sharing about mental models and how you can use them to better support and troubleshoot a product.
Sound familiar? I wrote about mental models a while back and used them to give a round of internal workshops in the Automattic support division. I got great feedback about those workshops and am excited to share them with a wider audience.
I truly believe that great communication between support and product teams is a key piece of product quality, and solid troubleshooting skills (and all that those skills entail) help facilitate those conversations!