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
throwout 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
documentwhere the item is in the review process. As another idea maybe have a status to indicate that the patch has
beenreviewed for formatting. It might make things easier to deal with because a ticket identified as WIP is obviously
notready for a CF etc etc. Hell you may even be able to find somebody to take care of reviewing formatting and
dealingwith 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
mustI think. That shouldn't be too hard to setup. I don't think this is a cure all but transparency to status in the
processis surely going to give first timers more of a warm and fuzzy.
--
Kevin Barnard
kevinbarnard@mac.com
