Consider protecting master

[cmungall]

On: https://github.com/geneontology/geneontology.github.io/settings/branches

This would allow a wider circle to edit and a smaller trusted circle to approve

Potential downside? Would this make it harder to have auto-commits via pipeline? @lpalbou @kltm

[kltm]

@cmungall there is some whitelisting mechanism. If we decided to go this route, I'm sure we could have a workaround.
That said, how many rogue committers are we really expecting?

[cmungall]

I think it is good practice to protect master

…

[suzialeksander]

I think protecting master is the right step, @lpalbou @kltm thoughts? But in response to @kltm not too many rogues have touched the site so far, so this may not be of the highest importance.

[kltm]

Okay, I did the following:

• using "classic" branch protection rules
• require a PR
  • require at least one approval to merge
  • people in geneontology/admin can bypass this
• Require status checks to pass before merging
• Require branches to be up-to-date before merging

Any other thoughts for this one?

[kltm]

Tagging @pgaudet @suzialeksander

[pgaudet]

This works, thanks!