Skip to main content

Contributing

To contribute to a repository, you must fork the repository and a Pull Request must be opened to merge changes from the fork repository to the upstream one. Pull requests need only the 👍 of one or more code owners to be merged; when the PR author is a code owner, that does not count.

How should I make a Pull Request?​

  • A Pull Request must contain a coherent set of modifications: i.e modifications that have a precise scope and that serve a unique purpose.
  • A Pull Request must be given a title that must comply with the Conventional Commits specification.
  • A Pull Request must be given at least one label that describes the nature of its modifications.
  • A Pull Request should be linked to one or more JIRA issues specifying the need for the modifications.
  • A Pull Request should be merged using the squash merging strategy after required checks are successful.

What if my PR contains multiple fixes or features?​

If the Pull Request contains multiple fixes or features, you should edit the commit message from the GitHub interface when merging the Pull Request.

Example:

feat: adds v4 UUID to crypto

This adds support for v4 UUIDs to the library.

fix(utils): unicode no longer throws exception
  BREAKING-CHANGE: encode method no longer throws.

feat(utils): update encode to support unicode

The above commit message will contain:

  1. an entry for the "adds v4 UUID to crypto" feature.
  2. an entry for the fix "unicode no longer throws exception", along with a note that it's a breaking change.
  3. an entry for the feature "update encode to support unicode".

⚠️ Important: The additional messages must be added to the bottom of the commit.

How should I write my commits?​

Before you create a Pull Request, please check whether your commits comply with the commit conventions used in this repository.

When you create a commit we ask you to follow the convention category(scope or module): message in your commit message while using one of the following categories:

  • feat: changes that introduce completely new code or new features.
  • fix: changes that fix a bug.
  • docs: changing existing or creating new documentation (i.e. README, docs for usage of a lib or CLI usage).
  • style: changes that do not affect the meaning of the code.
  • refactor: any code related change that is not a fix nor a feature.
  • perf: changes that improve performances.
  • test: changes regarding tests (adding new tests or changing existing ones).
  • build: changes that affect the build system or external dependencies.
  • ci: changes regarding the configuration of continuous integration (i.e. GitHub actions, CI system).
  • chore: changes to the repository that do not fit into any of the above categories.
  • revert: reverts a previous commit

We use commitlint to lint the commit's title. Please put extra care when you choose the type of your commit as the linter can't verify the nature of your commit for you.