Fair enough. Let's pull them in and work on solidifying them as we move toward graduation.
+1 -Taylor > On Jun 20, 2014, at 11:33 AM, Bobby Evans <[email protected]> wrote: > > Taylor, > > I do like all of your suggestions. Like I said in the initial mail I am > mostly concerned about capturing the informal rules we have now and > formalizing them. The bylaws I see as a living document that should be > updated regularly to reflect how we want to run the project. As such I > would prefer to adopt the current bylaws and have a separate > discussion/vote on your proposed changes. > > That being said, I do realize that small changes associated with a release > are needed and no project I have worked on has forced release managers to > follow the strict rules in those cases, or when a checkin went badly and a > rollback is needed. So If you want me to make that formal, as I don¹t see > that as being controversial, I am happy to do that and restart the vote if > you feel it is needed. > > - Bobby > >> On 6/20/14, 8:41 AM, "P. Taylor Goetz" <[email protected]> wrote: >> >> Bobby, >> >> Thanks for putting this together and my apologies for not providing >> feedback sooner. >> >> The proposed bylaws make a distinction between committers/(P)PMC >> members. Currently, all committers are also (P)PMC members. I think this >> works for the number of members we have now. If that list gets really big >> later, we may want to change the bylaws to make a distinction. >> >> For code changes do we want to have some provision for getting changes in >> under 2 days if necessary (e.g. an important security fix, etc.) and/or >> the ability to do lazy consensus for code changes? >> >> Another thought I have is concerning changes made during release >> preparation. In the past I¹ve taken some liberty here when small changes >> that don¹t affect the main code or functionality (for example to the >> Maven build) are necessary. Otherwise, going through a 2-day vote for >> minor pom changes could adversely affect our ability to release. For >> example, if I make a mistake and need to need to do a `mvn >> release:rollback`, I would like to be able to just do it. Obviously major >> changed to the build (like when we switched from leinengen to maven) >> would follow the regular code change rules. >> >> Other than those concerns, I think the bylaws look pretty good. >> >> - Taylor >> >>> On Jun 20, 2014, at 9: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 >>> b697071aa349f9c/BYLAWS.md >>> >>> I only updated the formatting from the original proposal as you can see >>> here >>> >>> >>> https://github.com/revans2/incubator-storm/commit/84d297a23c05fef5164029b >>> d4b697071aa349f9c#diff-77abd199a39cb67711132cd27fe41f6b >>> >>> - Bobby >> >
