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.