I am fine with consensus approval for the first vote. As you said, having the PMC be in agreement about this is important.
I also want to clarify that you want me to change the text in the Code Change action from "(at least one from someone who has not authored the patch).² to "from committers other than the one who authored the patch, and no -1¹s² The other comments seem related to suggestions that Taylor brought up and not the current version of the bylaws. If I misunderstood you please let me know. If you feel that the one change is important enough to restart the vote or if I misunderstood your comments please let me know and I¹ll make the appropriate changes and restart the vote. - Bobby On 6/20/14, 2:29 PM, "Nathan Marz" <[email protected]> wrote: >First off it doesn't make sense to use the voting rules in the bylaws >we're voting on as we haven't adopted the bylaws yet. I think that forming >the initial set of bylaws should require consensus approval. We don't have >that many PPMC members that this is going to hold us back, and I think >it's >important that we're all in complete agreement on the bylaws moving >forward. Obviously if we agree to this set of bylaws than future changes >can be accomplished with lazy 2/3 majority. > >A few things: > >- Code changes should be two +1's from committers other than the one who >authored the patch, and no -1's. I don't think a case where only a single >+1 is needed to get a change committed allows for sufficient review. This >is also the rule we all agreed to in the move to Apache and also before. > >- I think keeping the roles of PMC member and committer separate in the >bylaws is fine. I can see how having a PMC that's too big could slow down >a >project, so I can see how we'll reach a point where we'll want to propose >people as committers and not PMC members. I don't think having this >distinction in the bylaws in any way slows down the project, as we can >just >propose people to be both committers and PMC members as we have been all >along. > >- It's true that there are certain cases where we'd want to get changes in >quickly (e.g. security fix). However, making mechanisms for getting things >in quickly would also make it possible to get things in that haven't been >sufficiently reviewed and could be detrimental to the project. An >alternative is to not change any of the processes for making official >Storm >releases, and instead make alternative pathways to make "unofficial" >releases based on work that hasn't been fully vetted through the normal >process. These releases would have the caveat that whatever is in them >could change or be removed in a future release. This way we can get things >out to the community quickly if need be, but make sure that nothing gets >into a permanent release that hasn't been properly vetted. The process for >"emergency release" could be something like lazy consensus over a 1 day >vote, or maybe one +1 and no -1's over a 1 day vote. Those releases would >be tagged something like 0.9.2-hotfix1, and an emergency release would be >followed by a normal vote as to whether to do an official release with >those changes. > >- I do not think we should try to make a distinction between "minor" >changes to a release and "normal" changes that do or do not require a >re-vote. How are we really going to come up with a definition of "minor" >that's not ambiguous? I don't see there being any rush to getting releases >out a couple days earlier, and I view it as far more important to ensure >that sufficient review is done such that we don't release something bad to >the community. Even "minor" changes can go horribly wrong, as I'm sure >we've all experienced before. So everything should be properly vetted and >any changes should require a re-vote. As stated in the prior point I think >we can have separate pathways for "emergency" releases that are distinct >from normal releases. > > > >On Fri, Jun 20, 2014 at 10:16 AM, Andy Feng <[email protected]> wrote: > >> +1 >> >> On 6/20/14, 6:05 AM, "Bobby Evans" <[email protected]> wrote: >> >> >I got almost no feedback on the bylaws. I am hoping everyone thought >>they >> >were a good idea and not that the document was so long that few >>bothered >> >to >> >read it. Either way I am calling a vote on the bylaws. >> > >> >In accordance with the proposed bylaws the vote will run for 7 days >>ending >> >Friday June 27th, and will require at least 3 +1s from active (P)PMC >> >members with at least twice as many +1s as -1s. Others in the >>community >> >are encouraged to vote as well to let your opinion be known, even if >>your >> >vote is not binding. >> > >> >If the vote passes I'll update the storm web page to include the >>bylaws. >> >I >> >am +1 (binding) >> > >> >You can find the markdown formatted bylaws at >> > >> > >> >>https://github.com/revans2/incubator-storm/blob/84d297a23c05fef5164029bd4 >>b >> >697071aa349f9c/BYLAWS.md >> > >> >I only updated the formatting from the original proposal as you can see >> >here >> > >> > >> >>https://github.com/revans2/incubator-storm/commit/84d297a23c05fef5164029b >>d >> >4b697071aa349f9c#diff-77abd199a39cb67711132cd27fe41f6b >> > >> >- Bobby >> >> >> > > >-- >Twitter: @nathanmarz >http://nathanmarz.com
