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.