[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 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
>>> +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
>>> +proposal. To make use of it, post something like the following on the
>>> +mailing list (or some other communication channel):
>>> -    - 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,
>>> -are taken with a lazy consensus approach: a few positive votes with no
>>> -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
>>> +**lazy consensus** is in the body of your message (this helps set up
>>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>> +stake-holders are, the project leadership can nominate a group of
>>> +to decide, or may choose to own the decision collectively and resolve
>>> +
>>> +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
>>> +-   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?


MirageOS-devel mailing list



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