diff --git a/web/content/docs/devguide/development-workflows/branching-model.pandoc b/web/content/docs/devguide/development-workflows/branching-model.pandoc
index ffb9d71ffb5feb5aa5efd53820aa042de2077472..ea82228e01648704e38c4c8108c690fdb576595a 100644
--- a/web/content/docs/devguide/development-workflows/branching-model.pandoc
+++ b/web/content/docs/devguide/development-workflows/branching-model.pandoc
@@ -34,4 +34,4 @@ First thing to do when you start working on your local repository is to create a
 
 Start committing changes in logical chunks. After you are happy with your implementation push your topic branch to your forked repository on GitLab.
 
-Open a *Pull Request* which will initiate the code review process.
+Open a [*Merge Request*](https://docs.gitlab.com/ee/user/project/merge_requests/) which will initiate the code review process.
diff --git a/web/content/docs/devguide/getting-started/get-the-source-code.pandoc b/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
index 0e0041ec8d8eb0e6669d16eb9d6ca8873a895916..130d233487bb03a28e97b332ea6c89af248a56c9 100644
--- a/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
+++ b/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
@@ -95,7 +95,7 @@ Now after you implemented the feature and committed your work you can push the n
 $ git push
 ```
 
-If your work is done submit a pull request.
+If your work is done submit a [merge request](https://gitlab.opengeosys.org/ogs/ogs/-/merge_requests/new).
 
 This workflow is summarized with this picture:
 
diff --git a/web/content/docs/devguide/testing/gitlab-ci.pandoc b/web/content/docs/devguide/testing/gitlab-ci.pandoc
index ac9f7338e502b0dc485a8b6d30a3fe9b03c3a78f..64626dfc91dd0d22f1c0aed356b6bcb5f6c8b2d5 100644
--- a/web/content/docs/devguide/testing/gitlab-ci.pandoc
+++ b/web/content/docs/devguide/testing/gitlab-ci.pandoc
@@ -13,7 +13,7 @@ weight = 1022
 
 [GitLab CI](https://docs.gitlab.com/ee/ci/) is a powerful [Continuous Integration](../../development-workflows/continuous-integration) system integrated into GitLab.
 
-The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/gitlab-ci/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/gitlab-ci/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a pull request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the pull request.
+The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/gitlab-ci/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/gitlab-ci/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a merge request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the merge request.
 
 ## GitLab Pipeline
 
@@ -27,7 +27,7 @@ Jobs are belong to a stage and each job will get a status (success, warnings, fa
 
 ## Automatic testing
 
-The master-branch of the the main repository as well as all pull requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
+The master-branch of the the main repository as well as all merge requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
 
 ### Skip automatic testing