How to work with WordPress Trac

Undoubtedly, WordPress Core would benefit from a larger number of active developers. The system, especially Trac¹, might be, however, too complicated for newcomers to work with. That goes for me too. Do you know what’s the best way to learn something? Write an article about it, of course. That’s what I’m going to do: write a post about what the Trac is, how to use it and so on. I’m going to use a lot of screenshots to accomplish the task with an ease.

What is WordPress Trac

“Trac is an open source project that serves as a bug tracker and project management tool for WordPress.”² Simply put, it’s the place where WordPress itself is developed. With Trac, we can contribute to WordPress by creating tickets (reporting bugs), working on unsolved tickets and testing the ticket patches (fixes or solutions) submitted by others. Trac is the first thing a new WordPress developer has to get familiar with. And that’s where the problem lies: people are deterred from contributing to the Core (or studying how to do so) because the first thing they get to see is Trac, which becomes one of their largest barriers to entry.

Taking Trac apart

…screen by screen. Navigate to Trac homepage¹ and follow the steps from there.

Tickets Screen

On the right-hand side at the top of the page, there is a navigation menu. Click on the “Tickets” item, as shown in figure 2. That will get you to the Tickets Screen:

This is the main screen of the whole Trac system. It is divided into several parts:

1. Trac Ticket Reports
2. Me
3. Tickets by Release
4. Tickets by Topic
5. Getting Started
6. Tickets Needing Feedback and…
7. Other Workflow Reports

Trac Ticket Reports

This part is, too, divided into several subparts. The two most important links here are “Latest Tickets” and “Browse Source”.

Latest Tickets

After clicking on this link, we are shown a table of the latest tickets submitted to the Trac system, sorted by the date of creation:

From the table, we can observe that each ticket has:

• a serial number (wow, we are at #33240 at the time of writing) (assigned automatically when a ticket is created)
• a short summary of the problem (assigned by the ticket’s reporter)
• reporter’s nick
• the component where it belongs (categorization of tickets, assigned by the ticket’s reporter)
• a priority (assigned by Core developers)
• a severity (assigned by Core developers)
• a milestone (“Awaiting Review” if not yet reviewed and assigned different milestone by Core developers)
• a type (whether it’s a bug, an enhancement or a feature request (new feature), assigned by the ticket’s reporter)

The highlighted tickets (yellow color) are still “Awaiting Review”, so they have not yet been reviewed by a Core contributor.

Latest Tickets table is an important place allowing us to choose a good-sounding, eye-catching ticket and work on it. However, the best tickets for beginners like us are to be found on the Good First Bugs page³. Will discuss that a bit later.

Browse Source

The next thing we’ll talk about is the “Browse Source” screen. You can get on it by clicking on the link “Browse Source” in the Trac Ticket Reports section of the Tickets screen.

On this screen, we can see the “Trac Repository Browser”⁴. It can be used to browse the source code of the WordPress project. The project is developed in SVN revision control system⁵ (similar to Git⁶)

The red circle is showing the “trunk” folder; try clicking at it — you’ll be presented with the WordPress project files.

Each major WordPress release (such as 4.0) is stored as an SVN branch. To go back in time and browse the source code in older WordPress version, use the “Visit” select element:

You know what gets on my nerves? The sluggishness of the code browser… It’s so slow that I prefer to use the GitHub mirror⁷ of the SVN repo and browse the files there.

Me

Tis iz not about me, rather about the actions you, as a WordPress.org user, can do in Trac. Basically, you can create (submit) a ticket and then attach a patch (code fix) to it. Let’s look how we can create a ticket.

Create a Ticket

After clicking on the “Create a Ticket” link, we are moved to the “New Ticket” screen:

Here we can type in our problem and have it recorded into the Trac system. To see how such a ticket could look like, inspect the following example of a ticket filled in:

Always double-check that the same (or very similar) issue has not been already reported as this makes unnecessary work for the Core contributors. Try to be as concise as possible and include screenshots if they describe the problem in a better way — people reading your tickets are not magicians, they can’t read your mind. 🙂

Getting Started

This screen is a ticket filter, helping us to select those ones we want to work on.

Patches Needing Testing

These are the tickets which have already been patched (fixed) but in order for them to be accepted into the Core, they need more user testing. A good starting point if you are afraid of jumping right in.

Tickets without a Patch

Are you confident in your WordPress and reasoning skills? Do you want to be the first to solve a problem? These are the tickets which have been reported but still don’t have any patches (fixes).

Good First Bugs for New Contributors

These tickets were marked as “Good First Bugs” by Core developers. That means they are probably easier to fix and understand. I would start with these if I were you.

What’s next?

1. sign up for WordPress.org⁸
2. don’t be shy
3. click on everything
4. play with Trac
5. read, read and read the tickets of other people, how they communicate and deal with issues
6. find a bug, report it and then fix it (grammatical and spelling errors count, too)
7. subscribe⁹ to the SVN commits and new tickets feeds to be up to date all the time