-
Notifications
You must be signed in to change notification settings - Fork 0
Contributing
The master branch contains the latest stable version.
When implementing a new ticket or creating a bug fix an issue branch should be created from master, named issue-[github-issue-id]. Use a pull request to merge your issue into master.
Issues should never be merged directly into the main branches!
A pull request must be tested and merged by another person, you can never merge your own issue.
Releases follow the Semantic Versioning spec.
Each milestone will result in a new release. A release should always contain stable code that has been reviewed and tested.
Each release must be accompanied by a set of release notes that provides a summary of all fixed issues from the milestone.
Here you can find all the Github documentation.
- Clear Issues (label, assignee, description & title)
-
issue-xpattern for branchnames -
issue-x: messagepattern for commit messages - Never merge into master on your local machine
- A pull request must be tested and merged by another person
- “Fixes”, “Fixed”, “Fix”, “Closes”, “Closed”, or “Close” in the description of pull request
- Correct labels (has-pull-request & others)
Every month we group tickets into important milestones.
Here you can find a list of all the milestones.
Issues should be small and clear tasks, the solution can already be provided by the reporter in the description. An Issue should have an assignee and labels.
Referring to issues can be done with #issuenumber.
Here you can find our label list.
When you made a pull request that references an issue, it's best to attach the has-pull-request label, to separate it from the other tickets in the milestone.
When the Issue is a discussion please attach the label discussion.
You can close Issues by adding closes #issuenumber, but you can also do that in the description of the pull-request, it is better there because it can be altered afterwards.
More importantly is the commit message structure, issue-...: message.