[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] [PATCH v3 4/4] Addressed comments on quorum and security team members
On 03/10/2016 17:27, "Ian Jackson" <ian.jackson@xxxxxxxxxxxxx> wrote: >Lars Kurth writes ("[PATCH v3 4/4] Addressed comments on quorum and >security team members"): >> Main changes >> Leadership team decisions: express quorum in terms of +1 votes >> Security Team Members: election >> Project Wide Decision Making: minor text changes > >The resulting series is a little odd because your v3 4/4 patch only >changes things that are introduced in v3 3/4 and agreed to be probably >wrong there. I would have been more usual to fold these changes in, >at least if the series related to code. I will merge the two for the next version : hopefully the last > >> --- a/governance.pandoc >> +++ b/governance.pandoc >> @@ -410,18 +410,26 @@ resolution. There is no differentiation between >>**+1**/ **+2** and >> **-1**/**-2**: in other words a **+2** is counted as a vote for, a >>**-2** as a >> vote against the resolution. The number of votes for and against a >>resolution >> is called **active vote**. **0** votes **are not counted** as an >>active vote. >> -- A **quorum of more than 50% of active votes** is required for a >>resolution >> -to pass. In other words, if the leadership team has 7 members, at >>least 4 >> -active votes are required for a resolution to pass. >> +- A **quorum of at least 1/3 of +1 votes for a proposal** is >>required for a >> +resolution to pass. In other words, if the leadership team has 7 >>members, at >> +least 3 members need to vote for the resolution. > >This paragraph should say `positive' rather than `+1', since as >written it appears to exclude +2. (Same in the table.) Agreed >> #### Project Lead Elections >> >> @@ -553,10 +568,10 @@ as outlined below. >> - Project leadership team members vote for or against a proposal >>(there is no >> differentiation between **-1**/**-2** and **+1**/**+2**). A **0** vote >>is not >> counted as a valid vote. >> -- A **quorum of more than 50%** of each project's leadership team >>members is >> -required. In other words: if more than half of a project's leadership >>team >> +- A **quorum of at least 50%** of each project's leadership team >>members is >> +required. In other words: if fewer than half of a project's leadership >>team >> members do not vote or abstain, the entire sub-project's vote is not >>counted. >> -This avoids situations where only a minority of leadership team >>members votes, >> +This avoids situations where only a minority of leadership team >>members vote, > >This still has the non-monotonicity problem. > >I would suggest to deal with this issue by, when calculating the >percentage, dividing all the votes by the larger of (a) the number of >people voting (including `0' votes); (b) one third of the size of the >project leadership team. > >So if only two out of a 10-person leadership team vote, and they both >votes in favour, that subproject's overall vote is > 2 / max(10/3, 2) >which = 2 / max(10/3, 6/3) = 2 / (max(10,6) / 3) = 2 / (10/3) > = 2 * (3/10) = 6 / 10 = 0.6 = 60% > >I would add a further backstop that a successful resolution must have >positive votes from at least three (or maybe, two) separate people. Let me play with this Originally I was planning on changing the quorum to match the one for leadership teams for consistency. Lars _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |