How to do Core Old Ticket Triage for WordPress

Introduction

I did my first patch to the WordPress core in 2015, I remember that I was thrilled when it was reviewed, approved and merged.
It was like feeling part of the family like I do for many other open source projects, the difference in this case it is just that there isn’t any GitHub involved (almost).

My bio on WordPress Profiles after all say that:

In 2012 I started to develop for WordPress for work and in 2013 I opened many tickets in many plugins with patches.
In 2014 I’ve written my first official plugin and in 2015 my first patch for WordPress itself.
In 2016 co organizer for the WP Rome meetup and in 2017 my first talk at WordCamp Europe.
In 2018 I am part of the team of WordCamp Rome 2018 and in 2019 I am part of the VVV team as maintainer.

Those aren’t my only contributions to the WordPress ecosystem but I am part also for GlotDict or VVV.

Last year I did an analysis about WordPress Core contributions by tickets numbers as I think that a OSS project is not healthy if had a long queue of stuff that no one sees, so I already tried in the past talking with Core Committers about more Triage sessions, finally now every 2 weeks there is a session for Old tickets (that is open to everyone of course).

Legend

Usually when I do this kind of triage job I start from the oldest tickets also for the needs-refresh tickets. But let’s just do some steps back with a legend.

• Triage: in Open Source is one of the “janitor” tasks that usually is done by contributors that don’t need to have an advanced knowledge of the code and so on. Basically take a ticket and try to see if you can replicate the issue in the latest version following the steps suggested in the ticket and giving information, like where there is the code that fixed the issue or where there is the bug (but is not mandatory). As you can see is just a way to give more information to the developers in a way that they can open the ticket and just start debug or close it (for old tickets that in the meantime was already fixed)
• needs-refresh/good-first-bug/etc: they are the tags used to catalogue the tickets on WordPress Trac system. Every open source projects as similar tags and the meaning usually are the same, just change the granularity of the organization. The needs-refresh tickets are a ticket where there is a patch and need to be updated to work on the latest release, usually you can find stuff very old hanging there since 10 years. good-first-bug are like the title says easy for newcomers and they are a way to learn how to contribute and experiment with the contribution in the project itself
• local instance: in development it is a environment in your computer that it isn’t online or in another server, but in your machine so you can do all the changes that you want
• version: in trac tickets there is the version flag but is not the latest release where the issue was found but instead the first release where the issue was found
• codebase: in development projects is the whole source code in the various files, also the one that usually when the project is released are not present

Tutorial

1. You need to have a WordPress instance where you can experiment without breaking anything, it is better if you have one with WordPress-develop source code if you want to dig better but is not mandatory (it is online on GitHub and you can use the search there). If you have a local instance is better to and there are tons of ways to get that like VVV.
2. Open https://core.trac.wordpress.org/, login and give a look to that page and if you want to read something from beginners to advanced check the Core Handbook
3. Next step is to open the ticket search and configure it by opened ticket and ordered by id, but if you are lazy like me you can just click here and save it in your bookmark
4. Just pick one ticket and check if someone recently (I mean in the last comments) tried it what is the ticket issue

Let’s start with a real example of a ticket (that in the moment of writing is still opened) that I already triaged.

The ticket #3329 is more younger then me but it was started in 2006.

As we can see the ticket topic is about a URL that includes the %symbols that creates issues in routing (aka what the browser should show to you based on the URL), as a Mozilla volunteer and developer in this case I was helped a bit. In the last years browsers improved a lot supports for “strange” symbols or non-latin characters in the URL so I was already thinking that is not happening anymore.

So what you should do in this case? Simple just open your WordPress instance and create a new post in a way that should get a URL with the % symbols and open that URL to see if there are some errors.

This is enough to do triage, I mean you just checked that a ticket that now is able to drive a car legally in any country it isn’t anymore a problem in WP as the issue is not happening.

This is was my answer, as I already contributed in the past in WordPress again it was kind of easy to look in the code and study a bit was happening. Also in this case I read it all the comments (and you have to do it because someone can bring more information or other cases about the issue to test).
In this ticket there was another one about a similar issue so I studied both the code patches (but again is just for developers), give my hints using the latest WP codebase.

When you reply in a ticket, don’t close it and don’t change tags/labels if you have no idea what they are and leave that to something else. Just give the most information you can to help the next one that will read this ticket (so can avoid to repeat what you did from reading all the 30~ replies and so on).

So at this point, you already studied a bit how to do a triage, you learned about punycode and URLs (just as personal knowledge) and helped the core committers about the next steps in this ticket, saving their time to focus on something else (like create a patch).

There is space for everyone, in my suggestions is better to dig with the oldest as often they are already fixed or not anymore a problem (as we saw the technology evolves). Remember right now WP Core has 7800~ tickets opened without considering Gutenberg that is not GitHub!

You are contributing without writing a line of code but learning in the meantime and giving hints.

Triage is something that you can do in any open source project, I did in a lot of them in the years and usually is something that I do on new ones just to learn more about before to do something more difficult/advanced.

Just a Wapoo to close this tutorial and I am hoping that on WP International Slack instance there will be a dedicated room, so we can discuss together by chat and asks for reviews each other!

Yes reviews are important to give more hints about what you did, as example with #4298 (from 2007) where during the Old Core Scrubs on chat we saw:

• Give a better title to the ticket
• To check if the HTML code also if it is right it is also W3C valid
  • Right now doesn’t seems valid so this means that we have a bug that will require a patch and so on

And you are you ready to triage something now?

EDIT: If you are looking on how to contribute to WordPress core, there is this recap post for the WordCamp Asia 2023 with various links that can help you to understand where to look at.

Liked it? Take a second to support Mte90 on Patreon!