From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Xen-devel <xen-devel@lists.xen.org>
Subject: Survey Results - Part 3 : Improving Xen Project Governance and Conventions
Date: Fri, 16 Oct 2015 16:37:28 +0100 [thread overview]
Message-ID: <F3AE7229-2BC9-47A7-BE07-ED68210E18E5@gmail.com> (raw)
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@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2015-10-16 15:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 15:37 Lars Kurth [this message]
2015-10-21 15:02 ` Changing the voting model, Was: Survey Results - Part 3 : Improving Xen Project Governance and Conventions Stefano Stabellini
2015-10-21 15:59 ` Lars Kurth
2015-10-22 15:04 ` George Dunlap
2015-10-22 16:20 ` Stefano Stabellini
2015-10-23 10:04 ` Jan Beulich
2015-10-26 14:31 ` Lars Kurth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F3AE7229-2BC9-47A7-BE07-ED68210E18E5@gmail.com \
--to=lars.kurth.xen@gmail.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.