Skip to content

Latest commit

 

History

History
84 lines (60 loc) · 3.22 KB

CONTRIBUTING.md

File metadata and controls

84 lines (60 loc) · 3.22 KB
Raw

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 which automatically generates the changelog diff based on the commit messages

We enforce well formed commit messages with pre-commit hooks using husky.

The following guidelines are based on the angular team's contribution guide. Checkout commitizen and 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 behaviour
  • 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.