I got the chance to volunteer as a PostgreSQL Commitfest Manager (CFM) this past July. As a full-time developer and contributor to PostgreSQL since 2020, I really enjoyed the opportunity to interact with the community more broadly than I usually do. This particular commitfest was the first of five patch-review-and-commit events for the PostgreSQL 16 development cycle.

Contributing to open-source communities can be incredibly rewarding, but finding a place to begin can be challenging, and there’s often a lot of institutional knowledge hidden away. Looking at the worldwide surveys we held here at Timescale in the last few years, it seems like this is an issue in many PostgreSQL users’ minds. To shed some light on some common questions, fellow PostgreSQL contributor, Aleksander Alekseev, showed you how to contribute your first patch in this article while developer advocate Ryan Booz dug deeper into ways to give back to the community, whether with code or beyond code.

In this blog post, I’ll talk more about contributions beyond code by giving you an overview of the CFM position and discussing some of my recommended prerequisites. If this sounds enjoyable, watch this space: I’ll share my July CFM experience, including a timeline, observations, and lessons learned, in a future blog post.

Note that the contents of this post are my personal opinion only—they don't represent official rules or positions from the community. (For those, you can take a look at the PostgreSQL Code of Conduct.)

Now let’s kick off this blog fest.

Should You Be a PostgreSQL Commitfest Manager?
So who should volunteer to manage a commitfest? Personally, I recommend that potential CFMs should already feel comfortable interacting with the PostgreSQL development community. The following will serve you well:

• You should know what a commitfest (CF) is.
• For the commitfest you want to manage, you should know where the community will be in the development cycle. A CF at the beginning or end of a PostgreSQL development cycle is going to be more work (and, at the end of the cycle, perhaps more emotionally charged* than one in the middle)

Why "emotionally charged"?
The end of the cycle is the last chance for patch sets to land in the upcoming release. For contributors who've been working on a patch set for a while, it can be disappointing and frustrating to wait another year for a feature they've poured their volunteer time into.

• You will need a PostgreSQL Community account so that you can log into the Commitfest App, which tracks entries that have been submitted for review.
• You should already be able to send and receive emails on the pgsql-hackers mailing list. The CF app will allow you to send mail from the website if you choose, but it's outgoing only; you'll still want a subscribed email address to read others' responses to you. (And honestly, this whole process will be much, much easier if you already have an email workflow set up.)
• You should be aware of, and nominally comfortable with, the cfbot CI interface. This is still not integrated into the CF app as of this writing (it’s a highly requested feature!). So, it'll help a lot if you already know how to read the build status of a particular patch set quickly.

• It's nice, though not strictly required, if you can download, apply, and test patches from the mailing list. This allows you to perform your own independent review during triage, and if you can do this, you're more likely to understand the overall process from the reviewers' perspective. But reviewing patches is not your primary focus when wearing your CFM hat.

• And finally, consider contributing a patch before volunteering to manage a commitfest! (No, it doesn't have to have been committed.) This is mostly to help develop contributor empathy since you'll be interacting with many first-time contributors. In my opinion, it'll help to remember the emotional range (Excitement! Worry! Fear!) that can accompany that first patch. But it's not a hard requirement since, as before, you're not going to be focused on code changes as a CFM.

If you're missing some of that skillset or you're worried you might be, can you still volunteer? Absolutely! And you don't have to do it alone—take a buddy. Ask for (or volunteer to be) an assistant CFM so that you can tag-team with someone who can smooth over any gaps in knowledge and answer questions about the process.

(Like most barriers to OSS contribution, hopefully this is something that we can all help to make easier over time. The fewer the number of ‘gotchas’ in the contribution process, the less a CFM will have to keep in their head, and the easier it will be for newer community members to successfully manage a commitfest.)

A Commitfest Manager's Job

What does a CFM do?

Mechanically, you will send emails to many people. There will be plenty of administrative work to ensure that the CF tracker reflects reality in a helpful way. (Maybe you'll have ideas on how to reduce the amount of that work.)

You'll be answering one-off questions from contributors, like explaining pieces of the process or helping someone find a patch to review. For very new contributors, you may be a first (or simply the most visible) point of contact, and you'll be actively working to keep their patches from falling through the cracks—there's a lot to remember when someone makes their first contribution.

As with many open-source volunteer positions, everyone brings different goals and skill sets to the role. The common thread seems to be to keep things flowing: help people when they get stuck, remind contributors that they should try to give as much as they receive, and draw community attention to small problems before they get bigger. Some CFMs have focused on an extremely comprehensive evaluation of entries during triage or finding the right people to review patches in certain areas. I tried to bump threads that had gone quiet and needed to be either helped along or returned so that the author wasn't stuck waiting.

Your job is not to decide which patches get committed and which do not, or even which patch sets are worthy of review and which are not. But you will exercise some independent judgment at the end of the CF, when you’ll recommend how patches are closed.

Exercise restraint with that judgment. My personal opinion is that, ideally, you want to be finding and channeling a consensus from the community as opposed to asserting your own opinions over patches. That's a really hard goal to meet in practice because you'll have opinions, and you don't want to start finding ways to disguise those opinions as "coming from the community." So just do your best: speak and then listen, be open about why you're taking action, and be honest when you have strong personal opinions.

And you can absolutely be an author or reviewer while you're managing a commitfest. Try to keep the roles separate, though: make it obvious to new contributors whether you're telling them something as a CFM or as a reviewer, since having a "title" can sometimes imply weight that wasn't intended.

A Commitfest Conclusion

It’s easy to look at open-source software from a pure code perspective. But the community is more than just its codebase, and the CFM role is interesting in that most of its responsibilities lie outside the repository. If you’re looking to build (or brush up on) your community participation and communication skills while getting a broad look at the state of PostgreSQL, managing a commitfest for a month might be a good fit for you.

In the following article, I’ll share my personal experience and cover all the steps in the CFM timeline, from your initial preparation to closing the CF, plus some special cases I encountered along the way. The 2022 September PostgreSQL commitfest is starting soon: I hope these posts will help make the process less daunting and encourage others to volunteer and give back to this awesome community.

Written by Jacob Champion.