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 22 Oct 2015, at 16:04, George Dunlap <dunlapg@xxxxxxxxx> 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?

I was mainly looking at this from the viewpoint of project-wide (or-subproject 
wide) policy decision and giving more people which are active in the project a 
stake in policy decisions. I have noticed that very few people outside 
committers today engage in these discussions. What I don't know is whether this 
is because the formal decision in the end lies with the committers and whether 
more people would engage, if they had a formal say.

> 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).

I am assuming you refer to "Thus, as a last resort when consensus cannot be 
achieved on a question internal to a project, the final decision will be made 
by a private majority vote amongst the committers and project lead. If the vote 
is tied, the project lead gets an extra vote to break the tie."

If we had an active project lead, this would be good enough. In reality we do 
not have an active project lead any more. So we could theoretically end up in 
with a tie. There is also a provision for the Advisory Board to provide the 
casting vote (although not on project internal matters). I really wouldn't want 
to end up in a situation, where the "Advisory Board" makes a casting vote. In 
any case, the text in "Last Resort" does not seem to be reflecting the current 
reality of not having an active project lead. 

In particular as in the survey we established that we prefer the status-quo of 
a committee based project leadership, rather than a "benevolent dictator" 
model, with which we started with and which the governance still assumes. Part 
of the reason why I kicked off the survey, was to see whether a) we had any 
glaring issues somewhere, b) see how we future proof the governance based on 
the now validated assumption that we would probably not elect a new project 
lead. 

I also think that "Elections and Formal Votes" in [1] is not very clear: for 
example, it is not really clear whether a majority say in a "Committer 
Election" or a "Process/Convention change" would suffice. Aka, whether the 
"Last Resort" section applies to formal governance related votes. In practice, 
we always had full consensus and often treated formal votes as if negative 
votes were a veto. I remember at least one cases, where Jan registered an 
objection, but phrased it such that he would go with a majority view. 
 
> 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.

And it appears to me that we have not had any incidents and issues in this area.

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

I agree. I still claim though that sections "roles / project lead", "conflict 
resolution" and "elections and formal votes" would probably benefit from being 
cleaned up and made clear. And maybe, we can take this as an opportunity to 
come up with an approach that better encourages contributions (in the general 
sense, not just code contributions). I also remember that Konrad pointed us to 
the "Code of Conflict" that Linux has, but that does not seem sufficient in 
light of Sarah Sharp's recent resignation as a Linux Maintainer.

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