Clarification on Contributing doc

[scsides]

In the Contributing doc the rules are for the "repo". This would include all branches under that repo. Is that the intent? It might be reasonable to allow branches to be somewhat more agile, and keep the requirements on the main/master/dev tight. If branches remain under the same rules, would the multiple rapid PRs required to create a new release from a branch fall under the trivial clause?

[rbeyer]

That document applies to the "the ISIS_TC repo". One could assume (although this is not explicitly stated) that this contributing policy would also apply to the ISIS repo. As you point out, I think the TC may decide that the ISIS repo should have contributing guidelines which are modified from these.

Now that we have this doc in place for the ISIS_TC, we can have discussions like this, and decide what changes, if any should happen there, and then think about what the "ISIS repo" contributing doc should be, which I agree may need to be different.

[scsides]

I was projecting too far, but I still think a branch is a very good place to make changes to one or more TC documents, and loosening up the requirements for branches makes them even more useful. Nothing in a branch is official; only the master can rule them all.

[jessemapel]

I agree, non-release branches are sometimes just two collaborators, so relaxing the merge requirements to just one approval makes sense. Merging those branches into the release branch, though, would be like any other PR onto it.

[rbeyer]

I don't think it matters a great deal for the TC, since I agree that only the 'master' branch needs the protections. However, its a matter of defaults. Do we make this the default: current situation for the master only, and any other branch just needs one, or do we make the current situation the default, and just make decisions about individual branches that relax those restrictions?

[AndrewAnnex]

reducing the up-front costs to a side branch would be my base assumption for participating with an open source project. Work In Progress [WIP] branches tend to move fast and then "mature" when submitted as PRs.

[jlaura]

Without a PR or additional conversation by the next meeting (7.14.2020), we are considering closing this issue. Please feel free to reopen at a later date if this is still a pertinent issue.