By submitting code as an individual you agree that anyone may use your ammendments, fixes, patches, changes, modifications, submissions and creations in the production of this project and that the ownership of your submissions transfers to the project in its' entirety.
When submitting an issue, there's a few guidelines we'd ask you to respect to make it easier to manage (and for others to understand):
- Search the issue tracker before you submit your issue - it may already be present.
- When opening an issue, a template is provided for you. Please provide as much information as requested to ensure others are able to act upon the requests or bug report.
- Please ensure you add screenshots or documentation references for bugs/changes so we can quickly ascertain if the request is suitable.
In order to be 'assigned' an issue, please comment on the issue itself - we can then assign your GitHub account to that particular issue.
If you wish to add a new feature or you spot a bug that you wish to fix, please open an issue for it first
The work-flow for submitting a new pull request is designed to be simple, but also to ensure consistency from all contributors:
- Fork the project into your personal space on GitHub.com.
- Create a new branch (with the name issue-issue_number, replacing issue_number with the issue number you're resolving).
- Commit your changes.
- When writing commit messages, consider closing your issues via the commit message (by including "fix #22" or "fixes #22", for example ).
- The issues will be referenced in the first instance and then closed once the MR is accepted.
- Push the commit(s) to your fork.
- Submit a pull request (PR) to the master branch.
- The PR title should describe the change that has been made.
- The PR description should confirm what changes have been made and how you know they're correct (with references).
- Please include any relevant screenshots to prove the changes work
- Ensure you link any relevant issues in the merge request (you can type hash and the issue ID, eg #275). Comment on those issues linking back to the PR (you can reference PRs in the same way as issues, using the format #pr-id).
- Be prepared to answer any questions about your PR when it is reviewed for acceptance.
Please keep your changes in a single PR as small as possible (relating to one issue) as this makes it easier to review and accept. Large PRs with a small error will prevent the entire PR from being accepted (and could potentially miss the airac/sector release date).
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting merge requests or patches, and other activities.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, issues and other contributions that are not aligned to this Code of Conduct.
This Code of Conduct applies both within this project space and public spaces when an individual is representing the project or its community.