Document what is required before merging a pull request

[psss]

Clearly document what is required and what is recommended before merging a pull request. Also include the github rulesets exports so that the configuration can be easily shared/updated across all teemtee repositories using import a new ruleset. For the required checks the pick-the-required-checks placeholder is needed to actually export the settings. To be adjusted individually for each repository.

Pull Request Checklist

• write the documentation

[gemini-code-assist]

Code Review

This pull request adds GitHub branch protection rulesets (enforced.json and override.json) to enforce merge requirements like linear history, squash merging, and resolved conversations, while allowing release leads to override them. It also updates docs/contribute.rst to document these policies. Feedback recommends removing repository-specific metadata (such as id, source, and source_type) from the JSON configurations to make them generic and reusable.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[psss]

Docs check is expected to fail as the new links are pointing to files in the future main branch.

[LecrisUT]

Docs check is expected to fail as the new links are pointing to files in the future main branch.

Did we not add something to construct links to local files more consistently? If not can make an issue for it, I should at least have the snippet from some other projects.

[LecrisUT]

Other than the footgun of replacing required_status_checks with something empty, LGTM

[LecrisUT]

We should just add the full set here. It would make bumping it more automatic. Each repo would have a different set, but maybe we can merge it with another source, maybe even something fmf-y?

My concern here is that when we use an import, it would override it with the bogus value here.

[psss]

We should just add the full set here. It would make bumping it more automatic.

I'm not sure I understand: There is no plan/need to re-import these. Once the settings are synced across the repositories (already now) this is just for reference and possible future repositories.

Each repo would have a different set, but maybe we can merge it with another source, maybe even something fmf-y?

Yes, each repo has a completely different set of checks. I don't think it's worth automating in any way as we will use the import... let's say once per year when a need for a new repo pops up?

My concern here is that when we use an import, it would override it with the bogus value here.

It's not possible to override existing rule sets:

Name must be unique

So it's always needed to drop the rule set if it already exists.

[LecrisUT]

We should just add the full set here. It would make bumping it more automatic.

I'm not sure I understand: There is no plan/need to re-import these. Once the settings are synced across the repositories (already now) this is just for reference and possible future repositories.

What if a new security feature is introduced or we want to make any other changes.

Also having the test names can be useful every 6 months when we need to bump the fedora-stable names and drop the older ones.