From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars Kurth Subject: Re: Changing the voting model, Was: Survey Results - Part 3 : Improving Xen Project Governance and Conventions Date: Mon, 26 Oct 2015 14:31:49 +0000 Message-ID: <2B36E31B-4AAF-4951-A6A8-AACDC121431A@gmail.com> References: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Campbell , Ian Jackson , Stefano Stabellini , Tim Deegan , Xen-devel List-Id: xen-devel@lists.xenproject.org > On 22 Oct 2015, at 16:04, George Dunlap wrote: > > On Wed, Oct 21, 2015 at 4:02 PM, Stefano Stabellini > 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