Skip to content

Latest commit

 

History

History
93 lines (63 loc) · 3.7 KB

CONTRIBUTING.md

File metadata and controls

93 lines (63 loc) · 3.7 KB
Raw

Code Contribution Guide Rust

The primary language of this repository is Rust more specifically the 2018 edition.

The following document outlines how to make a code contribution to this project.

Code Conventions

In general we follow the language style guidelines outlined here.

Code Formatting

To ensure contributions meet the intended style guide, rustfmt is used.

Code Analysis

Clippy is also used to catch common mistakes in contributions

Code Documentation

Any public fields, functions, and methods should be documented with Rustdoc.

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.