Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!

For 3.7, the biggest goal (at least in my mind) is to blow through Trac and close as many tickets as possible, either through committing a patch or because they aren’t relevant anymore. At close to 3800 open tickets, Trac just isn’t manageable for anybody anymore (except perhaps for Sergey). Casual and hopeful patch contributors are understandably intimidated and lost. Nobody wants to make a duplicate, and keywords often don’t accurately reflect the state of a given ticket, leaving people wondering how they can see tickets that need a body. We need to get this under control.

I consider Trac curation to be one of the most important but often overlooked areas of contributing to core. Other projects formally recognize them – for instance, Joomla! recognizes active members of their Bug Squad. There are efforts currently under way within WordPress to form core component teams, so I don’t currently have any real thoughts on what should be recognized and how, but I think something similar could be really nice.

In the community, some trusted contributors are given Trac privileges to do what’s called bug gardening. There isn’t really a whole lot about this that is different from what everybody else can do – it’s pretty much just that you can set the Milestone, which serves two purposes. One is that it prevents creep (of course everyone would want to put their pet ticket into the current milestone), and the other is that tickets that are closed still get some kind of review from somebody who’s been around, because the milestone needs to be cleared.

You don’t need to be given a little piece of Trac permissioning to do gardening, though! There’s a page in the handbook about bug gardening, but I thought I’d give a practical example based on how I do things. I’m sure it won’t work for everybody, but if it helps anybody, then it’s worth writing down.

I subscribe to what’s known as the Trac firehose: the wp-trac mailing list. It’s definitely not for everybody, and soon (seriously, soon) you’ll be able to subscribe to just certain components instead. However, I’d recommend that everybody give the firehose a shot, even just for a week or so. There are definite swings in activity, and I think it gives a great perspective as to the sheer number of tickets, comments, and patches that are clamoring for attention at once. If getting emails for when somebody is just cc-ing themselves to the ticket drives you insane, I have a handy Gmail filter for that: “added — Ticket URL:” β†’ Trash. If you’re just doing it as a temporary thing, though, you might not want to filter those out. It’s a great barometer as to the level of interest in something, and it can often bring an old ticket back up for attention.

I try not to read these emails all day, but rather set aside a little bit of dedicated time to read them in chunks. I do make an effort to read everything, but if I’m overloaded and there’s a super active discussion on something I’m not tied into, like say using PDO, I might just delete it without reading. If I see something that’s been closed but the milestone hasn’t been cleared, I go check it out. Usually it’s been closed for a perfectly valid reason, like a duplicate or that it’s a plugin at fault, so I just clear the milestone and go on about my day. Other times I reopen it, or it sends me on a hunt for other duplicate tickets that can also be closed, etc. I might also add keywords if they’ve been left out when somebody adds a patch (has-patch) or somebody reports that a patch doesn’t work (needs-patch).

Many times, though, just seeing an email for a ticket triggers me to want to know more about it, and it often ends in a patch. As an example, take #17201: “dynamic_sidebar performance”. I saw that a newer gardener had closed it saying he didn’t see a performance issue, and the ticket title was vague, so I went to see what it was about. The complaint was that sanitize_title() was slowing things way down, and given that it’s something I’ve dinged people for using on display due to its heaviness in various code reviews, I thought that the ticket was probably perfectly valid after all. So I took a quick look at the function, saw that the usage of sanitize_title() is indeed there (and more than once in a call!), couldn’t reason out why exactly it’s even needed, and reopened the ticket with a comment saying as much. Now, I still haven’t figured out why it’s there, but it seems to me that a less expensive function could be used in its place. Maybe I’ll patch it. More likely, though, I’ll encourage somebody newer to patch it for experience. πŸ™‚

There’s life beyond the firehose and messing with keywords and milestones, too. Reproducing bugs and testing patches in general are a huge help. There are various reports in Trac that can get you a picture of what’s going on in a given area – the most common ones people look at are 5 and 6 for the current release. You can also just pick a random open ticket, or look at a component, and go from there. If a bug report is just sitting there without any further comment, try reproducing the bug. If you can’t, ask the reporter for feedback (and leave the reporter-feedback keyword). If you can, leave a comment with the steps you used, as it helps for history and for further patch testing. From there, if so inclined, you can try writing a patch.

If a patch exists already, test it! If it doesn’t apply cleanly, you can mark the ticket with the needs-refresh keyword, and/or go ahead and refresh it yourself. If the patch doesn’t work, or doesn’t solve everything, leave a note saying so and add the needs-patch keyword. You can also, of course, iterate on the patch. If everything’s good, leave a comment saying that the patch works for you. If it’s a complicated process to testing the patch, it can help to leave your steps, much like with reproducing the bug in the first place. Refreshing and iterating on patches get you props just like a patch you wrote all on your own, so if the props are a good carrot for you, that’s something to note.

Don’t be afraid to do something “wrong”. Really, there is no wrong. Maybe somebody will reopen a ticket you closed, or maybe it’s not really a duplicate after all, but it’s not a big deal. Don’t take it personally or worry about it. Learn from it if there’s something to be learned, and keep going. Let’s clean up Trac, y’all.

Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!

16 thoughts on “Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!

  1. #17201 Is a great example. It opened a whole new discussion on a 3 year old ticket. I’ve been working off report 19 needs wrangling / punting, starting with oldest tickets to hopefully make a dent in the back log.


  2. wycks says:

    I find jumping into track really confusing, partly because I am used to “other systems” which automate a more specific or tailored workflow. I find it daunting because I just don’t know where to jump in, is there a roadmap for the new release structure, what’s important vs what is wasting time, etc, what tags do I search for? I think the my bounce rate is really high and I would assume I’m not the only one, after surfing around trac for a few minutes I just get lost.

    I know the devs who are familiar with trac feel very comfortable using it but I need some directions, instead of a flood of information I would prefer baby steps.


  3. lizhenry says:

    Wow great article. I definitely feel your pain and agree that bug gardening is a great thing to do!

    It might help to have links to a few possible queries or lists of bugs to go through! That’s what I’d like in order to dive in to your system and poke around a little bit πŸ™‚


    1. Bryan Petty says:

      There’s the full list of various official pre-configured reports that can be helpful here: (click on “show descriptions” for some help there too)

      Also, the bug gardening guide on make/core that Helen linked to specifically focuses on just *one* single report on that list that helps narrow down a specific set of tickets that should be easiest for someone new to jump into and work on.


  4. There are good nuggets of wisdom to share with other Bugsquad communities out there, for example just a list of tasks that anybody can get started with, and default queries for them, as Liz already wrote. In general bug triaging is a great way to contribute to your favorite software when you are not a programmer, and often people turn into key community members after a while.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s