|
[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
>>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.
>> +- 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
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.
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
favour.
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.
>>
>> -
>>-------------------------------------------------------------------------
>>------------
>> - ISSUES TO BE ADDRESSED LATER:
>> - - 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
>quorum.
>
>> + 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
>>that
>
>No. Formal decisonmaking of this sort should not count some votes
>double.
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
>>Elections
>...
>> - Nomination: Community members should nominate candidates by
>>posting a
>> proposal to *appointments at xenproject dot org* explaining the
>>candidate's
>> @@ -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
>>mailing
>> list for wider community input.
>> - Election: A committer will be elected using the decision making
>>process
>> -outlined earlier. Voting will be done by committers for that project
>>privately
>> -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
>>mailing
>> -list.
>> +outlined earlier. In other words, the decision is delegated to the
>>[project
>> +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
>consensus.
Agreed. Will add.
>> +
>>-------------------------------------------------------------------------
>>----------------
>> + **Proposal** **Who reviews?** **Who
>>votes?**
>> + ----------------------------- -----------------------------
>>-----------------------------
>> + 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
>>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,
>> +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
>>the
>> +communiuty manager.
For myself: community
>> +- For each qualifying project with a quorum, the percentage of votes
>>in
>> +favour and against is calculated (e.g. if 5 people voted in favour, 2
>>against
>> +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
>>passes.
>> +Otherwise it fails.
>
>This is a rather complex approach but I don't have a clearly better
>proposal.
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.
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |