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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.16 at 14:53, <lars.kurth@xxxxxxxxxx> wrote:
> 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

That would still leave 10 -1's overruled by a single +1.

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

Maybe when there are no +2's, simply take the sum of all votes,
and require it to be non-negative?

Jan


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