First of all, thanks for considering contributing to this project!! Your help is highly appreciated!!
So this document got quite long... here is the very short summary/checklist:
- don't commit on main - use pull requests only
- use this branch naming convention:
feature/#39_bring_the_unicorns_back - commits must adhere to the conventional commits spec.
- add copyright header to new file or add yourself as author in existing files.
- sign your commits with a developer certificate of origin (dco) - (
git commit -s -m "MESSAGE") or use vscode which is configured for the repo to do this automatically. - only once: add yourself as a contributor to NOTICE.md.
Use pull requests to contribute to this repository.
Pushes to the main branch are automatically rejected.
Keep your PRs focussed on a single purpose. For example, do not implement multiple features or fix multiple bugs in a single PR unless they are interconnected. Simply create separate PRs instead.
Branches should be named with this scheme:
group/short_description
The group denotes the purpose of the contribution:
- feature: A new feature
- fix: A bug fix
- ci: GitHub workflow only changes
- docs: Documentation only changes
The short description should describe the change/feature etc.
If you have a bigger change please create an issue here in github and use the number as short description,
e.g. feature/#39_bring_the_unicorns_back
We use Conventional Commits to automatically calculate the semantic version, create the changelog, and publish the release via Python-Semantic-Release tooling.
The following is a slightly adapted version (to doxysphinx) of the excellent Angular commit style.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message should not be longer than 100 characters!. This allows the message to be easier to read on GitHub as well as in various git tools.
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The scope could be anything specifying place of the commit change. For example parser,
writer, config, examples, cli etc...
You can use * when the change affects more than a single scope or just leave (<scope>) out completely.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit closes.
Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines.
The rest of the commit message is then used for this.
If the commit reverts a previous commit, it should begin with revert:, followed by the header of the
reverted commit.
In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
-
a very short new feature commit message:
feat: add button that brings the unicorns back -
a multiple changes (just add a newline and repeat the pattern) + breaking change commit message:
feat(config): config file support Now we established our own configuration file mechanism. The previous command line argument based mechanism forced the users to always create a script, use makefiles etc. With the new mechanism only a config file needs to be given. Config can be read from yml, toml and json files. As we're often dealing with python projects there is also special support for pyproject.toml. fixes #59 BREAKING CHANGE: cli arguments aren't supported anymore. docs(config): document config mechanism The new config mechanism is documentation in our sphinx documentation.
Include a copyright notice and license consistent with the style used by this project. If your contribution contains code under the copyright of a third party, document its origin, license, and copyright holders.
Typically for code this would be through a header. You can use this as a template: .copyright.tmpl
This project also tracks patch provenance and licensing using the Developer Certificate of Origin and Signed-off-by tags initially developed by the Linux kernel project.
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
With the sign-off in a commit message you certify that you authored the patch or otherwise have the right to submit it under an open source license. The procedure is simple: To certify above Developer's Certificate of Origin 1.1 for your contribution just append a line
Signed-off-by: Random J Developer <[email protected]>
to every commit message using your real name or your pseudonym and a valid email address.
If you have set your user.name and user.email git configs you can
automatically sign the commit by running the git-commit command with the
-s option. There may be multiple sign-offs if more than one developer
was involved in authoring the contribution.
Often employers or academic institution have ownership over code that is written in certain circumstances, so please do due diligence to ensure that you have the right to submit the code.
If you are a developer who is authorized to contribute to Ontology Central on behalf of your employer, then please use your corporate email address in the Signed-off-by tag, otherwise use a personal email address.
Each contributor is responsible for identifying themselves in the NOTICE.md file, the project's list of copyright holders and authors. Please add the respective information corresponding to the Signed-off-by tag as part of your first pull request.
If you are a developer who is authorized to contribute to Ontology Central on behalf of your employer, then add your company / organization to the list of copyright holders in the NOTICE.md file. As author of a corporate contribution you can also add your name and corporate email address as in the Signed-off-by tag.
If your contribution is covered by this project's DCO's clause "(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it", please add the appropriate copyright holder(s) to the NOTICE.md file as part of your contribution.