It’s one thing to have a local copy of the latest version of WordPress installed on your system – don’t get me wrong, it’s really cool to be able to see some of the new features – but it’s another thing to want to get involved in contributing to the codebase.

Sure, it’s completely possible to get started by trying to implement your own desired feature, but the likelihood that it’s going to be merged into core is very, very small. Those type of decisions have a process through which they undergo before being merged. Plus, that’s taking on a lot if you’re just getting started with contributing code to WordPress.

But what about trying to fix WordPress bugs? That is, what if you were to want to try to take your chances with fixing some of the existing problems with the software?

That’s a bit easier.

Squashing WordPress Bugs

Regardless of if you’re new to a small agency or team or a large corporate large, one of the best things you can do as a developer is to jump in and begin trying to fix bugs from the existing bug reports.

This helps you to become familiar with how the software is organized, how it works, any coding standards they have in place, processes for testing, deployment, and so on. There’s a lot to be gained for working on bugs. And when it comes to WordPress, the experience is no different.

What’s Trac?

Regardless of where you’ve worked – or where you work – odds are, you have a system in which bug reports are kept. WordPress uses a piece of software called Trac.

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way.

Straightforward and easy enough, right? It’s a very simple system that’s used to list bugs, comment on them, view the contributors, upload patches (produced via Subversion which is a topic for another post), and have discussions around the issues.

Trac

If you’re going to be submitting patches to WordPress, then you need to be familiar with the WordPress Trac.

Getting Familiar with Trac

Hoping into Trac can be a lot like drinking from a firehose especially if it’s your first time hopping into a large project’s ticketing system.

Not only is there a lot to learn in terms of how the information is organized, but there’s also a lot to learn in terms of how to interact with the rest of the developers and contributors, as well as how to open issues, submit issues, and discuss issues.

Luckily, it’s easy to lurk around Trac and other issues to see how people interact in order to get a feel for how to conduct yourself.

But let’s say you’re looking to actually get started resolving some of the issues that exist in WordPress. What then?

Your First Bugs

Lucky for us, WordPress Trac includes a page called Good First Bugs. In short, it’s a great place to start if you’re looking to get involved with the WordPress project.

Good First Bugs

Just as mentioned above, good first bugs are a place to start that help you get familiar with the codebase and the processes that come with resolving issues that exist in a project. Straight from the Trac page:

First bugs aren’t necessarily “easy,” though some are. These bugs are meant to be well-contained. They are designed to help get you familiar with WordPress core code, processes, and contributing, not send you down a rabbit hole for days on end.

For each of the listed bugs, you’ll see a reason for why the ticket exists and, in most cases, a good place in which you can get started. Based on that description, you take the local copy of WordPress that you’ve checked out from Subversion, try to reproduce the problem, and then work on the core code to resolve the issue.

Once the issue is resolved, you then create a patch and submit it to Trac. Creating a patch based on work done on the local copy of the code is an exercise in and of itself so I’ll cover that in another post.

For now, though, you’ve got what you need in order to have the latest version of the codebase and what you need to identify existing bugs and how to get started working on them.

Category:
Articles
Tags:

Join the conversation! 2 Comments

  1. On and off for a number of years I have sat watching the WP Trac good first bugs list, but they always appear to have diffs submitted by people pretty quickly so I have never bothered to contribute. It would be nice to see a follow up post explaining the development pipe line that WP uses and how to set up a good development environment for working on multiple bugs.

    • On and off for a number of years I have sat watching the WP Trac good first bugs list, but they always appear to have diffs submitted by people pretty quickly so I have never bothered to contribute.

      True — this is something that you definitely have to keep an eye on. The nice thing is that multiple people can submit multiple patches and one of the patches will be accepted. Maybe it’ll be the first, maybe not.

      Whatever the case, you have to be kind of vigilant in terms of monitoring it and staying engaged (it’s a good problem for an open source project to have).

      It would be nice to see a follow up post explaining the development pipe line that WP uses and how to set up a good development environment for working on multiple bugs.

      What do you mean by the development pipeline used by WordPress?

      As far as a local development environment is concerned, I usually just point people towards something like MAMP and some people use VVV. If you’re looking for something more than that, let me know.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.