Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
54 lines (42 loc) · 2.41 KB

CONTRIBUTING.md

File metadata and controls

54 lines (42 loc) · 2.41 KB
Raw

Contributing to thadin

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

The following is a set of guidelines for contributing to thadin. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Commits

We're using conventional commits, so use following prefixes for your commits:

  • feat: A new feature
  • fix: A bug fix
  • chore: A change that is related to dependencies, imports, format changes - not worth any other prefix
  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts
  • docs: Documentation only changes
  • 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

Proposing a Change

If you intend to add a feature, or make any non-trivial changes to the implementation, we recommend filing an issue. This lets us reach an agreement on your proposal before you put significant effort into it.

If you’re only fixing a bug, it’s fine to submit a pull request right away but we still recommend to file an issue detailing what you’re fixing. This is helpful in case we don’t accept that specific fix but want to keep track of the issue.

Creating a Pull Request

Before creating a pull request please:

  1. Fork the repository and create your branch from main.
  2. Install all dependencies (make setup).
  3. Squash your commits and ensure you have a meaningful commit message.
  4. If you’ve fixed a bug or added code that should be tested, add tests! Pull Requests without 100% test coverage will not be approved.
  5. Ensure the test suite passes (make test)
  6. If you've changed the public API, make sure to update/add documentation.
  7. Format your code (make format).
  8. Analyze your code (make analyze).
  9. Create the Pull Request and fill the description.
  10. Verify that all status checks are passing.

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.