GitHub protections

[JohnMoehrke]

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches

[JohnMoehrke]

I think that we should implement these kind of protections once a repo goes into TI publication. but I am not exactly sure, so would like discussion.
what rules should be applied, when, etc...

[JohnMoehrke]

I did put these kind of rules in place for FormatCode repo.

[lukeaduncan]

I think it's a good idea. I think for this repo and publications. We could start with only allow pull requests to update the main branch and require reviews of the pull request. If others seem useful we can certainly try them as well and see if it's more harmful than helpful.

For the others, I don't think it's as necessary since they only affect a CI build. Perhaps once something is final text we'd do the same protections as for publications and this?

Is this something we should discuss in a planning meeting or maybe at the next face to face? Even to just confirm or review after setting them up?

[JohnMoehrke]

I think Trial-Implementation repos should also. Trying to think about the downside to that protection, and the only thing that comes up is updates needed simply due to the tooling changes (Grahame's fault).

[JohnMoehrke]

I think we concluded on this, but can't find where I documented that. I would expect it should be documented in:

• https://github.com/IHE/publications/wiki/Revision-Management
• https://github.com/IHE/publications/wiki/Public-Comment-phase
• https://github.com/IHE/supplement-template/wiki/IG-build-for-Publication

should it be a standalone article pointed to by these?

[JohnMoehrke]

Committee members should be given "Write" (is necessary to create pull-requests)
Committee co-chairs should be given "Admin" (unclear this or maintain)