I have drafted a second version of this. I made the following changes:
1. Based on Dmitriy's feedback on clarity for code change votes, I changed the approval column of the code change row of the voting table to say:
"Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received"
I think this expresses what Dmitriy believed to be the case that every code change requires a +1 from a committer that is not the contributor of the code. Note that this is stronger than what I indicated had been our practice in the past (to allow contributors to +1 committer's patches). But it seems reasonable. If a contributor knows the code well enough to give authoritative votes on contributions s/he should probably be a committer. And as far as I know this was only done on Zebra because it had only one committer.
2. Based on Dmitriy's feedback on the horrors of rolling back checkins (done by responding with a -1 on a commit message), I added the following sentence:
"Note that this should be a rare occurrence. All efforts should be made to discuss issues when they are still patches before the code is committed."
3. Based on Olga's feedback of the need for timetables for votes, I defined a minimum length for each type of vote. All vote lengths are in business days. I set code changes at 1 day; release plan, product release, new committer, and new PMC member at 3 days; and adoption of new code base, committer removal, and PMC member removal at 6 days. I picked 1 day for code changes because we don't want to wait long periods of time to get patches in but we should wait at least a day so that developers all around the world can take a look. I used 3 days for other common votes as that is the length currently used by Hadoop. I picked 6 days for the others because these are momentous votes and 6 days guarantees one week for everyone to consider and respond.
4. As suggested by Olga I reviewed other Apache projects to find their requirements for consensus votes. Most of the projects I reviewed had no bylaws that I could find. httpd and Jakarta had bylaws that covered voting but none discussed votes such as removing committers or PMC members that we stipulate would require unanimous votes with no abstentions. Both Ant and Xerces did have bylaws for this, and both require unanimous votes with no abstentions to remove a committer or PMC member. See http://ant.apache.org/bylaws.html, http://jakarta.apache.org/site/decisions.html , http://httpd.apache.org/dev/guidelines.html, http://xerces.apache.org/charter.html for details.
Given that we had one speak in favor of lowering this bar (Olga) and 2 speak in favor of the bar where it is (Alan and Santhosh), for the moment it stays where it is. If others have thoughts on this, please contribute them.
5. In response to Ben's suggestion on pre-announcing votes, I added the following sentence to the guidelines on voting:
"In general votes should not be called at times when it is known that interested members of the project will be unavailable."
This is weaker than what Ben suggested, but I'm not comfortable with having to pre-announce votes, as we want the project to be able to move as quickly as possible. Is this strong enough for you Ben?
Alan. On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:
As directed in our vote to become a TLP, we (Pig's PMC) need to set out bylaws for the project. I have put up a first proposal for these by laws at http://wiki.apache.org/pig/ProposedByLaws. Please take a look and give feedback. Alan.
