How about I update the document to take into account Nathan¹s comments. Then turn it into a formal pull request. Then we can continue the discussion, and put more pull requests on top of it until we graduate and have a formal vote on adoption. Then at that point we can move the bylaws into the subversion web page repo, or add a link to the github repo for the bylaws. Either way is fine with me.
I am canceling the vote. - Bobby On 6/28/14, 3:15 PM, "P. Taylor Goetz" <[email protected]> wrote: >I agree completely! > >I think adding ³work in progress² or ³DRAFT² in the title will prevent >any confusion. And maybe cancel the vote and treat it more like a patch >for now. Then when it¹s time to formally adopt the bylaws, we can hold >the official vote. > >- Taylor > >On Jun 28, 2014, at 2:31 PM, Nathan Marz <[email protected]> wrote: > >> My impression was that this was a vote to adopt the bylaws, since it >>says >> "proposed bylaws" and the vote required consensus approval. >> >> Regardless, I agree that we should merge it into source control and >> collaborate on it with pull requests/comments, and we should delay a >>vote >> until everyone's issues have been addressed. However, let's add "work in >> progress" to the title so people don't get confused. >> >> >> On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <[email protected]> >>wrote: >> >>> I¹m +1. >>> >>> I think with Bobby¹s latest changes it makes it abundantly clear that >>>it >>> is a working draft, and we are not voting to adopt them. I see this as >>>a >>> vote to pull the draft into source control so individual changes can be >>> proposed and discussed as opposed to trying to approve the document in >>>it¹s >>> entirety. >>> >>> Trying to get everything right all at once places undue burden on >>>Bobby ‹ >>> a veto forces him to cancel the vote, interpret the comments, reword >>>things >>> to address the comments, and initiate a new vote. Bobby was kind >>>enough to >>> put it together in the first place. >>> >>> I think it would be more efficient if we just staged it in source >>>control >>> (we wouldn¹t have to publish it to the website), and allow people to >>> collaborate by proposing changes/patches that can be discussed and >>>applied >>> individually. Again, the document doesn¹t carry any weight until it is >>> finalized and formally adopted. >>> >>>> Lastly, I want to address something that Taylor said in the previous >>>> discussion: >>>> >>>> 'Understood. Also be aware that lazy consensus can be invoked for code >>>> changes by declaring so in the pull request: ³I will assume lazy >>> consensus >>>> on this and commit the change in X hours if there are no -1 votes.² >>> >>> That should have read ³days² instead of ³hours,² so it came across a >>> little more drastic than intended... >>> >>>> >>>> I think Hadoop uses lazy consensus as the default, but I¹d have to >>> check.' >>>> >>>> I'm not sure where "be aware that lazy consensus can be invoked for >>>>code >>>> changes by declaring so in the pull request" came from. Is this a rule >>> that >>>> Hadoop or other Apache projects use? Ultimately each project >>>>determines >>> for >>>> themselves the rules for committing what Hadoop or other projects do >>> has >>>> no relevance on Storm. This is certainly not something we ever agreed >>>>to >>>> for the governance of Storm. >>> >>> That came from here [1]. But looking at it again it seems to conflict >>>with >>> a RTC policy (even though some projects seem to use lazy consensus with >>> RTC). So I stand corrected. >>> >>> My point is that yes, other Apache projects do use lazy consensus for >>>code >>> changes, so it is an option that open to us if we so choose. Nothing >>>more. >>> >>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's >>> development >>>> has gone through some pretty ridiculous things, like the completely >>> broken >>>> record append implementation and the fiasco around the mapred.* and >>>> mapreduce.* namespaces. I believe Storm to be a much higher quality >>>>piece >>>> of software (though not perfect, of course) and we should try keep it >>> that >>>> way. >>> >>> >>> I never meant to imply that we should aspire to be like Hadoop. I was >>> merely using it as an example in the context of a bylaws discussion. >>> >>> If there¹s on goal we all share, I think it¹s to make Storm the highest >>> quality piece of software we can. That¹s why we¹re here. >>> >>> No project is perfect. We will inevitably make mistakes, fix them, >>>learn >>> from them, and grow stronger as a community in the process. >>> >>> - Taylor >>> >>> [1] http://www.apache.org/foundation/voting.html >>> >>> >>> On Jun 27, 2014, at 8:16 PM, Nathan Marz <[email protected]> wrote: >>> >>>> -1 (binding) >>>> >>>> I've given this quite a bit of thought, and I think we need to be more >>>> explicit in the bylaws in a few places. >>>> >>>> 1. Code changes: >>>> I've reverted a bit and think that a single +1 from any committer >>> (besides >>>> author of patch) and no -1's is sufficient to commit code. >>>> >>>> I also think we should explicitly make exceptions to these rules for >>>> non-code related changes (e.g. documentation). In these cases we can >>>>use >>>> lazy consensus and the committer can use their own discretion as to >>>>how >>>> long the vote should be open. >>>> >>>> 2. Releases: >>>> The bylaws mention a "release plan". We haven't been proposing or >>>>voting >>> on >>>> release plans and I don't think that's necessary as a formal process. >>>>I >>>> think any committer can propose a release at any time, something >>>>Taylor's >>>> been doing a good job of doing. Should we just remove that from the >>> bylaws? >>>> >>>> There was also discussion of allowing for "fast releases" for >>>>important >>>> changes that can't wait (e.g. security fixes). I am fully against >>>>this. >>>> Based on the previous discussion it sounds like we're in agreement >>>>that >>> any >>>> committer can make unofficial releases available publicly, and this is >>> the >>>> avenue we can use to get these fixes out. This way we don't commit >>>> ourselves to any code changes or any need to maintain backwards >>>> compatibility. >>>> >>>> I think the vote time for releases should be 7 days, not 3 days. A >>> release >>>> is a big deal and people need more time to test it and give feedback. >>> Also, >>>> any change to the release should require a revote. Taylor brought up >>>>that >>>> this could make getting a release out a pain and I agree. So I'm >>>>fine >>>> with including explicit exceptions in the bylaws to this rule, like >>>>not >>>> requiring a revote for changes to documentation, committer info in >>> pom.xml, >>>> etc. >>>> >>>> >>>> >>>> >>>> Lastly, I want to address something that Taylor said in the previous >>>> discussion: >>>> >>>> 'Understood. Also be aware that lazy consensus can be invoked for code >>>> changes by declaring so in the pull request: ³I will assume lazy >>> consensus >>>> on this and commit the change in X hours if there are no -1 votes." >>>> >>>> I think Hadoop uses lazy consensus as the default, but I¹d have to >>> check.' >>>> >>>> I'm not sure where "be aware that lazy consensus can be invoked for >>>>code >>>> changes by declaring so in the pull request" came from. Is this a rule >>> that >>>> Hadoop or other Apache projects use? Ultimately each project >>>>determines >>> for >>>> themselves the rules for committing what Hadoop or other projects do >>> has >>>> no relevance on Storm. This is certainly not something we ever agreed >>>>to >>>> for the governance of Storm. >>>> >>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's >>> development >>>> has gone through some pretty ridiculous things, like the completely >>> broken >>>> record append implementation and the fiasco around the mapred.* and >>>> mapreduce.* namespaces. I believe Storm to be a much higher quality >>>>piece >>>> of software (though not perfect, of course) and we should try keep it >>> that >>>> way. >>>> >>>> >>>> >>>> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans >>>><[email protected] >>>> >>>> wrote: >>>> >>>>> I have updated the proposed bylaws following Nathan and Taylor¹s >>>>> suggestions. They the only parts edited were the title to indicate >>>>>that >>>>> these are proposed bylaws and will not officially be adopted until we >>> are a >>>>> top level project, and the voting on code changes to reflect that a >>>>>+1 >>>>> from the author of the patch is not counted. >>>>> >>>>> You can find them here. >>>>> >>>>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md >>>>> >>>>> The new voting is consensus approval with (P)PMC members casting >>>>>binding >>>>> votes. >>>>> >>>>> - Bobby >>>>> >>>> >>>> >>>> >>>> -- >>>> Twitter: @nathanmarz >>>> http://nathanmarz.com >>> >>> >> >> >> -- >> Twitter: @nathanmarz >> http://nathanmarz.com >
