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
