PostgreSQL's commitfest clog

Talk about its benefits on the mailing list? Add explanation as to how it's organized? Ask if there's a better way to design it? Ideally, the commitfest manager would have some suggestions particular to the patch about what might be putting reviewers off.

Often a patch will get the code exactly right, but the commit message doesn't explain enough about why it's right and give reviewers enough information to check that the author understands the implications entirely. It's almost always possible to add more to the presentation of the patch such that the code ends up the same but the review is easier to do or, especially, easier to get started on. A patch that touches several files will generally have the diffs ordered alphabetically and that's likely not the order in which a logical argument for making the change would go. Beyond the point where the patch is correct and applying it would be the right thing to do, there's a variety of ways that a patch author can make it more obvious that that is the case, and it may be necessary to make the patch more approachable in non-technical ways in order to motivate reviewers.

I wonder what would happen if they adopted the opposite policy: If nobody reviews it, that means nobody has any objections to it, so let's just merge it with no review.

This would, at the very least, provide a stronger motivation for more senior developers to review old patches that are close to the limit (i.e. "you had better review it now, or else it might just get merged by default"). However, I don't imagine it would be appropriate to make such a policy retroactive, and there would probably need to be some kind of limiting principle to prevent abuse (e.g. only if you've sent at least X accepted patches in the past, only if you have fewer than X other patches outstanding, etc.).