- GitHub as a public repository. Please create an account.
- Git for version control. Git How To and Git Cheat Sheet provide an introduction into working with Git.
This repository is following the Contributor Covenant Code of Conduct.
Please be self-reflective and always maintain a good culture of discussion and active participation.
Since the open license allows free use, no notification is required.
However, for the authors it is valuable information who uses the software for what purpose.
Indicators are Watch
, Fork
and Starred
of the repository.
If you are a user, please add your name and details in 📝USERS.cff
.
You can give ideas, hints or report bugs in issues, in PR, at meetings or other channels.
This is no development but can be considered a notable contribution.
If you wish, add your name and details to 📝CITATION.cff
.
You add code and become an author of the repository. You must follow the workflow!
You contribute and take care of the repository. You review and answer questions. You coordinate and carry out the release.
The workflow for contributing has been inspired by the workflow described by Vincent Driessen.
Create an GitHub Issue
in the repository. Choose a suitable Issue Template
for a Feature
or a Bug
and fill in as much information as possible.
Most important is the Issue Title
, it describes the problem you will address.
Update the GitHub Labels
and assign to a GitHub Project
and Milestone
.
- develop - Contains all current developments
- production - Contains the latest released version
- gh-pages - Contains the compiled documentation
- Load the
develop
branch: 💠git checkout develop
- Update with online version: 💠
git pull
- Create a new feature branch: 💠
git checkout -b feature-1314-my-feature
- Naming convention for branches:
type
-issue-nr
-short-description
feature
- includes the new feature that will be implementedenhance
- includes enhancements or improvementsbug
- includes minor fixes and improvementshotfix
- includes small improvements before a release, should be branched from a release branchrelease
- includes the current version to be released
The majority of the development will be done in feature
and enhance
branches.
The issueNumber
should be taken from Step 1. Do not use the "#".
Describe shortly what the branch is about. Avoid long and short descriptive names for branches, 2-4 words are optimal.
- Separate words with
-
(minus) - Avoid using capital letters
- Do not put your name to the branch name, it's a collaborative project
- Branch names should be precise and informative
Examples of branch names:
feature-42-add-new-ontology-class
enhance-911-branch-naming-convention
hotfix-404-update-api
release-v0.10.0
- Divide your work into small logical units
- Start to write the documentation or a docstring
- Write a unit test that covers the desired outputs and possible errors
- Don't rush, have the commit messages in mind
- Add your changes to the
📝CHANGELOG.md
- Add your name and details to
📝CITATION.cff
- Check branch status: 💠
git status
- Add a new file: 💠
git add filename.md
- Commit regularly with: 💠
git commit filename.md
- Add REUSE license information
- "If applied, this commit will ..."
- Follow existing conventions for commit messages
- Keep the subject line shorter than 50 characters
- Do not commit more than a few changes at the time: atomic commits
- Use imperative: Add, Update, Fix.
- Do not end the commit message with a period
. - Allways end the commit message with the
issueNumber
including the "#"
Examples of commit message: Add function with some method #42
or Update documentation for commit messages #1
- Do you want to improve your latest commit message?
- Is your latest commit not pushed yet?
- Edit the commit message of your latest commit: 💠
git commit --amend
- Push your
local
branch on the remote serverorigin
. - Check branch status: 💠
git status
- Update with online version: 💠
git pull
- If the branch is not on the remote server yet, use: 💠
git push --set-upstream origin feature-1314-test
- Then push with: 💠
git push
- Follow the GitHub guide creating-a-pull-request
- The PR should be directed:
base: develop
<-compare: feature-1-collaboration
- Use the Pull Request Template
- Check that all tests pass
- Assign a reviewer and get in contact
Follow the GitHub guide approving a pull request with required reviews.
Assign one reviewer or a user group and get into contact.
If you are the reviewer:
- Check the changes in all corresponding files
- Checkout the branch and run code
- Comment if you would like to change something using
Request changes
- If all tests pass and all changes are good,
Approve
the PR - Leave a comment and some nice words!
- Follow the GitHub guide merging a pull request.
- Merge the PR
- Follow the GitHub guide deleting a branch.
- Delete the branch (feature, bug, enhance)
- Document the result in a few sentences and close the issue.
- Issue title describes the problem you solved?
- All commit messages are linked in the issue?
- The branch was deleted?
- Entry in
📝CHANGELOG.md
? - PR is closed?
- Issue is closed?
- 🎉 Congratulations dear contributor, let's keep going 🚀
!!! note "Used Icons" 🐙 GitHub | 💠 git | 📝 File | 💻 Command Line