- Search tickets before you file a new one. Add to tickets if you have new information about the issue.
- Keep tickets short but sweet. Make sure you include all the context needed to solve the issue. Don't overdo it. Great tickets allow us to focus on solving problems instead of discussing them.
- Take care of your ticket. When you spend time to report a ticket with care we'll enjoy fixing it for you.
- Use labels to categorize your ticket or pull request. Do not use
[component]
or(other component)
to prefix ticket and pull request titles. - Use GitHub-flavored Markdown. Especially put code blocks and console outputs in backticks (
```
). That increases the readability. - Do not litter. Don’t add +1’s unless specifically asked for and don’t discuss offtopic issues.
In short, since you are most likely a developer, provide a ticket that you yourself would like to receive.
We depend on you (the community) to contribute in making the project better for everyone. So debug and reduce your own issues before creating a ticket and let us know of all the things you tried and their outcome. This applies double if you cannot share a reproduction with us because of internal company policies.
Please include steps to reproduce and all other relevant information, including any other relevant dependency and version information.
Please try to be precise about the proposed outcome of the feature and how it would related to existing features.
We love pull requests! However, before we can accept your pull request, you will need to sign and return one the following Contributor License Agreements (CLA) to [email protected]:
- Individual Contributor License Agreement (PDF|Word)
- Corporate Contributor License Agreement (PDF|Word)
All contributions will be licensed under the Apache 2.0 license.
Code/comments should adhere to the following rules:
- All changes require test coverage (where it's applicable) to ensure it does not break during refactor work, as well as ensure consistent behavior across supported platforms.
- Comments are required for public APIs. See Documentation Conventions below.
- When documenting APIs and/or source code, don't make assumptions or make implications about race, gender, religion, political orientation, or anything else that isn't relevant to the project.
- Remember that source code usually gets written once and read often: ensure the reader doesn't have to make guesses. Make sure that the purpose and inner logic are either obvious to a reasonably skilled professional, or add a comment that explains it.
- Pull requests will be squashed and merged. Please add a detailed description; it will be used in the commit message and paraphrased in release notes.
For coding and documentation conventions check out these sub-pages: