Re: [MirageOS-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 12/08/2016 13:41, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

>>>> On 12.08.16 at 01:13, <lars.kurth@xxxxxxxxxx> wrote:
>> +### Lazy Consensus {#lazyconsensus}
>> +
>> +Lazy Consensus is a useful technique to make decisions for specific
>>proposals 
>> +which are not covered by the Review Then Commit Policy or do not
>>require a more 
>> +formal decison (see below). Lazy Consensus is extremely useful, when
>>you don't 
>> +anticipate any objections, or to gage whether there are objections to
>>a 
>> +proposal. To make use of it, post something like the following on the
>>project's 
>> +mailing list (or some other communication channel):
>>  
>>      
>>-------------------------------------------------------------------------
>>------------
>> -    ISSUES TO BE ADDRESSED LATER:
>> -    - The "Consensus Decision Making" section is totally wrong. It
>>does not describe
>> -      "Lazy Consensus"
>> +    Should we set a fixed time-frame? If so what?
>>      
>>-------------------------------------------------------------------------
>>------------
>>  
>> -Sub-projects or teams hosted on Xenproject.org are normally
>>auto-governing and
>> -driven by the people who volunteer for the job. This functions well
>>for most 
>> -cases. When more formal decision making and coordination is required,
>>decisions 
>> -are taken with a lazy consensus approach: a few positive votes with no
>>negative 
>> -vote are enough to get going.
>> +    > I am assuming we are agreed on X and am going to assume lazy
>>consensus: <
>> +    > if there are no objections within the next seven days.
>>       <
>> +
>> +You should however ensure that all relevant stake-holders which may
>>object are 
>> +explicitly CC'ed, such as relevant maintainers or committers, ensure
>>that 
>> +**lazy consensus** is in the body of your message (this helps set up
>>mail 
>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>relevant 
>> +stake-holders are, the project leadership can nominate a group of
>>stake-holders 
>> +to decide, or may choose to own the decision collectively and resolve
>>it.
>> +
>> +Objections by stake-holders should be expressed using the [conventions
>> +above](#expressingopinion) to make disagreements easily identifiable.
>> +
>> +__Passed/Failed:__
>> +
>> +-   Failed: A single **-2** by a stake-holder whose approval is
>>necessary
>> +-   Failed: **-1**'s by all stake-holder whose approval is necessary
>> +-   Passed: In all other situations
>
>Hmm, that means all -1's except a single 0 would already be a pass?

That is not the intention. If we have only -1's and 0's it should be a
fail. 
Let me fix this in the next revisions.

How about: 
+-   Failed: Only **-1** or **0** votes by all stake-holder whose approval
is necessary


Although maybe someone can come up with a clearer way to express this.


>> +    Let me express this as an algorithm.
>> +
>> +      treshhold=2/3;
>> +      active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>> +      favour='number of +1 and +2 votes'
>> +      against='number of -1 and -2 votes'
>> +      strong-against='number -2 votes'; just added this as a sanity
>>check
>> +
>> +    One open question is what to do with 0-votes. We could introduce a
>>rule discounting 
>> +    0 votes (let's call it 0-rule). If someone votes 0, we assume they
>>really don't care
>> +    about the outcome and are considered inactive for the purpose of
>>the vote. 
>> +
>> +    In that case:
>> +
>> +      active -= 0-votes;
>> +
>> +    Without the 0-rule:
>> +    - to pass: favour/active >= treshhold
>> +      to pass: with active==7, favour >= 5
>> +      in other words, 3 (0,-1,-2)-votes block the proposal as we cant
>>achieve favour>=5
>> +
>> +    With the 0-rule, let's consider 1, 2 or 3 0-votes
>> +    1=>6: to pass: favour >=4
>> +          in other words, 3 (-1,-2)-votes block the proposal
>> +    2=>5: to pass: favour >=4
>> +          in other words, 2 (-1,-2)-vote blocks the proposal
>> +    3=>4: to pass: favour >=3
>> +          in other words, 2 (-1,-2)-vote blocks the proposal
>> +
>> +    Looking at the arithmetic, it does probably make sense to go for
>>the 0-rule. If we
>> +    do, there ought to be more votes in favour of a proposal, than
>>0-votes.
>> +
>> +    On the other hand, not having the 0-rule forces everyone to form
>>an opinion, 
>> +    otherise we will find it hard to make decisions. But in some
>>cases, forming an
>> +    opinion costs significant mental capacity.
>> +
>> +    It would also allow us to remove the complexity of differentiating
>>between
>> +    active and non-active leadership team members by assuming that no
>>vote, equals
>> +    a "0" vote.
>> +
>> +    Opinions?
>
>I'm in favor of the "with 0-rule" variant.

That's what I assumed most people would go for and which is (hopefully
correctly)
implemented in the rules above the comment section.

Regards
Lars

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel