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