Commit 49607f29 authored by mrodzis's avatar mrodzis 🌎
Browse files

docs(contributing.md): implement feedback, improve styling

parent e653f5ff
......@@ -28,22 +28,36 @@ Each branch should start with the dedicated issue number and a short description
All issues will be arranged in [milestones](https://gitlab.gwdg.de/groups/subugoe/ahiqar/-/milestones).
Milestones are always group-wide, so we combine tickets from all repositories associated with Ahiqar to a single milestone.
The milestone number is increased with each sprint.
The milestone number is increased with each sprint in accordance to [Semantic Versioning](https://semver.org/).
### Merge Requests (MR)
Merge requests should be peer reviewed before merging them into `develop`.
A well-tried workflow is:
1. A developer decides to work on a feature. She commits her changes to a separate feature branch. After some time she finishes the feature and wants it to be part of the development branch.
2. The developer creates a merge request and assigns everybody she sees fit to properly review her code to it.
3. To avoid diffusion of responsibility, she also assigns one of the chosen assignees as MUST. This means that this person has to approve the MR, otherwise the merge cannot be done. Although GitLab sends notifications to everybody who is newly assigned to a MR, she should notify the MUST assignee personally (in case he or she doesn't notice the mail sent by GitLab). The MR settings are:
1. A developer decides to work on a feature.
She uses the current development branch as a base for her work.
She commits her changes to a separate feature branch.
After some time she finishes the feature and wants it to be part of the development branch.
2. Before creating her merge request, the developer rebases her branch on the basis of `develop`.
This minimizes the change of merge conflicts.
You can either use `rebase` or `merge` for this.
3. The developer creates a merge request and assigns everybody she sees fit to properly review her code to it.
She uses one of the proposed merge templates in order to not forget anything and ease her reviewers' work.
4. To avoid diffusion of responsibility, she also assigns one of the chosen assignees as MUST.
This means that this person has to approve the MR, otherwise the merge cannot be done.
Although GitLab sends notifications to everybody who is newly assigned to a MR, she should notify the MUST assignee personally (in case he or she doesn't notice the mail sent by GitLab).
The MR settings are:
* The MR is associated with the current sprint's [milestone](https://gitlab.gwdg.de/groups/subugoe/ahiqar/-/milestones).
* The boxes for "Squash Commit" and "Deleting branch after Merge" are ticked
4. The MUST assignee reviews the changes according to style, variable naming, understandability, documentation provided, functionality, etc. If everything is to his or her liking, he or she approves the MR. The other assignees are free to review the code as well. **Note:** MRs without docs should not be accepted.
5. After the MR has been (dis)approved, the assignee removes his- or herself from the list of assignees. The MUST assignee informs the developer over the review being done.
6. The developer merges her changes into the development branch.
5. The MUST assignee reviews the changes according to style, variable naming, understandability, documentation provided, functionality, etc.
If everything is to his or her liking, he or she approves the MR.
The other assignees are free to review the code as well.
**Note:** MRs without docs should not be accepted.
6. After the MR has been (dis)approved, the assignee removes his- or herself from the list of assignees.
The MUST assignee informs the developer over the review being done.
7. The developer merges her changes into the development branch.
If a merge conflict occurs the person who has proposed the MR is responsible for solving all conflicts.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment