[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

 


Rackspace

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