First of all, thanks for your participation.
The following guideline will help you with creating good issues or pull requests as well as proposing improvements to existing functionality. These rules are by no means comprehensive so please feel free to create a pull request if you see room for improvement.
While the following guidelines are not strictly enforced, if everyone were to adhere to them, I feel it would create a much more productive environment for all.
A development model consisting of continuous atomic improvements is preferred over large changes which are difficult to review and may lead to bugs in the code base.
The committer is responsible for making sure that commit won't break the build. Please test before committing in order to verify that code compiles without any errors or warnings.
Browse Issues Section in order to make sure the issue you wish to submit is not already present.
A commit message often consists of two main components: a subject and a body.
Subject: A concise but descriptive title identifying the commit.
Body: Summary of commit being proposed. Clear explanation of why the change is being made and what the impact is.
- Capitalize each sentence
- Limit subject line to 50 characters
- Subject line sould not end with punctuation
- Add an empty line before the body seperating it from the subject line
- Use imperative present tense
- Limit body to 72 characters
- Do not commit incomplete work
- Divide changes in appropriate small chunks
- Each feature should have its own commit
- Do not commit dependencies or local configuration files
- Do not directly commit to the main branch, utilize branches
While one-line messages are fine for small changes, bigger changes are expected in the following form:
$ git commit -m "A short description of the commit
>
> A paragraph explaining the change along with its impact"
Additionaly, please refer to the Code of Conduct