Re: new CommitFest states

I didn't really get any feedback on my proposal to add a new "Discussing
review" state to help out the reviewers and CF manager. To show how
adding it helps track the common flow of patches through the system, I
turned the whole CF into a big state machine and marked how the
transitions should normally happen at
http://wiki.postgresql.org/wiki/Running_a_CommitFest

If you carefully read the "Followup" section, which Robert wrote
initially, you can see it implies such a state exists via the "Bogged
down in discussion" comments. I'd just like to have a way to flag
patches that are entering discussion because the reviewer isn't sure
what happens next as such directly, to make this whole process more
mechanical, fair, and predictable to the bulk of the participants
(reviewers and authors). I wasn't able to figure out how to do that
without adding this additional state to the system.

Robert's main objection to this idea, that at any point there should be
one obvious person with the next action to take and authors should take
more responsibility for their patch, is a good ideal. But since the CF
manager ends up being the backstop for breakdowns in the process,
they're always a second possible source for transitions. I'd rather
them be a more predictable such source for a number of reasons.

Note that a major secondary goal here is to make it easier to bring
on-board new CF managers and have them hit the ground running, by having
near deterministic suggestions for much of what they need to do. It's
also not a coincidence that some of the more boring parts of that job
step toward being specified well enough that one might start automating
them too. How to construct a simple "nag bot" that mails
pgsql-rrreviewers to perform most of the CF actions listed here is
pretty obvious working from this table.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com