[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

On 20/09/2016 18:01, "Ian Jackson" <ian.jackson@xxxxxxxxxxxxx> wrote:

>Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision
>making; some new roles and minor changes"):
>> [proposal]
>Thanks.  I've reviewed this and it looks generally good but I have
>some specific comments.
>Throughout you use "gage" where I think you should use "gauge".
>(AFAICT from Wiktionary this is not a US/UK spelling thing.)

Will fix.

>> +Voting is conducted in line with the following rules:
>> +
>> +-   Project leadership team members vote for (**+1**) or against
>>(**-1**) a 
>> +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
>> +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
>> +to pass. In other words, if the leadership team has 7 members, at
>>least 4 
>> +active votes are required for a resolution to pass.
>> +-   The resolution passes, if a 2/3 majority of active votes is in
>>favour of 
>> +it. 
>Quorums like this should count only positive votes.  Otherwise someone
>who opposes a proposal has to guess whether it is more likely to fail
>quorum, or to fail the 2/3 majority.  If it is likely to fail quorum,
>they should refrain from voting.

I think probably the term quorum is leading to some confusion here and
should probably be changed. Basically what

+-   A **quorum of more than 50% of active votes** is required for a
+to pass. In other words, if the leadership team has 7 members, at least 4
+active votes are required for a resolution to pass.

is trying to encode is a turnout threshold of >50% (discounting spoilt
ballot papers: in other words a **0** votes would be the equivalent of a
spoilt ballot paper). My thinking was that
A) The rules would encourage team members to vote for or against a
proposal, rather than abstain
B) The minimum threshold is there to ensure that we don't have to manage
disappearing leadership team members tightly and that decisions have
enough legitimacy
C) The 2/3 majority would only apply to the people that have voted for or
against a proposal

>For example with a team of 6, with two people having alread voted yes,
>and the remaining three having expressly declined to vote because they
>don't have an opinion, a leadership team member who votes "no" would
>move the outcome from "quorum not met since only 2 out of 6 active
>voters - fail" to "quorum met with 3 active voters, 2 votes in favour,
>one against, 2/3 majority met - pass".

This is wrong. With a team of 6, at least 4 people would need to vote
"yes" or "no" to pass the 50% threshold. If more than "2" decline to vote,
the threshold wont be achieved. Amongst the 4 votes, 3 would need to be in

But you are right, this does open the door to tactical voting in some
boundary cases. So if there were 2 active "0" votes and 3 "+1" votes, the
last voter could shoot down the proposal by voting "0". If the vote had
been secret, that person would probably vote "-1" and the proposal would
pass. The same applies, if we were close to the voting deadline and 3
people had voted "+1" and 2 had not.

I am not quite sure I understand what you mean by "otherwise someone who
opposes a proposal has to guess whether it is more likely to fail quorum,
or to fail the 2/3 majority", but I guess it is what I outlined above. I
suppose the whole issue would go away, if there was a secret vote. But
introducing this, would be a bit heavyweight.
>I suggest changing the quorum threshold to count only explicit
>abstentions and votes in favour; either 1/3 or 50% would do.

I am not suggesting this is a bad idea, but I don't think I fully
understand what you mean and how your proposal avoids the issue above.

>> -### Conflict Resolution
>> +    Let me express this as an algorithm.
>> -    
>> -    - Generalise refereeing in terms of Project Leadership instead of
>>specific roles
>> -    - Also some examples for sPecific situations that have happened in
>>the past may be 
>> -      useful
>> -    
>> +      treshhold=2/3;
>         threshold
>> +      active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>                                                                         ^
>                                                   at the time of
>writing, 2016-09-20
>> -#### Refereeing
>> +    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. 
>With my proposal you can delete this because 0-votes do not affect
>> +    The other question is whether to treat -2-votes different than
>>-1-votes. We could
>> +    say there should not be more than 20% -2-votes. That would mean
>No.  Formal decisonmaking of this sort should not count some votes

This entire section was just an illustration of my thought process.

>> +    The entire last resource section goes, because it is essentially
>>not needed any more,
>                       ^^^^^^^^
>                       Resort

ACK. Thanks.

>> +#### Committer, Security Team Member and other Project Leadership
>>  -   Nomination: Community members should nominate candidates by
>>posting a 
>>  proposal to *appointments at xenproject dot org* explaining the
>> @@ -299,74 +606,123 @@ review all proposals, check whether the nominee
>>would be willing to accept the
>>  nomination and publish suitable nominations on the project's public
>>  list for wider community input.
>>  -   Election: A committer will be elected using the decision making
>> -outlined earlier. Voting will be done by committers for that project
>> -using a voting form that is created by the community manager. Should
>>there be a 
>> -negative vote the project lead and community manager will try and
>>resolve the 
>> -situation and reach consensus. Results will be published on the public
>> -list.
>> +outlined earlier. In other words, the decision is delegated to the
>> +leadership team](#leadership).
>This misses out appointments to the security team.  I suggest that
>they should usually be made by the team itself according to lazy

Agreed. Will add.

>> +  
>> +  **Proposal**                  **Who reviews?**              **Who
>> +  ----------------------------- -----------------------------
>> +  Creating, graduating,         Members of developer mailing
>>Leadership teams of
>> +  completing/archiving of       lists of qualifying projects
>>**mature** sub-projects,
>> +  sub-projects                                                with the
>>exception of the 
>> +                                                              project
>>which is being 
>> +                                                              reviewed
>>(e.g. for an 
>> +               
>>archivation review, the
>> +               
>>leadership team of the
>> +                                                              project
>>under review, cannot
>> +                                                              vote).
>> +
>> +  Global Process Changes        Members of developer mailing
>>Leadership teams of
>> +                                lists of qualifying projects
>>**mature** sub-projects,
>> +                                                              within
>>the scope described
>> +                                                              above.
>> +-   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
>> +members do not vote or abstain, the entire sub-project's vote is not
>> +This avoids situations where only a minority of leadership team
>>members votes, 
>> +which would skew the overall result. If it becomes clear, that a
>>sub-project is 
>> +not likely to meet the quorum, the voting deadline can be extended by
>> +communiuty manager.

For myself: community

>> +-   For each qualifying project with a quorum, the percentage of votes
>> +favour and against is calculated (e.g. if 5 people voted in favour, 2
>> +and 1 abstains, the share is 5/7th and 2/7th respectively).
>> +-   Votes in favour are averaged as percentages across all projects
>>(say we 
>> +have per project figures of 50%, 80%, 70% in favour, then the total
>>vote in 
>> +favour is 66.67%).
>> +-   If the total vote is more than 2/3rds in favour, the proposal
>> +Otherwise it fails.
>This is a rather complex approach but I don't have a clearly better

I know. I have been thinking about this for ages and couldn't come up with
something better. We may have to change the 50% quorum to be in line with
your proposal or to improve the language.


Xen-devel mailing list



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