Suggestions for repo settings

[mpbelhorn]

We should probably add to this repo:

• Setup collaborators and team members on the repo; I think multiple people in UA should be maintainers on the repo. This would also be useful for assigning issues to specific people.
• Protected branches Nevermind, it seems all branches are protected. I like it.
• Private issues; I don't think we have a github enterprise account, but we should look into that for a way to have issues and discussions that don't require hopping over into MM that can be private and not revealed to the public. Especially for working on docs for systems still under NDA. A potential option would be to use Public GitLab (which allows for free public repos with private issues) instead of GitHub?
• Setup an MM integration to alert the MM channel to changes.
• Define a set of issue labels for binning common issues (maybe per system, NDA, infrastructure, deprecated information, etc...)
• Policy for timely PR approvals: who can and should approve changes and when? One of the issues we've had with the software CI deployments is that we require MR approvals but not everyone who can approve voluntarily reviews changes without prompting.

[grahamlopez]

Setup collaborators and team members on the repo; I think multiple people in UA should be maintainers on the repo. This would also be useful for assigning issues to specific people.

Anyone who is an admin of the OLCF organization is also and admin of this repo.

Nevermind, it seems all branches are protected. I like it.

Yes, this is to discourage mistake pushes into this upstream. HOWEVER, admins are still allowed to push 😡

Private issues; I don't think we have a github enterprise account, but we should look into that for a way to have issues and discussions that don't require hopping over into MM that can be private and not revealed to the public. Especially for working on docs for systems still under NDA. A potential option would be to use Public GitLab (which allows for free public repos with private issues) instead of GitHub?

The current POR is to have a separate on-prim gitlab repo for NDA docs and not worry about protecting things here.

Setup an MM integration to alert the MM channel to changes.

Sure.

Define a set of issue labels for binning common issues (maybe per system, NDA, infrastructure, deprecated information, etc...)

Jack and I talked about this some. Personally, I am a fan of fewer labels to be used for either 1) calling attention to important things or 2) grouping common things. I usually wait to create labels as the need is felt, but anyone is able to create them (I think), so I guess it is a free-for-all.

Policy for timely PR approvals: who can and should approve changes and when? One of the issues we've had with the software CI deployments is that we require MR approvals but not everyone who can approve voluntarily reviews changes without prompting.

Probably a "cross that bridge if/when we get there." ?

[grahamlopez]

@mpbelhorn: do you have any lingering concerns here?

[jack-morrison]

Setup an MM integration to alert the MM channel to changes.

I had looked into this and discussed with Ops shortly after this repo was created. It does not seem likely in the near-term that this will be possible due to how MM is run.

---

I believe all of the points raised in this issue have been addressed by @grahamlopez above. Closing this for now, but please feel free to reopen if you disagree.