CHANGELOG.md

+# [2.3.0](https://gitlab.gwdg.de/fe/technical-reference/compare/v2.2.1...v2.3.0) (2022-05-17)
+
+
+### Bug Fixes
+
+* **code-quality.md:** adapt MR review assignemt for a possible gitlab-ce workflow ([6ce2334](https://gitlab.gwdg.de/fe/technical-reference/commit/6ce2334fe9fa59b97d7963cc03143994a1a512fc)), closes [#74](https://gitlab.gwdg.de/fe/technical-reference/issues/74)
+* **code-quality.md:** sample workflow: step 5. belongs to 4 ([862766e](https://gitlab.gwdg.de/fe/technical-reference/commit/862766e5de7d98bbf6f8bf13f8eb78a1eed6167b))
+* **code-quality.md:** spelling mistake and rephrasing ([f272bc6](https://gitlab.gwdg.de/fe/technical-reference/commit/f272bc64b4629eb9f160e45905db612c24fba7f1)), closes [#142](https://gitlab.gwdg.de/fe/technical-reference/issues/142)
+
+
+### Features
+
+* **code-quality.md:** add note about code quality measurement with gitlab-ci ([158d6ac](https://gitlab.gwdg.de/fe/technical-reference/commit/158d6ac482e26d0a44ecbbe99977cd9d3b75e727)), closes [#74](https://gitlab.gwdg.de/fe/technical-reference/issues/74)
+
 ## [2.2.1](https://gitlab.gwdg.de/fe/technical-reference/compare/v2.2.0...v2.2.1) (2022-04-05)
 
 

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.