Fork & Branch

Fork the repository and create a feature branch from main — the current default branch. Never work directly on main; if you’re not already on a branch, create one first.

Keep Current With main

Rebase your branch on main to stay up to date. Always check whether you need a rebase just before opening a pull request or asking for re-review — main may have moved since you branched.

Opening the Pull Request

Open the PR from your fork with a clear description of the change and its motivation. Reference the tracking issue — see Issues for creating one, and Commit Requirements for the Refs: footer format.

What Must Be True Before Merge

• Tests updated or added to cover the change — see Test Conventions.
• A changes.xml entry is present — see Changelog.
• Commit messages meet the Conventional Commits requirements — see Commit Requirements.
• The CI workflow is green on the branch — see Continuous Integration for which workflow that is and what it actually covers.

Review

The easier you make it for a reviewer to apply and understand your change, the more likely it lands quickly. Respond to review feedback with fixup! commits (see Commit Requirements) rather than a force-pushed rewrite, until asked to squash.

There is no CODEOWNERS file or pull request template in this repository today — review is informal maintainer review, not an automated gate.

Questions During Review

For questions, assistance, or other help on an open PR, comment directly on it, or use GitHub Discussions for broader questions not tied to a specific PR.