I'd suggest you start a [DISCUSS] thread on dev with a clear subject line and try to get consensus through discussion first. Once you think you have consensus, tie it up with a vote. In general, voting should be rare, and only used to "officiate" a consensus that was reached through discussion.
On 19 November 2013 15:14, Kasper Sørensen <[email protected]> wrote: > 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 > > -- Noah Slater https://twitter.com/nslater
