Clarify project status and define contribution workflow

[anderslindho]

This PR clarifies the current state of the project with a temporary notice. It also reverts a commit made directly to the default branch and adds contribution guidelines requiring reviewed pull requests with passing CI.

I further suggest enabling GitHub branch protection for the default branch to prevent direct pushes and enforce this workflow.

Fixes #5
Fixes #6

[ralphlange]

LGTM

[ralphlange]

+1 on adding protection - should I go forward with that?

[anderslindho]

+1 on adding protection - should I go forward with that?

If it were only up to me, yes. Since this changes the workflow for everyone with push access, though, I would prefer to give the other reviewers a chance to weigh in. If there are no objections within the next few days, please go ahead.

[ralphlange]

I certainly wasn't going to get myself into trouble...

[tynanford]

also agree on adding branch protection

[shroffk]

basic branch protection added

[anderslindho]

Since I don't have admin here I can't see the settings themselves, so just to close the loop on what CONTRIBUTING.md now promises ("reviewed and all required CI checks must pass"): does "basic" include required status checks, or only a required approving review? Worth making sure the CI jobs are actually listed as required.

Also noticed there are two branch rulesets on the repo, main and master, both currently enforcement: disabled. They don't do anything today, but they'll be confusing next to the classic protection - probably worth either enabling one and retiring the classic rules, or deleting them.

@ralphlange @tynanford @shroffk

[ralphlange]

Also noticed there are two branch rulesets on the repo, main and master, both currently enforcement: disabled. They don't do anything today, but they'll be confusing next to the classic protection - probably worth either enabling one and retiring the classic rules, or deleting them.

These two might be the default now. (As most existing repos have either 'main' or 'master' as default branch.) I did not change any setting.

[anderslindho]

These do not appear to be GitHub defaults. Both are repository-level rulesets created on June 12, both target the default branch despite their names, and both are disabled. Neither includes required status checks.

The protection @shroffk added may be a separate classic branch-protection rule, which I cannot inspect without admin access. Could someone with access confirm whether it requires an approving review and passing CI checks? That is the part needed to match the workflow documented in this PR.

[ralphlange]

There is one branch-protection rule, which requires PRs before merging and minimum 1 approval, but also allows force-pushing for everyone with write/push access.

[anderslindho]

Thanks for checking @ralphlange. Requiring a PR and one approval sounds good.

I think we should also disable force pushes to the default branch and require the CI checks that run on pull requests to pass before merging. Otherwise the protection does not fully enforce the workflow described in CONTRIBUTING.md.

[tynanford]

I think we should also disable force pushes to the default branch and require the CI checks that run on pull requests to pass before merging. Otherwise the protection does not fully enforce the workflow described in CONTRIBUTING.md.

Sounds good to me. Makes me feel better when I force push in my reccaster fork even after checking 5 times with git remote that I'm not in the community repo.

[shroffk]

It has been disabled

[anderslindho]

Thanks @shroffk - were required status checks also enabled?