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
