Caution
You can visit the Issues section to propose changes or features. Please ensure that your suggestion hasn't already been made and is not in the works.
Help prioritize issues by adding a ":thumbsup:" reaction to new features you'd like to see in this project or problems that affect you.
Assist the project by helping other users, enhancing the documentation, or validating security measures.
If you have technical or coding experience, you can assist by:
-
Engaging in development discussions,
-
Addressing issues by submitting code changes,
-
Reviewing pull requests,
-
Verify submitted bugs and provide additional details.
If you need assistance with submitting your code contributions, the GitHub Discussions is a good place to begin. You can also contact the project developers and the community through our GitHub Discussions forum.
-
Collaborate: Engage with others constructively, and be open to feedback and suggestions.
-
Stay On Topic: Ensure your contributions are relevant to the subject matter.
-
Respect Others: Always maintain a respectful tone when engaging with other contributors.
-
Provide Sources: Provide reliable sources for reference when stating facts or claims.
-
Be Clear and Concise: Express your ideas in a concise and clear manner, using simple language when possible.
-
No Spamming or Self-Promotion: Avoid posting irrelevant content or promoting personal products or services.
These guidelines help maintain a productive and respectful environment for everyone involved.
We welcome contributions from anyone interested in making them. These guidelines outline our policies for accepting contributions.
-
Always fork the repository to your own GitHub profile and do your work in branches within that fork. Do not push branches directly to the main project repository, even if you have access to do so. However, it is perfectly acceptable to create branches that are related to releases.
-
To contribute your work, please open a Pull Request, even if you have access to push to the main. Pull Requests become more necessary since your work is solely done on your fork. Please use the provided template for your Pull Request and fill in all the necessary details.
-
Please do not merge your own Pull Request. Allow it to be merged by the reviewer once the review process is complete, or the review has been approved. If you push new changes after the review is approved, it must be reviewed again! Project leads may merge their pull requests, but are highly encouraged to seek review from the community members, first.
-
If feedback is offered, please take it seriously. We won't generally reject a pull request based on spec, and we will often offer feedback on why we don't think it's a good fit or what needs to be changed. Your pull request will be more likely to be accepted if you honor our feedback.
-
Issues should only be closed by the team lead after they have been tested by a quality assurance lead, if one is available, or by another developer. Please do not close issues before they are tested.
-
Please keep in mind the following important points:
- This is an open-source project run by volunteers.
- You are welcome to fork the project or work with it under the terms of the license
Feel free to use the code, fork the project, or make any modifications you like, especially if we are unable to incorporate your recommendations. However, we kindly ask you to respect our license agreement.
Important
All code that you contribute is subject to the repository's license. By submitting your code, you agree to release it under that license.
We only accept contributions through Pull Requests on GitHub to the relevant repository/branch.
-
Please document any behavioral changes in the pull request so we can easily update the changelog.md when releasing a new version.
-
Please keep your commit message's first line within 80 characters. Use subsequent lines for additional information.
-
Pull requests should consist of 10 or fewer files and about 500 lines of code. If your submission exceeds these limits, you will need to provide an explanation, and we may ask you to divide the request into logical components.
-
We encourage you (though it is not required) to write tests for your contributions. We understand that unit testing can be challenging. If you have written tests for your code, we strongly encourage you to run those tests before submitting a pull request.
-
If your changes break backward compatibility with the current stable version, they must be included in the next major version release. Please submit your Pull Request targeting the branch for the upcoming major version. If a branch for that version has not yet been created, please request that one be set up for you. Additionally, any breaking changes should include a migration guide to assist users in transitioning from the old version(s) to the new version. We cannot accept changes that break backward compatibility in the current version, as this would violate Semantic Versioning principles.
-
All code contributed to the project is subject to the project's license. By committing and merging your code with ours, you agree to license your code to us under the project's license. For more details, please see the Contributor License Agreement.
The terms of this contribution agreement may change at any time and will be published on GitHub for public access. Changes take effect immediately for new contributions and will also apply to existing contributions. If you wish to opt out of the new terms, please contact any member of the leadership team.
You can view our list of Contributors.