[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] [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 _______________________________________________ Xen-api mailing list Xen-api@xxxxxxxxxxxxx https://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |