When I was first approached about being a Backdrop CMS core committer, I was both humbled and more than a little scared. I'm extremely grateful to the PMC for having the confidence in me to offer me this role in the community, but the amount of responsibility they were handing over made me a bit hesitant. Could I do this? What if I made mistakes? What did they expect of me time-wise? This article aims to pull back the curtain and show how easy (and rewarding) it is to be a Backdrop core committer.
When they offered me the role, there was a bit of a Q&A session with one of the PMC members. One of my main questions was "How much time will I need to devote to this each week?" At the time I was a relatively new parent and had family commitments that meant I only contributed to Backdrop in my (limited) spare time. The PMC assured me that this was purely an "as-available" position, meaning I only needed to perform core committer task if/when I had the time and energy for it. No expectations, no pressure.
I then had a meeting with one of the current core committers who walked me through the process of merging a pull request into Backdrop core. They were also able to answer the more technical questions I had, and then set me up with access to Backdrop's core GitHub repository. While the process of merging code into core can be a bit daunting (especially for someone like me who knows enough about git to do basic day-to-day tasks, but struggles to understand 'rebasing' and 'submodules', and who often confuses 'remote' and 'upstream'), after doing it often enough, and making a handy Bash alias for myself to simplify things, I'm more confident now and am often merging PRs that are marked 'RTBC' (Ready To Be Committed).
My process
This is how I approach being a core committer... Whenever I have the time and inclination, I'll look through the list of 'RTBC' issues and find one that I am more-or-less able to understand (after reading through the discussion and then the pull request (PR) code - I don't like merging something I don't understand, so I'll leave those issues for other core committers). Once I've verified that the PR nicely fixes the problem, or adds the desired functionality, and has been tested/reviewed by someone else as well, I'll 'squash and merge' the PR into core.
This makes a single commit to core with all of that PR's changes. This is handy when a PR might have gone through multiple revisions and had lots of follow-up commits. It's clean and simple. This merges the changes into the latest 1.x branch of core and, if this PR is slated to go into the next minor version of Backdrop, that's all there's to it. If however the PR is meant to go into the next bug-fix release, there's a bit more work needed.
For bug-fixes, I'll then copy the commit hash that was just created from the squash-and-merge, then head over to the command line. I have a clone of Backdrop core on my local machine specifically for core commits. The idea here is to cherry-pick the commit just made to the 1.x branch into the current branch. There're a few git commands needed to do this that Nate Lampton has documented, but I eventually put them all into a simple bash alias for myself:
function bmerge {
git checkout "$1" && \
git pull backdrop "$1" && \
git fetch backdrop && \
git cherry-pick "$2" && \
git push backdrop "$1"
}Now I can just run bmerge [branch] [commit] and it's done! Now all that's left to do is thank the people involved in filing the issue, making the PR, and testing/reviewing it. Then make sure the issue is closed with the appropriate labels and milestone.
There is a bit more to being a core committer than just committing PRs; such as weighing in on technical discussions where I may need to provide advice on the best way forward for a particular issue. But support abounds - there's a 'Leadership' Zulip stream where PMC members and core committers can chat privately, I can (and do) ask other core committers for help and advice, and the PMC members are also always available and willing to help as needed.
So being a core committer doesn't have to be scary, and it's certainly not time-consuming. We're all human and we all make mistakes. I have (and they were easily reverted), so there's really very little real damage a core committer can do. While being a core committer isn't a position you can apply for, if approached by the PMC with an offer to be one, I'd say go for it! It's so rewarding being part of such a great community, and the more core committers we have, the quicker bugs can be fixed and new features added.