Sorry, I meant: "Consensus check requires 1 binding +1 vote and no binding vetoes."
On 14 November 2013 15:31, Noah Slater <[email protected]> wrote: > This is very irregular. > > I just checked the bylaws, and we have the following verbiage: > > "one +1 from a committer who has not authored the patch followed by a > Lazy approval (not counting the vote of the contributor), moving to > lazy majority if a -1 is received" > > There are four red flags here: > > - A single +1 vote for a proposal to pass seems irregular. (Though I > note that Hadoop uses it. Though, remember that Hadoop is a very big > project and may have problems that we do not.) > - Whereas every other type of decision uses a defined voting model, > code modification does not, and invents one for itself inside the > little "Approval" box > - The ad-hoc voting model in the "Approval" box is actually two > voting models. If one fails, a new one is used. > - The model you switch to if a -1 is received effectively does way > with the idea of code vetos. This seems unusual, and dangerous. > > I think this needs to be fixed. > > I do not like RTC, as I think it adds unnecessary friction to the > contribution process. I think a true lazy consensus approach is much > better. Lazy consensus says that if you think this commit is good for > the project, you may perform it. And we will review it and tell you if > we think it needs changing. (Remember: our VCS is a time-machine!) > > This is a very good page on lazy consensus: > > http://rave.apache.org/docs/governance/lazyConsensus.html > > Note that the "lazy consensus" mentioned in the bylaws is not actually > lazy consensus. This is an error that was carried over from the Kafka > bylaws. (I have emailed them separately to correct it.) > > However, if this community still prefers CTR (despite my > protestations) I suggest you define the voting model "Approvals" > section. And I would recommend that it be defined as: > > "Consensus check requires 3 binding +1 votes and no binding vetoes." > > (Yes, I just invented a term, consensus check, to be like a > lightweight version of a consensus approval vote.) > > On 6 September 2013 12:49, Kasper Sørensen > <[email protected]> wrote: >> +1 :-) >> >> I agree to those rules that you just sketched there (RTC / min 1 vote / 48 >> hours lazy commit). >> >> >> 2013/9/5 Henry Saputra <[email protected]> >> >>> I guess it is the good time to discuss about the MetaModel bylaws =) >>> >>> Here is the link to how ASF Voting process: >>> http://www.apache.org/foundation/voting.html >>> >>> As indicated by the link [1], unless a vote is declared as lazy >>> consensus dictate three +1 votes are required for a code-modification >>> proposal to pass. >>> >>> And it is usually added to the JIRA to track down the vote process. >>> >>> We will need to create bylaws page in wiki or website to help new >>> developers understand how we operate. >>> >>> If it is agreed upon, we could use review-then-commits with at least 1 >>> vote to commit and if no response in 48 hours we could invoke lazy >>> consensus to get the patch going >>> >>> - Henry >>> >>> [1] http://www.apache.org/foundation/voting.html >>> >>> On Thu, Sep 5, 2013 at 12:29 AM, Kasper Sørensen >>> <[email protected]> wrote: >>> > Hi all, >>> > >>> > I wanted to clarify something now since we have seen a few times that >>> > people submit patches directly to JIRA. Which is fine :-) >>> > >>> > But how should we do voting on the patches then? Will we treat JIRA >>> > comments just like any other mail reply, and simply post our "+1"s on the >>> > JIRA issue itself? I also see JIRA has a voting mechanism although I >>> > haven't tried it. Finally we could also opt for re-raising the patch in >>> the >>> > mailing list and only do the votes by mail. >>> > >>> > What do you think is best, and what's common practice for Apache >>> projects? >>> > >>> > Kasper >>> > >>> > PS: Either way is fine by me :-) >>> > > > > -- > Noah Slater > https://twitter.com/nslater -- Noah Slater https://twitter.com/nslater
