Thursday, March 31, 2011

CommitFests and Meritocracy

Yesterday, I wrote a blog post on whether and to what extend the PostgreSQL community is a welcoming community, in which I quoted some remarks that Selena Deckelmann made, and she responded with her own post on where meritocracy fails.  I want to just recap a few things that may not be totally obvious to casual observers of our community; and then I have a few remarks about meritocracy.

For the last three PostgreSQL release cycles (8.4, 9.0, and the current 9.1 cycle), we've used a vehicle called CommitFests to ensure that people's patches are reviewed in a timely fashion.  Up until we reach feature freeze for a given release, we have a series of CommitFests.  CommitFests begin once every two months (e.g., for 9.1, July 15, September 15, November 15, and January 15) and last about a month.  Our commitment, as a community, is to review all patches submitted prior to the start of the CommitFest before the end of the CommitFest, and to commit those that are in sufficiently good shape.  We don't always meet that goal, but we come close.  At the end of the last CommitFest, we enter feature freeze and start preparing for beta.

So, for example, if you submitted a patch on July 1st, it would be reviewed between July 15th and August 14th - generally towards the beginning of that time period.   If you submitted a patch on July 16th, it would have been late for the July CommitFest, so it would get reviewed during the September CommitFest, so somewhere between September 15th and October 14th and, again, usually more towards the beginning of that time period.

This accomplishes a couple of useful things:

1. Patches get reviewed in a reasonably timely fashion.  Before we started having CommitFests, patches were much more likely to get lost in the shuffle, or sometimes, just ignored.  That is now quite rare.
2. We have a formal process for encouraging people to review patches written by others, rather than working only on their own stuff.  While we could really, really use more reviewers, it's still an improvement over the old way, where the committers were basically expected to carry the full load.

3. The deadlines for patch submission are known at the beginning of the release cycle, so contributors can have a reasonably good idea when their patch might appear in an official release.  (Unfortunately, this also leads to a significant amount of "piling on" during the last CommitFest, when everyone who hasn't gotten around to submitting their work for that release suddenly pulls out all the stops, resulting in a massive influx of patches - but it's still better than making up the schedule as we go along.)

We traditionally have not begun the next release cycle until the previous cycle is completed, so there is a long period at the end of the release cycle during which there are no CommitFests.  This is a problem, because it leads to long delays in reviewing and committing patches, but it's not clear what to do about it.  During the 9.0 cycle, we experimented with starting the 9.1 cycle when 9.0 reached beta3.  That was reasonably successful, but our community is small enough that it really is somewhat challenging to do two things at once - or three, really, because we were also in the midst of migrating from CVS to git just as all of this was going on.

Now, on to meritocracy.  I haven't actually talked to Ed about what he meant by the remark about meritocracy, but here's my take on it: Selena is absolutely right to point out that most contributors reach their position not only through their own merit, but also because we happen to be well-educated and have good support structures around us that enable us to earn a living and still have time left over to answer questions on the mailing list at 11pm on a Thursday.  Not everyone is so lucky, and I know I'm not always as mindful of my good fortune as I ought to be, and I agree with Selena's point that we should be thoughtful about reaching out to people who might be outside our usual demographic but who can contribute in meaningful ways.

All that having been said, I believe that one of the great strengths of our community is that, by and large, we judge people on the merits of their contributions rather than their race, sex, age, marital status, level of personal wealth or educational attainment, or other ancillary characteristics.  I'm not going to claim that we do this perfectly - I think we occasionally get sucked into attacking an idea based on the way it's presented rather than on how good it actually is - but we do try, and I think that's a good thing.


  1. To be honest I find this whole "Anti-Meritocracy" line of thinking somewhat offensive. While I have no problems with someone wanting to find ways to reach out to people and find new contributors, I think this line of thinking severely discounts the efforts and sacrifice made but those involved with the project, and also gives an impression that there are barriers to entry that quite frankly do not actually exist.

    Contributors to Postgres are measured on a fuzzy scale of time and usefulness. If you want to contribute to Postgres (and I'd argue if you want to contribute to *anything*), you either spend time on it, or you do something really useful. The more skillful you are at doing something useful, the less time you have to spend, but for the rest of us, we make up for that by spending lots of time on things. Of course, some folks have both tremendous skill and dedicate lots of time. But that is the key; that you make the choice to get involved, that make the commitment of your time.

    And this is what bothers me about the the idea of chalking up Postgres involvement to that of privilege. It's not "luck" that allows you to stay up past 11pm, or at least not luck in any useful sense. Millions (Billions?) of people also have that same "privilege", but it is a tiny minority that choose to spend those late nights answering questions on a mailing list, reviewing code, fixing the website, or organizing events, rather than seeing what's new with Team Coco. When people arrange their jobs/hobbies/families/lives in ways that allow them to contribute to Postgres, it is not luck or privilege that brings that together, it is a choice, and I think it deserves to be recognized as merit for those contributions.

    This is the classic open source idea of meritocracy. I think this is what Ed was getting at. And I think it's something the Postgres community should be proud of. For most other "open source" database like MySQL/MongoDB/Ingres and others, most of the contributors are either employees of the company or they don't get to contribute at all. In Postgres, there are no such walls. All we ask is that you dedicate some time, and do something useful. You can be poor. You can have kids. You don't need an advanced degree in computer science. If you are willing to pick a problem and dedicate the time to help make things better, you will be recognized for those contributions. At least by me. That is what meritocracy is about.

  2. So, for what it's worth, I did not intend to bring up 'anti-meritocracy'. I do see how the conversation quickly turns into that, but I tried to focus on what I see as the community's primary goal: creating excellent code.

    Also, I don't think that it's easy to classify how our community operates, and meritocracy is a poorly defined term at best.

    I'd like to describe how we operate more precisely, and talk about the things that we do well.

    I'm going to try to do that in my own blog later today.