Wednesday, March 30, 2011

A Welcoming Community?

I attended PostgreSQL East last week and, as usual, the most interesting discussions were the ones that nobody planned.  Ed Boyajian, the CEO here at EnterpriseDB where I work, threw out a remark to the effect that the PostgreSQL community is a meritocracy.  Selena Deckelmann wasn't convinced, "not to say that we don't do try hard, and do pretty well."  During the closing session, Josh Drake made some remarks to the effect that, in effect, the process for submitting a patch to PostgreSQL is long, difficult, and fraught with arbitrary and capricious rejection, which caused me to rise to my feet and object that that while it's not perfect, I think we do pretty well, and better than we used to.  Josh agreed with some of what I have to say, and I see his point, too.  But it got me thinking about the whole way that we operate as a development community, and what is good and bad about it.

These issues are particularly near to my heart, because I was a complete newcomer in this community less than three years ago, and boy, rejection was - and is - tough.  We regularly send patches back with a long list of technical deficiencies, and/or questions about the utility of the underlying behavior.  I don't think that any of that is badly meant, and I know that try I very hard to make sure that I'm only talking about THE CODE rather than THE PERSON, but let's face it: when you write code, it's your baby, and if someone doesn't like it, it's easy to take it personally.  You either get angry at the person who wrote the review (if you don't believe their criticisms are accurate) or you feel like an idiot for having failed to notice the problems yourself.  Or at least, I do.  It's some consolation that this process produces very, very good code and that our releases are consistently of high quality, but it can still be very discouraging, especially for newcomers.

Even harder are the patches which get turned away because, in the opinion of whoever takes time to look at them, they're a bad idea: the feature is badly designed, or is in fact an anti-feature.  I am particularly wary of this type of rejection, because people don't usually take the trouble to write a patch in the first place if they don't believe fairly strongly that it solves a real problem.  And if that person thinks it's a real problem, who am I to say it's not?  Moreover, this type of rejection, because it goes to the core of the idea, is somewhat more painful than simply finding out that you have some bugs to fix.  Nevertheless, a certain number of rejections of this type are unavoidable: some ideas really are bad, and figuring out how to deliver that news in a nice way can be challenging - particularly for engineers, who tend to be blunt-spoken by nature.  The fact that we communicate almost entirely by email doesn't make it any easier, either.

I also believe that fatigue plays a role here.  Everyone who works on PostgreSQL does it at least partly on their own time, and most people do it entirely on their own time.  The work of fixing up patches and getting them committed falls on a relatively small number of people, not because it's intrinsically impossible to spread it across more volunteers, but because many more people volunteer to write patches than to review them.  At a certain point, people get tapped out.  They either stop reviewing altogether, or else they continue working on it, but now they're tired, and instead of a detailed explanation explaining why something doesn't work and how to fix it, it turns into a summary dismissal.  Sometimes those summary dismissals are actually totally unwarranted, but most often - at least in my opinion and experience - they are accurate, but not very helpful to the author in figuring out what to do next.

I am not sure exactly how to improve this process, but I'm open to suggestions.  Perhaps needless to say, I don't believe that patch rejection is a phenomenon that is going to go away any time soon.  I think our challenge is, first, to make sure that we don't turn good work away for no reason, and, second, to try to do it in a way that doesn't discourage the person who contributed it from continuing to be involved.  As I said to Josh Drake, I think we're doing better in those areas than we have at some times in the past, but I'd still like to do better.  A growing and thriving and happy base of developers is critical to the success of PostgreSQL, and we can't afford to drive anyone away.


  1. I blogged about this from a slightly different perspective a while back.

    I agree with most of what you wrote.

    We set the bar fairly high. That has a major benefit, as you noted, in code quality. It can also cost us some if developers become discouraged. We need to try to maximise the one and minimise the other.

  2. One could say that getting a patch committed to project as complex and critical as a database _should_ be difficult. It is possible that an uphill battle in getting code submitted makes for a higher quality end product.

  3. Hey!

    You motivated me to post about what I meant last week about meritocracy.

    I agree with you about improvements that have been made, and I hope I made that clear in what I wrote.

    As far as the things about the patch review process to improve -- I think so much has been done to make this better. The numbers about patches that run through the Commitfest process don't lie. :)

    We're just at a point where we need to reach out more than we ever have, and talk more about the things that our community is producing "out in public", rather than just on our mailing lists.

    Another huge thing is formalizing our extensions interfaces, and making pgfoundry not suck. A healthy ecosystem of add-on projects that *looks* healthy to outsiders, would also do wonders.

    I'll think on it more, and post up my thoughts in another post.

    Thanks for taking the time to write about this.