Skip to content

Latest commit

 

History

History
65 lines (41 loc) · 2.39 KB

CONTRIBUTING.md

File metadata and controls

65 lines (41 loc) · 2.39 KB
Raw

Contributing to Chisel

Thanks for contributing to this project. Bellow, you can find a couple of things to keep in mind before contributing to Chisel.

  1. Issues
  2. Commits
  3. Branches
  4. Pull Requests

Issues

Every piece of work has to be related to an issue. The issue will have a capitalised title, which follows the same rules of commits messages.

Every issue should contain one label that reflects the issue category. If the issue is going to be close with no development, use one of these labels:

  • wontfix
  • can't replicate
  • chisel ignore
  • invalid
  • duplicate

When a task is completed, create a Pull Request which closes the issue.

Commits

  1. Start the subject line with a verb (e.g. Change header styles)
  2. Use the imperative mood in the subject line (e.g. Fix, not Fixed or Fixes header styles)
  3. Limit the subject line to about 50 characters
  4. Do not end the subject line with a period
  5. Separate subject from body with a blank line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Branches

For every piece of development, create a branch. The naming convention for the branch is lowercases-with-dashes. Branch off master rebase on top of master and create a PR back to master.

The branch will be deleted straight after the pull request.

Pull Requests

A PR has to close one issue. The less amount of work is in one PR, the easier is to review it.

Keeping the scope of each PR to one general feature or fix will allow you to use unstructured commit messages when committing each little change and then squash them into a single commit with a structured message (referencing the PR number) once they have been reviewed and accepted.

The body of the PR should start with a message that closes the related issues and the actual description in new lines.

The commit history in a PR should not contain Merge commits and should be rebased on top of master.

e.g.

Closes #123

Write any further information needed to the reviewer, e.g. run yarn before reviewing.

Checks

Every PR has to be reviewed before can be merged in.

Credits

These contributing guidelines are based on contributing guidelines of gren