Sorry for chiming in so late ... Noah, I think I agree to what you're saying. And this was only a draft and as you see it was mostly a edited copy/paste of Kafka's by laws.
Wrt. lazy concensus or not - I would go for the thing that we believe maximizes the involvement of the community. Obviously for a committer like myself it's much more practical with CTR... But might not be the opinion of outside people. On the other hand they could simply "commit" by making a pull request, patch or something like that and I think that is fine. Shall we do a vote on the CTR vs RTC approach? 2013/11/14 Noah Slater <[email protected]> > 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 >
