Triage remains one of the most important things to do in any scale project. When I refer to triage, I mean not just processing something but taking a good, hard look at it and deciding the direction. This is a skill that is hard to learn and refine. Many years ago, I wrote a post on the now-closed Automattic design blog about the art of triage; I want to reflect today on one aspect of that, closing. This is still a daily practice for me and remains even more critical as the project of WordPress scales and our open-source projects mature.
When I talk specifically about triage in this post, I am talking about tickets and issues within WordPress —in this case, both on Trac and GitHub, depending on the area. The thoughts apply beyond just one project to the art, hence the name. I use this practice in my work on products and with consultancy. It scales, but it is an art form I have learnt through open-source projects.
Misconceptions around triage
Triage may sound like a quick analysis, a brief check followed by immediate action. However, to ensure that you are providing the proper treatment, it is essential to slow down and take the time to analyze the situation. This is the ‘art of triage.’ It involves more than just applying a label and moving on; it requires a deep understanding of the project, the data, and your knowledge. Oftentimes, it’s not only about labelling; it’s about truly comprehending the context and implications.
Triage should be making decisions
One common misconception about triage is that no decisions can be made during the process. I strongly disagree with this notion. Ineffective triage can occur when no decisions are made; however, as long as you are clear about the reasons behind your choices, it is valid to make them. You may need to revisit those decisions later, which can provide additional clarity.
Engaging in triage over time improves your decision-making skills. Through my regular triage sessions, I have become more adept at understanding the areas of the projects I am involved in. Triage has helped me gain insights into the overall situation within WordPress, and it continues to give me that gift on any project I work on.
Closing is critical
As a project, we need to close issues. Triage is ineffective if we don’t consider closing an option. Closing an issue is not a final decision; it simply means “not at this time” and can be revisited later. It’s essential to close issues politely. If we are honest, an open ticket for years doesn’t serve anyone well. It is either a sign that nobody wants to decide, a consensus couldn’t be reached, or that the time wasn’t right.
There often seems to be an aversion to closing issues, which I have noticed among contributors repeatedly. The reality is that if we do not close tickets, it creates more problems. Without a closed state, it’s difficult to identify what should be prioritized over time. Maintainers and contributors need to clear pathways and be transparent with issue creators about what will or will not be included in the project roadmap. This is where we need to make decisions, and the true skill of triage comes into play. You might not always be the one making the decision; sometimes, you may need to direct it to the decision-makers who oversee specific components, for example.
Tone matters in triage.
One of the most significant issues when anyone participates in triage or issue management is the tone of the tickets. I struggle with this myself, far from always getting it right. It is a fine art, and I am continually learning and working on it. Triage is not just about taking action; it’s also about effectively communicating the message. You must be clear and respectfully explain why a particular state needs to be changed. Additionally, it’s important to log all decisions so that future participants can understand their reasoning.
Backlog maintenance or triage?
When managing projects, it’s essential to differentiate between triage and maintenance. Triage involves assessing the current situation and identifying urgent issues, while maintenance requires a more in-depth focus on long-term improvements. If we are honest, we haven’t fully implemented both processes in WordPress currently. This is a semantic point for now, although having a difference in practice is essential. Today’s focus, I would recommend, should be on making the triage process more effective and scaling up. This includes adjusting labels, making decisions, and closing issues, which would be a significant step forward.
The art of triage starts with graceful closure
I stand by my statement that triage is akin to an art form when done correctly. It’s an incredible aspect of project management, and I personally aspire to improve at it each year I work. Over the years, I’ve learned that, as someone in product, triage has become my lifeblood. It offers valuable perspectives, and as a creator, it helps me understand and acquire knowledge. This practice is rewarding as you learn along the way, and there is always something new to discover.
A healthy repository includes all ticket states—both open and closed—along with proper labelling and a two-way flow of information. It remains active and well-maintained. While I understand that closing tickets can be challenging due to concerns about pushback or reactions and the fear of making the wrong decision, it’s important to remember that nothing is beyond correction. If you close tickets gracefully and leave a clear trail, you can easily address any issues that arise later.
This is why I titled this post’ The art of triage starts with closing’. A project that has a healthy closing, good ticket updates, and confident maintainers who comment and keep the flow going on issues by closing is healthy and will attract contributions. It is also one where you can see what to work on and be productive.