[Xen-devel] Survey Results - Part 3 : Improving Xen Project Governance and Conventions

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

Hi all, 

please find results of part 2, following on from 
- Part 1 : 
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg00354.html 
- Part 2 : 
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01871.html

Part 4 will be omitted : too many different opinions.

Results and comments are marked with | under each question. Followed by an  
analysis, which is marked with !

Best Regards
Lars


== 3) Other related Governance Issues  --


There are a number of other shortfalls in 
http://www.xenproject.org/governance.html 
that have been raised in the past. Namely ...

 * <u>Voting for Governance Changes</u>

   http://lists.xen.org/archives/html/xen-devel/2014-11/msg01548.html raised 
   the issue that voting for governance changes is tied to committer status. 
   One issue with the current set-up is that the XAPI sub-project for example 
   does not differentiate between maintainers and committers and Mirage OS is 
   similar (aka all maintainers are also committers). Thus, the number of 
   qualifying XAPI votes (and in future Mirage OS votes) is significantly 
   higher than in the Hypervisor. This could create issues when voting for 
   global policy changes once Mirage OS graduates.

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

| Sub-projects should have a single vote; if they have multiple committers, 
| they should vote amongst themselves to determine how to vote on a project 
| wide change. 

! I think the proposal for Xen Project wide issues also makes sense: aka 
! "Sub-projects should have a single vote" which are then tallied up and
! follow all the other rules.

| Contribution-weighted votes would be nice, but you would need to find a 
| way to not only count submissions or commits, but also code reviews.

| I'd prefer a) with maybe the possibility to let the committers decide
| whether to ask a wider audience regarding a specific change.

| In terms of our existing people, this should be all the committers
| plus a small number of the existing maintainers.

| I would be in favor of separating committership from project leadership;
| but I haven't seen a proposal which I actually like better than a.

| I think a publicly elected committee of X people would be the best
| option. I have however not clear ideas on who should be allowed to vote.
| I guess doing it by contributions is a step forward, but we should be
| very careful with this, so that people don't start sending trivial
| patches in order to get a vote.
| 
| Should we also then consider other projects which are related to Xen but
| it's code doesn't reside inside of the Xen repository (Qemu, Linux...)?

! = Summary =
!
! We seem to have a clear majority to expand the pool of voters, but no
! real consensus on whom to add. There is a slight preference towards c)
! aka a group representing the project leadership consisting of committers
! plus some additional people. I think I would like to get some feedback
! on this thread and then make a concrete proposal. Elections are not unusual
! in open source projects when it comes to boards, but not so common for 
! the leadership: there is also a chicken and egg problem (in other words,
! who elects the leadership).

Please state a preference and explain why. Note that a) and b) donât fit XAPI, 
Mirage OS, ... This means that we may not be able to retain a single 
governance document across all projects. A fudge could be for each project to 
nominate/elect a leadership using project local criteria (aka c), which then 
vote on behalf of that subproject. Also consider, what would encourage 
community members to step up getting more actively engaged with reviews and 
other areas where we have bottlenecks today.

 * <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

| Yes, though I think the current system of voting 0 and explaining a
| weak preference in words does just as well.
|
| Note that there were a few comments along those lines.

| Yes, this ought to be workable. 

| I question whether the current model of a single negative vote blocking 
| a vote is a good one: The UN Security Council is good example of
| why one shouldn't allow single entities to veto everything.

! This seems to be clear cut 

 * <u>Majority</u>

 Every -1 vote today, is essentially a veto. With a growing pool of votes, it 
 becomes possible for an individual to block progress. Without a referee (see 
 Q2.6), who we are currently assuming in our governance will resolve a 
 conflict, we could find ourselves in a limbo.

Q3.3: Do you think introducing a deadlock resolution approach would make 
sense, if designed to be used in exceptional circumstances only. Would a 
majority based approach make sense?

| 10 / 12 Agree
| 0 / 12 Disagree
| 2 / 12 Don't know or have no opinion

| If we extend the voting to maintainers or expand the number of
| committers, then yes, but we should not use a simple majority -- after
| all we want to reach consensus.  We could require, e.g., a majority in
| favour and no more than 20% (strongly) opposed.

| If we allow for deadlocks to occur, we need such an approach

| I'm a little bit wary of designing new forms of government and voting etc,
| since the law of unintended consequences often comes into play.

| I think that we should abolish the blocking veto in governance votes.
|
| As a first step it should be possible for a voter to vote against
| something without vetoing it.

| I thought the goal was always for the committers to go along with the
| consensus of the community, and then to fall back to a majority vote if
| consensus failed.

! On the point above, I think this was the case for some things (e.g.
! process) but not for others, such as appointing new committers. In
! practice this is sort of broken, I think. Even if this was the goal,
! what would happen if a committer persistently votes against the 
! consensus.

! = 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.


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