You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2013/11/09 01:31:10 UTC

[DISCUSS ] Apache Flex guidelines RC1 - discussion

Hi,

Please discuss any issues here not in the vote thread.

Thanks,
Justin 

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Alex Harui <ah...@adobe.com>.

On 11/9/13 2:26 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Add "of the votes cast" if you want to avoid any and all confusion.
>That's is even more misleading IMO. eg Think about 4 x +1 and 3 -1's.
I may be missing something.  What is misleading about 4 +1's and 3 -1's?
That's a majority approval to me.

-Alex


Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Add "of the votes cast" if you want to avoid any and all confusion.
That's is even more misleading IMO. eg Think about 4 x +1 and 3 -1's.

> And as the general rules are very unclear
IMO the rules are fairly clear, is just the terminology that's an issue and inconsistent across projects.

> I don't feel the need to attach too much importance to the copy paste
> attempts of other projects. Let's just make the best rules for our project 
+1  Patches welcome.

Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Erik de Bruin <er...@ixsoftware.nl>.
Add "of the votes cast" if you want to avoid any and all confusion.

And as the general rules are very unclear, I don't feel the need to attach
too much importance to the copy paste attempts of other projects. Let's
just make the best rules for our project (within the confines of the Apache
by laws) and rely on the other projects to follow ours ;-)

EdB



On Saturday, November 9, 2013, Justin Mclean wrote:

> Hi,
>
> > +1 on the lazy removal.
> Are you 100% sure? That goes against the language used by just about every
> other Apache project.
>
> > No one expects half of the list subscribers plus one to vote :-)
>
> It's happened more than once and in fact occurred in the last week on this
> list.
>
> Thanks,
> Justin



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> +1 on the lazy removal.
Are you 100% sure? That goes against the language used by just about every other Apache project.

> No one expects half of the list subscribers plus one to vote :-)

It's happened more than once and in fact occurred in the last week on this list.

Thanks,
Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Erik de Bruin <er...@ixsoftware.nl>.
+1 on the lazy removal. No one expects half of the list subscribers plus
one to vote :-)

EdB



On Saturday, November 9, 2013, Alex Harui wrote:

>
>
> On 11/8/13 10:17 PM, "Justin Mclean" <justin@classsoftware.com<javascript:;>>
> wrote:
>
> >Hi,
> >
> >> Hmm. Well Roy emailed recently in some other similar discussion to
> >>confirm
> >> that majority is not "full majority".
> >So what do you suggest re changes to the guidelines?
> Taking out Lazy everywhere except for "Lazy Consensus".
>
> >
> >I can point to at least one example of where Majority was interoperated
> >to be more than 1/2 the voting pool.
> Maybe we should be clear about that in our definitions.
>
> >
> >Looking at project bylaws I'd guess more than 3/4 use the term "Lazy
> >Majority" even though it not included in the official glossary.
> I think I'll stir the pot on Incubator and ask ;-)  Sometimes, a bad
> phrase just propagates.
>
> -Alex
>
>

-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Taking out Lazy everywhere except for "Lazy Consensus".
The issue I have with that is that majority is then misread as more than 50% of all committers/PMC members. What o other people think?

> Maybe we should be clear about that in our definitions.
That certainly can be done.

> I think I'll stir the pot on Incubator and ask ;-)  
Please give feedback here as no everyone can see what goes on there.

Thanks,
Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Alex Harui <ah...@adobe.com>.

On 11/8/13 10:17 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Hmm. Well Roy emailed recently in some other similar discussion to
>>confirm
>> that majority is not "full majority".
>So what do you suggest re changes to the guidelines?
Taking out Lazy everywhere except for "Lazy Consensus".

>
>I can point to at least one example of where Majority was interoperated
>to be more than 1/2 the voting pool.
Maybe we should be clear about that in our definitions.

>
>Looking at project bylaws I'd guess more than 3/4 use the term "Lazy
>Majority" even though it not included in the official glossary.
I think I'll stir the pot on Incubator and ask ;-)  Sometimes, a bad
phrase just propagates.

-Alex


Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Hmm. Well Roy emailed recently in some other similar discussion to confirm
> that majority is not "full majority".  
So what do you suggest re changes to the guidelines?

I can point to at least one example of where Majority was interoperated to be more than 1/2 the voting pool.

Looking at project bylaws I'd guess more than 3/4 use the term "Lazy Majority" even though it not included in the official glossary.

Thanks,
Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Alex Harui <ah...@adobe.com>.

On 11/8/13 9:45 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>My guess is that "Lazy Majority" terminalogy is used instead of
>"Majority Approval" as that could be taken to mean more than 1/2 of the
>existing committers/PMC members may vote. Lazy Majority is an indication
>that the majority is not a full majority.
Hmm. Well Roy emailed recently in some other similar discussion to confirm
that majority is not "full majority".  To me Lazy means that those in
favor don't have to vote since that seems to be the main difference
between Consensus and Lazy Consensus.  And then I don't get how it applies
to Majority and 2/3 Majority.

>
>Justin


Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

My guess is that "Lazy Majority" terminalogy is used instead of  "Majority Approval" as that could be taken to mean more than 1/2 of the existing committers/PMC members may vote. Lazy Majority is an indication that the majority is not a full majority.

Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Alex Harui <ah...@adobe.com>.
I guess I just don't get what is Lazy about it.  I can understand how
Consensus can be lazy, but not 2/3 majority.  I noted that Ant didn't have
"Lazy 2/3 Majority" and just "2/3 Majority".

Can you explain the difference between a Lazy and non-Lazy majority?  I'd
rather just call it Majority Approval like it is in the Glossary.

-Alex

On 11/8/13 9:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>>  "Lazy Majority" and "Lazy 2/3 Majority" just doesn't make sense to me.
>These are exactly as most other Apache projects including HTTP (it
>doesn't mention 23rd majority however).
>
>From http://httpd.apache.org/dev/guidelines.html.
>"An action item requiringmajority approval must receive at least 3
>binding +1 votes and more +1 votes than -1 votes"
>"Lazy majority decides each issue in the release plan."
>
>See here:
>http://ant.apache.org/bylaws.html
>https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
>http://hadoop.apache.org/bylaws.html
>http://pig.apache.org/bylaws.html
>https://cwiki.apache.org/confluence/display/Hive/Bylaws
>https://cloudstack.apache.org/bylaws.html
>http://wiki.apache.org/jclouds/Bylaws
>
>And probably others (just a  quick search).
>
>There a little variation on if it called "Lazy Majority" or "Majority
>Approval" but the rules are the same.
>
>(Note Hive is a little different as it make a distinction between "Lazy
>Majority" and "Lazy Approval" and "Lazy Consensus".)
>
>And also here:
>http://www.apache.org/dev/release.html
>http://www.apache.org/foundation/glossary.html#ConsensusApproval
>http://www.apache.org/foundation/glossary.html#MajorityApproval
>
>Rules are the same but refers to it in the glossary as Majority Approval.
>"Votes on whether a package is ready to be released use majority approval
>-- i.e., at least three PMC members must vote affirmatively for release,
>and there must be more positive than negative votes. Releases may not be
>vetoed."
>"Refers to a vote (sense 1) which has completed with at least three
>binding +1 votes and more +1 votes than -1 votes. ( I.e. , a simple
>majority with a minimum quorum of three positive votes.) Note that in
>votes requiring majority approval a -1 vote is simply a vote against, not
>a veto. "
>
>>  The HTTP guidelines sort of explain something like that as "Lazy
>>approval" until someone votes -1..."
>That's lazy censuses not majority.
>
>> Otherwise, as soon as someone votes -1, everyone who had silently
>> consented and moved on to something else now has to keep tabs on the
>>vote
>> and see that and then vote.
>Encourages people to vote and have a say IMO and the person who raised
>the vote to encourage other people to vote - just like a release. The
>only common action that require Majority voting are releases. I guess the
>the guidelines may change occasionally (2/3 Majority). I hope we don't
>have the situation where we have to vote on removal of PMC or committer
>members that often.
>
>> Minor nit:  In "Code Change" I think "any" is missing in this portion:
>> "-1 vote by other committer"
>Changed. I think that can be considered a very minor change and not
>require a new RC - especially given that no one has actually voted yet.
>
>Thanks,
>Justin


Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

>  "Lazy Majority" and "Lazy 2/3 Majority" just doesn't make sense to me.
These are exactly as most other Apache projects including HTTP (it doesn't mention 23rd majority however).

From http://httpd.apache.org/dev/guidelines.html.
"An action item requiringmajority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes"
"Lazy majority decides each issue in the release plan."

See here:
http://ant.apache.org/bylaws.html
https://cwiki.apache.org/confluence/display/KAFKA/Bylaws
http://hadoop.apache.org/bylaws.html
http://pig.apache.org/bylaws.html
https://cwiki.apache.org/confluence/display/Hive/Bylaws
https://cloudstack.apache.org/bylaws.html
http://wiki.apache.org/jclouds/Bylaws

And probably others (just a  quick search).

There a little variation on if it called "Lazy Majority" or "Majority Approval" but the rules are the same.

(Note Hive is a little different as it make a distinction between "Lazy Majority" and "Lazy Approval" and "Lazy Consensus".)

And also here:
http://www.apache.org/dev/release.html
http://www.apache.org/foundation/glossary.html#ConsensusApproval
http://www.apache.org/foundation/glossary.html#MajorityApproval

Rules are the same but refers to it in the glossary as Majority Approval.
"Votes on whether a package is ready to be released use majority approval -- i.e., at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed."
"Refers to a vote (sense 1) which has completed with at least three binding +1 votes and more +1 votes than -1 votes. ( I.e. , a simple majority with a minimum quorum of three positive votes.) Note that in votes requiring majority approval a -1 vote is simply a vote against, not a veto. "

>  The HTTP guidelines sort of explain something like that as "Lazy approval" until someone votes -1..."
That's lazy censuses not majority.

> Otherwise, as soon as someone votes -1, everyone who had silently
> consented and moved on to something else now has to keep tabs on the vote
> and see that and then vote.
Encourages people to vote and have a say IMO and the person who raised the vote to encourage other people to vote - just like a release. The only common action that require Majority voting are releases. I guess the the guidelines may change occasionally (2/3 Majority). I hope we don't have the situation where we have to vote on removal of PMC or committer members that often.

> Minor nit:  In "Code Change" I think "any" is missing in this portion:
> "-1 vote by other committer"
Changed. I think that can be considered a very minor change and not require a new RC - especially given that no one has actually voted yet.

Thanks,
Justin

Re: [DISCUSS ] Apache Flex guidelines RC1 - discussion

Posted by Alex Harui <ah...@adobe.com>.
Hi, I should have looked after you made your edits.  I'm actually hoping
for a lot less "Lazy" in the document.  "Lazy Majority" and "Lazy 2/3
Majority" just doesn't make sense to me.  The HTTP guidelines sort of
explain something like that as "Lazy approval" until someone votes -1...",
but why can't we just make these actions "Majority" and "2/3 Majority"?
Otherwise, as soon as someone votes -1, everyone who had silently
consented and moved on to something else now has to keep tabs on the vote
and see that and then vote.  I think we should just have folks vote.

Minor nit:  In "Code Change" I think "any" is missing in this portion:
"-1 vote by other committer"

-Alex

On 11/8/13 4:31 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>Please discuss any issues here not in the vote thread.
>
>Thanks,
>Justin