On May 9, 2011, at 12:53 PM, Josh Berkus wrote: > > 2) Our process for reviewing and approving patches, and what criteria > such patches are required to meet, is *very* opaque to a first-time > submitter (as in no documentation the submitter knows about), and does > not become clearer as they go through the process. Aster, for example, > was completely unable to tell the difference between hackers who were > giving them legit feedback, and random list members who were > bikeshedding. As a result, they were never able to derive a concrete > list of "these are the things we need to fix to make the patch > acceptable," and gave up. >
I know I'm not in the position to talk work flow as it effects others and not myself, but I though I would at least throw out an idea. Feel free to completely shoot it down and I won't take any offense. A ticketing system with work flow could help with transparency. If it's setup correctly the work flow could help document where the item is in the review process. As another idea maybe have a status to indicate that the patch has been reviewed for formatting. It might make things easier to deal with because a ticket identified as WIP is obviously not ready for a CF etc etc. Hell you may even be able to find somebody to take care of reviewing formatting and dealing with those issues before it get's sent to a committer. I know the core group is use to the mailing lists so a system that can be integrated into the mailing list would be a must I think. That shouldn't be too hard to setup. I don't think this is a cure all but transparency to status in the process is surely going to give first timers more of a warm and fuzzy. -- Kevin Barnard kevinbarn...@mac.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
