[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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?

> +    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.

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.