From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Changing the voting model, Was: Survey Results - Part 3 : Improving Xen Project Governance and Conventions Date: Thu, 22 Oct 2015 16:04:55 +0100 Message-ID: References: Mime-Version: 1.0 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: Stefano Stabellini Cc: Lars Kurth , Tim Deegan , Ian Jackson , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org 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? 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