# Contributing

We use several pieces of technology in this repository to streamline the release process whilst maintaining high code
quality.

## Pre pull request checklist

Below is a brief checklist prior to submitting or updating a pull request

1. Running `yarn pre-pr` passes.
2. Commit messages conform to the below conventions.
3. The pull request description fills in the relevant fields provided by the template.

## Commit messages

A well formed commit message communicates context about a change. A diff will tell you what changed. A well cared for
commit log is a beautiful and useful thing.

What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.
From reviews to maintenance it's a powerful tool. Understanding why something happened months or years ago becomes not
only possible but efficient.

We rely on consistent commit messages as we use
[conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) which automatically generates
the changelog diff based on the commit messages

We enforce well formed commit messages with pre-commit hooks using [husky](https://github.com/typicode/husky).

The following guidelines are based on the angular team's
[contribution guide](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
Checkout [commitizen](https://www.npmjs.com/package/commitizen) and [commitlint.io](https://commitlint.io/) for
assistance.

```
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```

### Type

Must be one of the following:

- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- **test**: Adding missing tests or correcting existing tests

### Scope

The scope should be the name of the module/package/area affected (as perceived by the person reading the commit
message).

### Subject

The subject contains a succinct description of the change.

- use the imperative, present tense: "change" not "changed" nor "changes" (this convention matches up with commit
  messages generated by commands like git merge and git revert)
- don't capitalise the first letter
- no dot (.) at the end

### Body

The body contains more detailed explanatory text, if necessary.

- must have blank line between subject and body (unless you omit the body)
- wrap at 72 chars
- use the imperative, present tense: "change" not "changed" nor "changes" (this convention matches up with commit
  messages generated by commands like git merge and git revert)
- should include the motivation for the change and contrast this with previous behavior
- paragraphs come after blank lines
- use of markdown is encourage i.e. links, bullet points

### Footer

The footer contains references to issues the commit closes or addresses.
