+1 to those 2 bullet points Casey. And thanks Justin for adding the Jira for fixing the website.
I can think of 2 good examples to borrow from recently that were submitted by community contributors. Shane Ardell brought up a discussion about migrating from Protractor to Cypress, and Tamas Fodor brought up a discussion about migrating from momentjs to date-fns. This greases the skids by engaging community members and explaining the scope of proposed changes. As always, committers are able to -1 something at any time, so I would imagine that any contributor would be well advised to get as much buy in as possible prior to any large undertaking. And I would expect those PR's to reference the original DISCUSS threads when they come to fruition. Another example comes to mind from Ryan M with his PCAP feature branch. It was a lot of work, but Ryan put out a DISCUSS thread back in, I think it was May, outlining the intent for the FB. Subsequently, he followed up at the end with an accounting of all the requests from the original DISCUSS and any deviations from that along the way, and provided a clear explanation of what was in, what wasn't, what should be followed up with, and why. In fact, at one point I think there were some library changes that we saw as orthogonal to the intent of the FB and suggested they be made outside of the FB. Imho, this FB worked out well, though take this with a grain of salt as I may be biased because I was also involved with a number of PRs. I think Nick Allen also put together a good archetype for a FB with his recent work on the batch profiler. I see a couple introductory DISCUSS threads about the FB along with some back and forth around introducing Spark into the stack. He also followed up at the end to make sure there wasn't anything further the community wanted before he pushed to have the branch merged into master. *TL;DR* - We've learned a lot since the earlier days of the project, and our subsequent feature branches have gotten much better. We should take the lessons learned along the way and formalize them as Casey is recommending in our bylaws. I'll be following up with more specific thoughts on language. Best, Mike On Fri, Sep 28, 2018 at 10:13 AM Justin Leet <justinjl...@gmail.com> wrote: > Ticket created: https://issues.apache.org/jira/browse/METRON-1799 > > I think that whole '/develop' is orphaned and can be dropped. > > On Fri, Sep 28, 2018 at 12:12 PM Casey Stella <ceste...@gmail.com> wrote: > > > I just noticed this, but googling "metron bylaws" yields > > http://metron.apache.org/develop/bylaws.html which is not our bylaws. > Our > > bylaws are on > > https://cwiki.apache.org/confluence/display/METRON/Apache+Metron+Bylaws > > > > We should fix that. > > > > On Fri, Sep 28, 2018 at 12:02 PM Casey Stella <ceste...@gmail.com> > wrote: > > > > > Hi All, > > > > > > Given discussions about the current high-profile feature branch (Knox > > > SSO), I thought it might be appropriate to have a conversation about > what > > > constitutes a feature branch and get some of this encoded in the > > community > > > guidelines. > > > > > > Specifically, there was the request made that we split up the Knox SSO > > > feature branch due to the current implementation including a distinct, > > new > > > architectural change (specifically, in my mind, the migration from > > > expressjs to Spring Boot + Zuul). In that discussion, I made the > > assertion > > > that "for my mind a feature branch should involve the minimum > > > architectural change to accomplish a given feature." (I apologize for > > > quoting myself here ;) . I realize, however, that we have not encoded > > > this in our bylaws and I might not be speaking with the authority of > the > > > community at my back. > > > > > > Ultimately, I feel very sad that we didn't get around to clarifying > this > > > and we're in a situation where, had we made this clarification earlier, > > > we'd not be in a situation where a contributor has to make a major > > > refactoring to a substantial feature. To that end, I think we should > > > hammer this out once and for all so it's clear. > > > > > > So, I'd like to separate out this discussion here. My justification > for > > > my belief (beyond that I think it's the correct thing to do) was the > > > precedent set with 777, admittedly pre-feature branches, wherein we > > > requested a series of splits to get to smaller units of functionality > and > > > isolate large architectural changes. I think that it is good practice > to > > > isolate major feature changes to separate feature branches to ensure > that > > > we get sufficient discussion around each of those changes. To that > end, > > > I'd like some language encoded into the bylaws describing this. > > > > > > So, I'm opening up the discussion. Most specifically what I'd like to > > > know is: > > > > > > - What do you think about the idea that feature branches should > > > contain the minimal architectural changes to accomplish a feature > > (unless > > > the full scope of architectural changes are mentioned in the discuss > > thread > > > about the feature)? > > > - If you agree (or disagree), do you think a change to the bylaws is > > > merited to encode this policy? If you do think so, then what > wording > > would > > > you suggest? > > > > > > > > > Hopefully that all makes sense. > > > > > > Casey > > > > > >
