-
Notifications
You must be signed in to change notification settings - Fork 117
Contributing
Andrea Davanzo edited this page Aug 22, 2025
·
26 revisions
*The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119
Thank you for your interest in contributing! We welcome contributions of all types: features, bug fixes, performance improvements, and documentation updates.
Before opening a new issue:
- Search existing issues to avoid duplicates
- Provide clear steps to reproduce (for bugs)
- Be descriptive and specific
If you are not a maintainer and you would like to contribute to the project, please follow these steps:
-
Find or create an issue
- Comment on the GitHub issue you’d like to work on.
- If no issue exists, create one and describe what you plan to do.
- This avoids duplicate work and helps maintainers track contributions.
-
Fork the repository (if you have not already).
- If you already have a fork, sync/rebase it so that it is up to date with the latest
mainbranch of this project.
- If you already have a fork, sync/rebase it so that it is up to date with the latest
-
Create a new branch in your fork.
- This keeps your changes isolated and allows you to keep pulling updates from
main. - Branches SHOULD be short-lived and focused on a single feature or fix.
- Write clean, testable code.
- Add or update unit/integration tests if relevant.
- Before opening your PR, you MUST merge/rebase changes from upstream
maininto your branch as needed.
- This keeps your changes isolated and allows you to keep pulling updates from
-
Open a Pull Request (PR) from your branch to upstream
main.In your PR description, include:
- Related issue numbers (e.g., “Related to #42”)
- You MUST NOT use auto-closing keywords (e.g., “Fixes #42”), since releases are coordinated separately.
- A summary of your changes
- Any caveats, limitations, or follow-ups
- If the change is urgent, explain why
- Maintainers ** will retarget your PR to a different branch, e.g.
next-release/xyz**, for staging and CI.
-
Wait for review.
- The project team will review your PR and may request adjustments to ensure it meets project guidelines.
- Home
- About
- Contributing
- Releases
- Themes
- Google Analytics
- Translations
- Developer guide
- Reporting Issues

