Please review the Code of Conduct. It is in effect at all times. We expect it to be honored by everyone.
See the Support Guide. In short, GitHub issues are not the appropriate place to debug your specific project or for general questions, instead it should be reserved for filing bugs and feature requests.
Review the Security Policy. Do not open a public issue for security vulnerabilities.
Before creating an issue, check if you are using the latest version of the project. If you are not up-to-date, see if updating fixes your issue first.
When opening an issue make sure you use the correct template. Fill in as much information as possible. Use a clear, short and descriptive title.
If creating a bug report, include as many details as possible: version, environment, etc. Also include steps to reproduce the bug if you can.
Before forking and creating a pull request for non-trivial changes you should open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments of an existing issue, depending on if one exists already or not.
When opening a pull request make sure you use the correct template. Fill in as much information as possible. Use a clear, short and descriptive title that resembles the issue title it refers to.
All contributions will be licensed under the project's license.
Please write a great commit message.
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative in the subject line ("Fix networking issue")
- Limit the subject line to 50 characters
- Separate subject from body with a blank line
- Wrap the body at about 72 characters
- Use the body to explain why, not what and how (the code shows that!)
- Review the code, not the author. Look for and suggest improvements without disparaging or insulting the author. Provide actionable feedback and explain your reasoning.
- You are not your code. When your code is critiqued, questioned, or constructively criticized, remember that you are not your code. Do not take code review personally.
- Kindly note any violations to the guidelines specified in this document.
Consistency is the most important. Following the existing style, formatting, and naming conventions of the file you are modifying and of the overall project. Failure to do so will result in a prolonged review process that has to focus on updating the superficial aspects of your code, rather than improving its functionality and performance.
For example, if all private properties are prefixed with an underscore _
, then new ones added should be prefixed in the same way. Or, if methods are named using camelcase, like thisIsMyNewMethod
, then do not diverge from that by writing this_is_my_new_method
. You get the idea. If in doubt, please ask or search the codebase for something similar.
When possible, style and format will be enforced with a linter.
By making a contribution to this project, I certify that:
- The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
- The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
- The contribution was provided directly to me by some other person who certified (1), (2) or (3) and I have not modified it.
- I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.