You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by James Sirota <js...@apache.org> on 2016/12/16 17:00:46 UTC
Re: [DISCUSS] Modify Bylaws for veto clarification
Matt, I modified the requirement for 2 committers in our coding guidelines to a single review to be consistent with our bylaws. thank you for pointing that out
29.11.2016, 17:09, "Matt Foley" <ma...@apache.org>:
> Forgive me, but this is text editing so I\u2019m 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 \u201cVoting\u201d, which says:
>
> -1 \u2013 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 \u2013 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 \u201cApprovals\u201d, 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 \u201cActions\u201d these votes are specified to be by \u201cconsensus approval\u201d. Consensus means \u201cno -1 votes\u201d, in other words a -1 is a veto. Yet we\u2019ve just declared that vetoes are only valid for code changes, not people votes. So these parts of the \u201cActions\u201d section need to be clarified.
>
> D. There is an inconsistency in the \u201cActions\u201d : \u201cCode Change\u201d paragraph. It says \u201cThe code can be committed after the first +1.\u201d But in https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines , section \u201cMerge requirements\u201d, second bullet, it says \u201cThere should be 2 parties besides the committer that have reviewed the patch before merge.\u201d This inconsistency should be resolved by changing one of the two sentences.
>
> Thanks,
> --Matt
>
> On 11/29/16, 3:30 PM, "Casey Stella" <ce...@gmail.com> 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 <js...@apache.org> wrote:
>
> ����> Hi Guys, any thoughts on this?
> ����>
> ����> 11.11.2016, 16:50, "James Sirota" <js...@apache.org>:
> ����> > 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
> ����>
-------------------�
Thank you,
James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org
Re: [DISCUSS] Modify Bylaws for veto clarification
Posted by Matt Foley <mf...@hortonworks.com>.
Great, agreed. --Matt
On 12/16/16, 9:00 AM, "James Sirota" <js...@apache.org> wrote:
Matt, I modified the requirement for 2 committers in our coding guidelines to a single review to be consistent with our bylaws. thank you for pointing that out
29.11.2016, 17:09, "Matt Foley" <ma...@apache.org>:
> 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" <ce...@gmail.com> 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 <js...@apache.org> wrote:
>
> > Hi Guys, any thoughts on this?
> >
> > 11.11.2016, 16:50, "James Sirota" <js...@apache.org>:
> > > 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
> >
-------------------
Thank you,
James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org