Re: [Xen-devel] Changing the voting model, Was: Survey Results - Part 3 : Improving Xen Project Governance and Conventions

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 21 Oct 2015, at 17:02, Stefano Stabellini 
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 
> On Fri, 16 Oct 2015, Lars Kurth wrote:
>> * <u>Blocking Votes</u>
>> 
>>   We had several cases, where a voter wanted to express disagreement with a 
>>   proposal, but did not want to block a vote. I wanted to suggest an 
>>   approach that we used very successfully in Event Program Management 
>>   Committees. 
>> 
>>   It is based on splitting -1 into
>>    -1 : disagree, but donât care enough to argue against it
>>    -2 : disagree, but feel strongly enough to argue against it
>>   and +1 into 
>>    +1: agree, but donât care enough to argue for it
>>    +2: agree, but care strongly enough to argue for it
>> 
>>   Note that the -2, ... +2 is merely a shorthand and is not intended for 
>>   counting and could be replaced by some other shorthand.
>> 
>> Q3.2: Do you think such a proposal makes sense and is workable? 
>> 
>> | 11 / 12 Agree
>> | 0 / 12 Disagree
>> | 1 / 12 Don't know or have no opinion
> 
> [...]
> 
>> ! = Summary =
>> !
>> ! There seems to be a clear consensus against the current veto model. From
>> ! the comments there was no clear case for a simple majority, but for a 
>> higher
>> ! bar of consensus (2/3, 75% or <20% objections) depending on the size
>> ! of the group.
>> !
>> ! So I suppose again, I will let this run for a bit and then get some 
>> ! feedback to be incorporated into a proposal.
> 
> This seems to be a good place to start to make changes based on the
> results from the survey.
> 
> Everybody seems to agree on changing the voting model from consensus to
> some kind of majority vote among committers. I agree with Lars: we
> should gather a few proposals then call a vote to see which one is the
> best for us.
> 
> I think we should avoid counting abstentions and blank votes, only
> positive and negative votes by committers count, and go with a simple
> majority.
> 
> What do you think?

To be honest, ideally I would prefer to also look at who can vote as part of 
this topic, rather than making two separate changes within a few months, if 
that can be avoided. In particular, a higher threshold for a small group (5 
committers) in effect still amounts to a veto. 

<20% objections of 6 committers, is 1 vote against = retains a veto in practice
<25% objections of 6 committers, is 1.25 votes against would count as a veto 
depending on rounding 
<33% of objections of 6 committers, is 1.66 votes against

A majority vote would require 4 positive votes if all committers voted. And 3 
positive votes if 4 or 5 committers voted.

In practice, for most issues we typically had 4 votes. Which sort of retains 
the veto,
If fewer committers vote, the arithmetics look even worse.

Looking at 

> Q3.1: How would you feel about changing the pool of people that are allowed 
> to 
> vote on governance changes. Possible groups that may be allowed to vote could 
> be 
> 
> a) Committers (now), 
> b) Committers and Maintainers (possibly after changing criteria for both), 
> c) A new, yet to be defined group, which constitutes the project leadership 
>  (see Q2.6), 
> d) An approach which makes key contributors eligible based on the previous 
>  yearâs contribution (e.g. the top X contributors, each contributor who 
>  contributed more than X% last year, â) - we could limit the number of 
>  eligible voters based on sub-project size for global policy votes. 
> e) Some combination of c) and d) 
> 
> | We had people voting for multiple options equally. So this result has
> | to be considered with some care.
> |
> | a)           3   
> | b)           3 
> | c)           5
> | d)           2 
> | e)           1
> | No opinion:  2

and doing the sums. e.g. ...

a + No opinion = 5 ... let's count these as against increasing the pool of 
voters
b + c + d + e = 13 ... let's count these in favour of increasing the pool of 
voters

... I would argue that we have a clear majority to increase the pool of voters 
on policy and governance changes. 

The question is 

A) How big should the pool of people qualifying to vote on governance changes 
be? For simplicity, let's just call that set of people "leadership team". I 
think it is clear that active Committers should be part of the team. I would 
say that the current Release Manager should be included also. Around 10-12, 
seems a reasonable number.

B) From what I can tell, there are no objections to include a subset of 
maintainers into the "leadership team". And it would make sense. 

C) There seems to be a bias against automatically adding maintainers based on 
some rules (e.g. contribution stats) on the grounds that such a system can be 
gamed

D) Given C, the only option is then to go for some nomination / election based 
approach, where "X maintainers" are elected to be part of the "leadership team" 
for a term of "Y years" (I would recommend that Y is > 1 year; maybe 2). Maybe 
with a provision that if someone stops contributing, for a set period of time, 
they drop out of the "leadership team".

One concern with voting is that a vendor could take over the project: maybe 
there should be limits to how many people of a single vendor can be in the 
leadership team.

All that is missing is a concrete proposal.  

Best Regards
Lars





_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel