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
