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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 22 Oct 2015, George Dunlap wrote:
> 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.

What is written on the governance is not what I was expecting from the
quoted text above and my experience on xen-devel.

Actually I reread the governance before writing my email yesterday, but my
conclusion was that nobody likes to resort to the "last resort",
therefore things get stalled during the initial consensus phase. I don't
recall seeing the "last resort" vote ever being called.

Do you think that this is what is happening? Maybe we just need to
follow the current governance model a bit more closely and invoke the
"last resort" vote more often?

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