Project License: Apache License, Version 2.0 (Apache-2.0.txt or www.apache.org/licenses/LICENSE-2.0)
-
You will only submit contributions where you have authored 100% of the content.
-
You will only submit contributions to which you have the necessary rights. This means that if you are employed you have received the necessary permissions from your employer to make the contributions.
-
Whatever content you contribute will be provided under both project licenses.
All contributors are expected to follow our Code of Conduct.
We are using the GitHub Flow, where development happens in branches, which are merged via pull requests. Special cases, like fixing problems with the CI pipeline, are of course exempt from this guideline.
Branch names should adhere to the following pattern: users/username/token/branch-name-by-hyphen
.
We use the following tokens:
-
feat: A feature
-
fix: A bug fix branch
-
chore: A cleanup branch
Examples:
users/gclark/feat/improve-documentation users/chowe/fix/issue-13 users/gclark/chore/update-dependencies
As a general rule, the style and formatting of commit messages should follow the Conventional Commits guidelines.
We use the following types:
-
feat: A new feature
-
fix: A bug fix
-
chore: Changes that affect the build system or external dependencies, CI configuration files and scripts
-
docs: Documentation only changes
-
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 semicolons, etc.)
-
test: Adding missing tests or correcting existing tests
-
revert: Reverts a previous commit
Because of the noise it generates on the issue, please do not mention the issue number in the message.
Try to fit the summary within the soft 50-character limit.
Examples:
fix: ensure UTF-8 docs: add license style: format
ℹ️
|
There is no requirement for all commits to match the branch token, i.e. a |
❗
|
Add |
Pull requests are used to discuss a concrete solution, not the motivation nor requirements for it.
As such there should be at least one issue a pull request relates to.
At the same time it should be focused, so it should usually not relate to more than one issue (although that can occasionally happen).
Please mention all issues in the request’s body, possibly using closing keywords like closes
, fixes
(for bugs only), or resolves
.
To enforce the Branching Strategy pull requests from main
will be closed.