decide if we want to enable branch protection

[dhellmann]

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

[dhellmann]

@jasonamyers I looked over the definitions of branch protection. I think we should partially enable it. Here's my reasoning, I'm interested in what you think before I make any changes.

Require pull request reviews before merging

Mergify is configured to wait for a review, but this would block manual merges without a review. I'm not sure we're active enough to need this, and I worry that it would prevent fixing something. I think we can agree to be careful and leave this off?

Require status checks before merging

Same, Mergify gives us this.

Require conversation resolution before merging

Maybe in a more active repo? Wait and see.

Require signed commits

I could go either way on this. I can sign mine, but don't have that turned on right now.

Require linear history

I don't think we need this.

Require merge queue

I'll look into how this interacts with Mergify. If we can automate it, it makes sense to me.

Require deployments to succeed before merging

We don't have deployments, so leave this off.

Lock branch

Not on main, obviously.

Do not allow bypassing the above settings

We should allow.

Restrict who can push to matching branches

I think only the 2 of us can write to the repo anyway so I'm not sure this gives us much.

Allow force pushes

This feels safe to enable. Merging is still possible, and blocking force pushes prevents accidents.

Allow deletions

Same, we want to avoid a mistaken delete.

[jasonamyers]

I like it. Let’s do it

[dhellmann]

Done