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

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



On Wed, Oct 21, 2015 at 4:02 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> ! = 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?

I'm a bit confused by this discussion.  Are we talking about checking
in code, or about project-wide policy decisions?

For patch review, in general, no patch goes in while there are any
outstanding objections, regardless of who is doing the objecting
(consensus).  But it is permissible for maintainers of the code being
changed to override the person objecting, if they are not a
maintainer.  It is understood that this should be done only after a
reasonable discussion, and only if the maintainer thinks there is a
good reason to do so.

According to the governance doc [1], we are supposed to *try* to form
a consensus; but in the case that a consensus cannot be formed, things
fall back to a majority vote among the committers.  This parallels the
above example with patch review, but at a community-wide level: we
should first try to have a reasonable discussion, but if we cannot
achieve consensus, then a majority of committers can override the
objector (even if she is a committer).

There's some verbiage in there about this being a "last resort" in the
case that the community "becomes paralyzed", but I think we shouldn't
necessarily see it as quite so extreme: it should simply be understood
that such an override should only happen after a reasonable
discussion, and the override should only be given if the committers
think there is a good reason to do so.

The only "veto model" we have is where there is overlapping
maintainership: if a single maintainer says "no", then in theory that
is a veto for a particular patch to go in.  I think having a major
argument between maintainers would be quite exceptional, and if we hit
this situation then we clearly have a breakdown of relationships that
needs to be addressed with the individuals (in the last resort by
asking someone to step down as a maintainer), not by clarifying the
governance model.

 -George

[1] http://www.xenproject.org/governance.html

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


 


Rackspace

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