Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • textplus/text-software-development-guidelines
  • fe/technical-reference
2 results
Show changes
Commits on Source (9)
Hide whitespace changes
Inline Side-by-side
CHANGELOG.md
View file @ 2e4d841d
# [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) ## [2.2.1](https://gitlab.gwdg.de/fe/technical-reference/compare/v2.2.0...v2.2.1) (2022-04-05)
......
chapters/code-quality.md
View file @ 2e4d841d
...@@ -11,18 +11,26 @@ reviews within the team. Otherwise, ask your peers for support. ...@@ -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 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. needed for the MR to pass review.
#### Sample Workflow: Code Reviews in SADE #### Sample Workflow: Code Reviews in Technical Reference
1. A developer decides to work on a feature. They commit their changes to a separate feature branch. After some time they 1. An issue should be existing, briefly stating what is missing or should be changed.
finish the feature and want to merge it into the development branch. 2. If a developer decides to work on this issue, the "Create merge request" button at the issue view can be used.
2. They create a merge request and assign everybody they see fit to properly review their code. This creates a branch with a meaningful name related to the issue, and a merge request (MR). The MR has draft status
3. To avoid diffusion of responsibility, they also assign one of the chosen assignees as `MUST`. This means that this by default. (This step matches the GitLab Flow.)
person has to approve the MR, otherwise the merge cannot commence. Although GitLab sends notifications to everybody 3. The branch can be checked out locally, changes can be commited there. After some time, the feature
newly assigned to a MR, the developer should notify the `MUST` assignee personally (e.g. a new chapter or text change) is finished and should be merged into the main branch.
(in case they don't notice the notification by GitLab). 4. Now the draft status of the MR is removed and everybody who should review the text is requested to do so.
4. The `MUST` assignee reviews the changes regarding style, variable naming, understandability, documentation GitLab-CE allows to assign one person for reviewing the MR. This means that this
provided, functionality, etc. If everything is to their liking, they approve the MR. The other assignees are person has to approve the MR, otherwise the merge cannot commence. Other people relevant for the MR
free to review the code as well. **Note:** MRs without documentation should not be accepted. can be "mentioned" in a comment, so they are notified of this MR by email. The developer should notify the `MUST`
5. After the MR has been (dis)approved, assignees remove themselves from the list of assigned reviewers. The `MUST` assignee personally (in case they don't notice the notification by GitLab).
assignee informs the developer about the review being finished. 5. The `MUST` assignee reviews the changes regarding style, understandability, grammar and spelling, etc.
6. The developer merges their changes into the development branch. 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.