Merge branch '74-code-quality' into 'main'

Resolve "Code Quality"

Closes #74

See merge request !77

chapters/code-quality.md

@@ -11,18 +11,26 @@ reviews within the team. Otherwise, ask your peers for support.
 In multi-developer projects, all relevant developers should be adressed to review a MR, with at least 2 approvals
 needed for the MR to pass review.
 
-#### Sample Workflow: Code Reviews in SADE
-
-1. A developer decides to work on a feature. They commit their changes to a separate feature branch. After some time they
-finish the feature and want to merge it into the development branch.
-2. They create a merge request and assign everybody they see fit to properly review their code.
-3. To avoid diffusion of responsibility, they also assign one of the chosen assignees as `MUST`. This means that this
-person has to approve the MR, otherwise the merge cannot commence. Although GitLab sends notifications to everybody
-newly assigned to a MR, the developer should notify the `MUST` assignee personally
-(in case they don't notice the notification by GitLab).
-4. The `MUST` assignee reviews the changes regarding style, variable naming, understandability, documentation
-provided, functionality, etc. If everything is to their liking, they approve the MR. The other assignees are
-free to review the code as well. **Note:** MRs without documentation should not be accepted.
-5. After the MR has been (dis)approved, assignees remove themselves from the list of assigned reviewers. The `MUST`
-assignee informs the developer about the review being finished.
-6. The developer merges their changes into the development branch.
+#### Sample Workflow: Code Reviews in Technical Reference
+
+1. An issue should be existing, briefly stating what is missing or should be changed.
+2. If a developer decides to work on this issue, the "Create merge request" button at the issue view can be used.
+This creates a branch with a meaningful name related to the issue, and a merge request (MR). The MR has draft status
+by default. (This step matches the GitLab Flow.)
+3. The branch can be checked out locally, changes can be commited there. After some time, the feature
+(e.g. a new chapter or text change) is finished and should be merged into the main branch.
+4. Now the draft status of the MR is removed and everybody who should review the text is requested to do so.
+GitLab-CE allows to assign one person for reviewing the MR. This means that this
+person has to approve the MR, otherwise the merge cannot commence. Other people relevant for the MR
+can be "mentioned" in a comment, so they are notified of this MR by email. The developer should notify the `MUST`
+assignee personally (in case they don't notice the notification by GitLab).
+5. The `MUST` assignee reviews the changes regarding style, understandability, grammar and spelling, etc.
+If everything is to their liking, they approve the MR. The people mentionened in the comments are free to review
+the changes as well.
+6. The developer merges their changes into the main branch.
+
+### Code quality measurement with Gitlab-CI
+
+GitLab-CE provides some tools which can be used
+[to measure code quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html).
+We want to test these tools in the near future.