Demystifying Bug Triage

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.

Get Started

If you’re new to triage, here are some next steps you can take to get yourself and your team started:

  1. 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.
  2. Set up any projects or milestones you have or are planning to use to organize your work.
  3. Review all open issues (add labels, assign priority, check for completeness, etc.).
  4. 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.
  5. 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?

Advertisements

Right-to-Left Testing in Mobile Apps

Did you know that both iOS and Android have easy ways to build your apps for localization testing?

As someone who loves languages, I’m used to just switching a test device into another language for testing and dogfooding over a longer period of time. But even I get a little scared that one day I’m going to switch my iPhone’s device language to Arabic and never find my way back to the language settings. And for teammates who don’t speak another language, it can be even more intimidating. Here’s where iOS and Android come to the rescue with build options for localization testing.

Screenshot of WordPress for iOS app with RTL pseudolanguage displaying backwards English text.
RTL Pseudolanguage on iOS

In Xcode you can select a pseudolanguage in your build scheme. For regular localization testing you can choose Double-Length Pseudolanguage to see how your app works in languages with longer strings. (My teammate Eduardo also suggests using the iOS text size settings as another way to test this on the fly.) But for RTL testing it’s especially handy — choose either Right-to-Left Pseudolanguage to get an RTL layout with regular English strings or Right-to-Left Pseudolanguage with Right-to-Left Strings to see the English strings backwards in the RTL layout. Build your app and you can test out the RTL experience, no language classes required!

For Android, you can enable pseudolocales in your build.gradle file. Then, on your device or emulator, go to the device language settings and select English (XA) or Arabic (XB). (If you don’t see those languages, make sure developer options are enabled.) The first language gives you lengthened strings and all kinds of exciting accented characters, but the second is where RTL testing kicks in — you get English strings backward with an RTL layout.

Now, off to file some GitHub issues for the localization bugs I just noticed … 😉

The Josephus Problem: How math teaches us to solve problems

When I was in school, I always thought math word problems were a little funny. I understood that the point was for me to apply math to solve real-world problems, but the problems never felt real. However, these days I truly appreciate all of the ways that math taught me how to think about, break down, and work through problems.

Numberphile has a wonderful example of how to approach problem-solving with the Josephus problem:

These are the same skills you can use to solve a problem in support, as well:

  • Gather data about the problem
  • Look for patterns
  • Make a conjecture
  • Test your conjecture

As noted in the video, it’s also incredibly important to tackle small, discrete parts of the problem and work from there to the larger solution. If you stare at a big problem, it can look impossible to solve. But if you can prove theories about small parts of the problem, the larger solution can become clear.

Thank you to all of my teachers and others who encouraged me to learn and practice these skills — although I don’t do much pure math these days, I use these skills every day!

Multilingual Testing

As a polyglot and a former translator, I am a huge advocate for software localization, which also means testing software in multiple languages. Code that works flawlessly in English can totally break down in another language — whether it’s due to missing translations, translations that don’t fit into the space provided by the UI, or bugs that only pop up in other languages. (I found examples of all three while testing the WordPress apps today.)

But that’s not the only reason I like testing in other languages. As soon as I switch to one of my non-native languages, I’m forced to slow down and take a fresh look at the interface. Is everything where I expect it to be? Am I seeing what I’m supposed to see on this screen? Do all the buttons work the way they should? Working in another language can help you look at the software with a fresh set of eyes and find bugs that occur across languages — even in English.

Give it a try! Pick another language you speak — or one you’re trying to learn — and use it while you test. I’m trying to spend at least one day a month using WordPress.com and the WordPress apps in another language. It’ll help my testing, and I’m sure it’ll also help my language skills. 🙂