First off, thank you for contributing! We're excited to collaborate with you! 🎉
The following is a set of guidelines for the many ways you can join our collective effort.
Before anything else, please take a moment to read our Code of Conduct. We expect all participants, from full-timers to occasional tinkerers, to uphold it.
Check out our Coding Style guide.
We take security bugs seriously. Please see our Security documentation for details.
Have a suggestion or feedback? Please go to Issues and open a new issue. Prefix the title with a category like "Bug:", "Question:", or "Feature Request:". Screenshots help us resolve issues and answer questions faster, so thanks for including some if you can.
Before you ask a question, it is best to search for existing Issues that might help you. In case you find a suitable issue, you can ask your question by adding a comment there.
Similarly, before reporting a bug, check if there is not already a bug report existing for your case.
If you're just getting started and want to familiarize yourself with the app’s code, we suggest looking at these issues with the good first issue label. But if you’d like to tackle something different, you're more than welcome to visit the Issues page and pick an item that interests you.
We always try to avoid duplicating efforts. If you decide to work on an issue, leave a comment to state your intent. If you choose to focus on a new feature, or the change you’re proposing is significant, we recommend waiting for a response before proceeding. The issue may no longer align with project goals.
If the change is trivial, feel free to send a pull request without notifying us.
All code contributions pass through pull requests. If you haven't created a pull request before, we recommend this free video series, How to Contribute to an Open Source Project on GitHub.
The core team monitors and reviews all pull requests. Depending on the changes, we will either approve them or close them with an explanation. We might also work with you to improve a pull request before approval.
Note: If you are part of the org, and have the necessary permissions for the repo, please add yourself to the PR as an assignee, and add the appropriate GitHub label(s) and Milestone.
- PRs require one reviewer to approve the PR before it can be merged to the base branch
- We keep the PR git history when merging (merge via "merge commit")
- The reviewer who approved the PR will merge it right after approval (without waiting for the PR author) if all checks are green.
Have look at the Coding Style guide to learn how to format your code so it passes the convention and quality checks like the rest of the project.