Skip to content

Latest commit

 

History

History
86 lines (64 loc) · 2.83 KB

CONTRIBUTING.md

File metadata and controls

86 lines (64 loc) · 2.83 KB
Raw

Contributing

Thank you for contributing to lattpy 🎉

Pre-commit Hooks

We are using the pre-commit framework to automatically run some checks and the Black code formatter at commit time. This ensures that every commit fulfills the basic requirements to be mergeable and follows the coding style of the project.

The pre-commit hooks can be installed via

$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

Commit Message Format

A format influenced by Angular commit message.

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Type

Must be one of the following:

  • feat: A new feature
  • fix: Bug fixes or improvements
  • perf: A code change that improves performance
  • refactor: Code refactoring
  • ci: Changes to CI configuration files and scripts
  • docs: Documention changes
  • build: Updating Makefile etc, no production code changes
  • test: Adding missing tests or correcting existing tests
  • update Other configurations updates
  • auto Mostly used by automatic commits (for example from GitHub workflows)

Subject

Use the summary field to provide a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Body (optional)

Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".

Explain the motivation for the change in the commit message body. This commit message should explain why you are making the change. You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.

Footer (optional)

The footer can contain information about breaking changes and deprecations and is also the place to reference GitHub issues, Jira tickets, and other PRs that this commit closes or is related to. For example:

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>

or

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>

Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.

Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.