Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
113 lines (81 loc) · 3.67 KB

CONTRIBUTING.md

File metadata and controls

113 lines (81 loc) · 3.67 KB
Raw

Contributing guide

Table of contents

General

We welcome all contributions from the community. Adhere to Code of Conduct at all times.

Prerequisites

  1. Read ROADMAP to understand the project's goals.
  2. Read Developer's Certificate of Origin (DCO) in DCO.md (you must sign-off your PRs).
  3. Read LICENSE

Contributions

We welcome non-code contributions as well. If you have any suggestions, ideas, or want to report a bug, follow these steps:

  1. Verify open issues to see if someone reposrted similar issue or requested a similar feature.
  2. If the issue exists, upvote it and share more information in a comment (use cases, examples and so on).
  3. If the issue does not exist, create a new one from the Issues Templates tab.
  4. Follow the appropriate template for the issue

Committing changes

Please follow the simplified Conventional Commits standard in every commit, for example:

git commit -s -S -m "feat: add new feature"
  • You can only use fix, feat, fix!, feat! types, we do not accept any other types (e.g. chore, refactor, docs and others).
  • Your commits should be atomic and should not contain many changes.
  • Your commits have to be signed-off (use -s flag in git commit as in the example above). Please see the DCO for more information.
  • Your commits have to be signed (use -S flag in git commit as in the example above). Please see the Signing commits for more information.

Creating a pull request

Follow GitHub Flow; main branch should always be in the releasable state.

Small pull requests are encouraged. If, for some reason, you cannot make small a pull request, describe the reasons in the pull request description.

Pull requests have to be:

  • Contain type akin to the commits; Same rules apply (only fix, feat, fix!, feat! allowed)
  • Linked to the issue via Closes #XXX (where XXX is the issue number) in the description.
  • Target the main branch.
  • Contain descriptive header and (optionally) description.

Tip

Type of the pull request should be the largest of all commits (feat! > fix! > feat > fix)

Other features:

  • Pull requests will be automatically labeled based on the type of the commit (in some cases, you might want to manually add the label from the existing ones).
  • Stale pull requests (no changes for 7 days) will be automatically closed (can be reopened later).

Warning

Once you submit a PR, do not rebase it (easier to review the changes).

Merging pull requests

Maintainers will merge your pull request after it is approved. In general, if pre-commit checks pass, no major changes should be necessary.

Note

We use Squash and Merge strategy for merging pull requests, individual commits should not matter if they follow the guidelines.

If you need help with this part of the process, tag one of the maintainers in the PR.