Regarding just the issue [C], voting for new committers and new PMC members:
The old and now deprecated approach of having such votes be by “consensus approval”, where in fact any -1 was a veto, was intended by Apache for the sake of community harmony. However, it has been found by hard experience to actually encourage restricting membership, which is not a good thing. The current content of http://www.apache.org/foundation/voting.html is clear that only votes on code changes should allow vetoes. It is silent on the topic of votes for new committers or PMC members. However, it does say: “Votes on procedural issues follow the common format of majority rule unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of lazy consensus for a modifying factor.)” So I guess we can consider votes for new committers and PMC members to be “procedural”, and select one of the majority-based voting styles. I guess I would recommend “Lazy 2/3 Majority” as being closest to the sense of consensus approval. We could also consider footnote 9 in http://community.apache.org/apache-way/apache-project-maturity-model.html which says: “In Apache projects, "consensus" means widespread agreement among people who have decision power. It does not necessarily mean "unanimity".” But I think it is better to select a majority-based voting style rather than try to give substance to this vague observation. Cheers, --Matt On 11/29/16, 4:08 PM, "Matt Foley" <[email protected] on behalf of [email protected]> wrote: Forgive me, but this is text editing so I’m going to get editorial. A. In the current Bylaws, https://cwiki.apache.org/confluence/display/METRON/Apache+Metron+Bylaws , there are two paragraphs that might be affected by this change. The first is a bullet under “Voting”, which says: -1 – This is a negative vote. On issues where consensus is required, this vote counts as a veto. All vetoes must contain an explanation of why the veto is appropriate. Vetoes with no explanation are void. It may also be appropriate for a -1 vote to include an alternative course of action. I suggest that this should read: -1 – This is a negative vote. On issues where consensus is required, this vote counts as a veto. Vetoes are only valid for code commits and must include a technical explanation of why the veto is appropriate. Vetoes with no or non-technical explanation are void. On issues where a majority is required, -1 is simply a vote against. In either case, it may also be appropriate for a -1 vote to include a proposed alternative course of action. B. Second, under “Approvals”, there is currently: A valid, binding veto cannot be overruled. If a veto is cast, it must be accompanied by a valid reason explaining the reasons for the veto. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid. If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, any action that has already been taken must be reversed in a timely manner. I suggest that this should read: A valid, binding veto regarding a code commit cannot be overruled. If a veto is cast, it must be accompanied by a valid technical explanation giving the reasons for the veto. The technical validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid. If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, any action that has already been taken must be reversed in a timely manner. C. The above changes impact the semantics of PMC votes for new committers and new PMC members. Under “Actions” these votes are specified to be by “consensus approval”. Consensus means “no -1 votes”, in other words a -1 is a veto. Yet we’ve just declared that vetoes are only valid for code changes, not people votes. So these parts of the “Actions” section need to be clarified. D. There is an inconsistency in the “Actions” : “Code Change” paragraph. It says “The code can be committed after the first +1.” But in https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines , section “Merge requirements”, second bullet, it says “There should be 2 parties besides the committer that have reviewed the patch before merge.” This inconsistency should be resolved by changing one of the two sentences. Thanks, --Matt On 11/29/16, 3:30 PM, "Casey Stella" <[email protected]> wrote: Yeah, I can agree with that. I believe the procedure for this is to vote on the bylaws change and a simple majority of the PMC members is required to ratify. On Tue, Nov 29, 2016 at 6:27 PM, James Sirota <[email protected]> wrote: > Hi Guys, any thoughts on this? > > 11.11.2016, 16:50, "James Sirota" <[email protected]>: > > going through the Apache Maturity Model we have to respond to the > following point: > > > > CS40In Apache projects, vetoes are only valid for code commits and are > justified by a technical explanation, as per the Apache voting rules > defined in CS30. > > > > The voting section of our bylaws does not currently explicitly define > this: > > https://cwiki.apache.org/confluence/display/METRON/Apache+Metron+Bylaws > > > > I propose to add the following bullet point to the Voting section of our > bylaws: > > > > - Vetoes are only valid for code commits and are justified by a > technical explanation > > > > This way we are unambiguously covered with regards to this point upon > our review during graduation > > > > What do you think? > > > > ------------------- > > Thank you, > > > > James Sirota > > PPMC- Apache Metron (Incubating) > > jsirota AT apache DOT org > > ------------------- > Thank you, > > James Sirota > PPMC- Apache Metron (Incubating) > jsirota AT apache DOT org >
