Spurring a round of activity on how various core committers of the WordPress open source project work through code committing, I felt compelled to also jump on the train, as I felt like my process diverged a bit. I unfortunately did not have the opportunity to join in during WordCamp US this year, where this first came up, but there’s always next year!

One of the biggest differences, I suspect, is that there’s very few committers who use Windows such as I, instead of a unix platform.

I wonder if these differences come from ingrained habits, based on where in the cycle of tooling one gets invited to these hallowed halls?

I did slightly consider naming this post “How I contribute to WordPress as a committer”, because although this is my process when committing, I commit much less than many others, but I provide feedback and opinions much more frequently. Feedback and opinions are important, they’re a great way to contribute when they bring value and move things forward… but I digress, this is to share the process we go through so that others may take what feels comfortable and right to them and maybe find a friend they can ask or improve on alongside, so let’s focus on that for now!

Code editors

As you may also notice, many other wonderful people have shown off their command-line skills in pulling down changes and applying them. I’ve become too attached to my IDE at this point in time, and find it much more convenient to my workflow to use it’s “apply patch” feature, along with other quality of life buttons and menu items, where I can take a .patch file (from Git or SVN!) and apply it to my local copy of the WordPress repository, that means you won’t see a lot of command examples in this post, but more about my process).

This also ensures it is applied to a separate “patch” branch automatically, so I can go back to the base project without any changes without much hassle.

I personally use PhpStorm, and although it is a paid product, and I have a paid license for work, they also have a very generous open source maintainer license which I use for my personal machine and open source project work. This paragraph left intentionally without links, this isn’t to promote IDEs one way or the other, although in theory that is what I just did, but it also would not make sense to say I lean on my IDE without saying what i use that i find convenient.

Dev environments

I swear by the built in docker environment, it allows me to quickly build up or tear down a test site, or just start fresh to make sure nothing else is interfering with what I am testing or writing.

Code I write

I’ll have a fork of the WordPress/WordPress-develop repository on my personal GitHub account, it should be noted that I regularly destroy this and re-fork, just to make sure nothing unintentional snuck in.

Any code I write an intend to make patches for, I will commit to this fork, and open a pull request for, this gives me peace of mind that all the tests are running and working like they should, without needing to dedicate processing power locally to running the tests (depending on which device you are on, this could suddenly take a lot of time if it is under performing).

Code I review

If the code is written by someone else, I will generally apply the patch locally to spot the obvious things such as code formating and the likes, if the code wasn’t submitted via a pull request, but directly on trac, I will assess if the change will impact any tests.

Leaning on my IDE again, I am given all the tools I need to observe what files are modified by a patch in a quick overview, as well as the ability to make visual diffs for whole files, making it easier to look at context of a diff as well.

If the changes will impact tests in any way, I continue on by pushing the contributors changes to my GitHub fork so that the test runners can do their thing again.

If they won’t (for example string changes, documentation changes, anything like that), then reviewing it directly, giving feedback as needed, and then moving on to the commit stage is what I do.

Code I commit

Once code is written, it’s ready for commit, we get to the easy, but always exciting, part.

I try to avoid stopping a contribution based on minor things, code style issues that I can easily adjust from a small patch I’ll just fix before committing.

Writing the commit message is probably the most time consuming part of the commit procedure. I have a bookmark labeled “Commit Messages” which I always consult when doing a commit and it’s been more than a day or two since the last one; both because I worry I’ll forget something, and because routines may change over time, and doing so is a good habit to help keep it fresh for every commit.

Commits are done to SVN, until this point, we have not touched SVN in my process. SVN is for code that is ready, it is the source of truth, and as such is left alone until it needs changing.

I have a separate directory, and a separate project in my IDE for the SVN repository, this lets me safely keep them as separate as possible, and I don’t have to worry about mixing credentials or remembering commands because of the different version control systems living in the same house.

I use the apply patch button in my IDE, do a final look at the diff window to see that it applied like it should, and then I commit.

And if I have the pull request tests already, I can skip this final step: Sit and wait anxiously as you hope the tests pass and you don’t have to do a follow-up commit.

---

For historical reference, and because we all make mistakes and learn from them; my very first commit was followed by a fix commit roughly 8 hours later (when I woke up), as I had suddenly realized while in bed, that what I committed could have an unintentional behavior causing a warning as well.

I include that, because I think an important part of being a committer is knowing that it’s human to make a mistake in the process, we all make them, and it isn’t the end of the world, no matter how big the software is.

---

Once everything is done, I go back to GitHub and close any pull request i opened for the issue, and delete the branches on my personal fork to keep things neat and tidy.

This sounds like a lot of steps, but it’s quite fast when it’s the workflow you’re used to and comfortable with.