|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [win-pv-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
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |