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.