# Contributing Guidelines ### Pull Request General Guidelines * Please check to make sure that there aren't existing pull requests attempting to address the issue mentioned. * Check for related issues on the issue tracker. * Non-trivial changes should be discussed on an issue first. * Develop in a topic branch, never on master: `git checkout -b topic-branch`. * Provide useful pull request description. * Make "atomic", well scoped pull requests. 1 PR per feature of bug fix. * Link the issue on the pull request description for cross references between code and issues. We only support support **squash merge** of the pull requests as a best practice for ensure the master log is maintained clean and relevant, without requiring the pull request to be rebased. This strategy requires that all pull request made are "atomic", in other words they solve one thing only. One pull request per feature, bug fix or documentation update. ### Commit Message Guidelines We have very precise rules over how our git commit messages can be formatted by following the [Conventional Commits Standard](https://www.conventionalcommits.org/en/v1.0.0/). This leads to **more readable messages** that are easy to follow when looking through the **project history**. But also, we use the git commit messages to **generate the project change log**. #### Commit Message Format Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: ``` ():