diff --git a/doc.zih.tu-dresden.de/docs/contrib/content_rules.md b/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
index aa1eab9308b4bf0535040d02eb8345ef32af0981..ae60c07486095a5c24f0d067371bc01fe29fd6d8 100644
--- a/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
+++ b/doc.zih.tu-dresden.de/docs/contrib/content_rules.md
@@ -1,375 +1,8 @@
-# Contribution Guide
-
-## Contribute via Issue
-
-Users can contribute to the documentation via the
-[issue tracking system](https://gitlab.hrz.tu-chemnitz.de/zih/hpc-compendium/hpc-compendium/-/issues).
-For that, open an issue to report typos and missing documentation or request for more precise
-wording etc.  ZIH staff will get in touch with you to resolve the issue and improve the
-documentation.
-
-**Reminder:** Non-documentation issues and requests need to be send as ticket to
-[hpcsupport@zih.tu-dresden.de](mailto:hpcsupport@zih.tu-dresden.de).
-
-## Preparation
-
-Contributions can be done via editing the repository through GitLab's web interface or following
-the git-based workflow. Both ways are described in the following.
-
-### Fork and Clone Repository
-
-All contributing starts with forking the repository to either
-[gitlab.hrz.tu-chemnitz.de](https://gitlab.hrz.tu-chemnitz.de) or any other
-git service, e.g., (https://www.gitlab.com), (https://www.github.com) or
-your personal preference.
-Now, create a local clone of your fork
-
-```Bash
-# SSH based method
-~ git@gitlab.hrz.tu-chemnitz.de:LOGIN/hpc-compendium.git
-
-# HTTP based method
-~ https://gitlab.hrz.tu-chemnitz.de/LOGIN/hpc-compendium.git
-```
-
-## Contribute via Web IDE
-
-GitLab offers a rich and versatile web interface to work with repositories. To fix typos and edit
-source files, just select the file of interest and click the `Edit` button. A text and commit
-editor are invoked: Do your changes, add a meaningful commit message and commit the changes.
-
-The more sophisticated integrated Web IDE is reached from the top level menu of the repository or
-by selecting any source file.
-
-Other git services might have an equivalent web interface to interact with the repository. Please
-refer to the corresponding documentation for further information.
-
-<!--This option of contributing is only available for users of-->
-<!--[gitlab.hrz.tu-chemnitz.de](https://gitlab.hrz.tu-chemnitz.de). Furthermore, -->
-
-## Contribute via Local Clone
-
-### mkdocs Rocks
-
-As mentioned, this documentation bases on markdown files which are translated into static html files
-using the tool [mkdocs](https://www.mkdocs.org/). All markdown source files are located in the
-`docs` sub-directory. The file `mkdocs.yml` is the single configuration file for the project from layout
-up to document structure and extensions.
-The navigation section `nav` in `mkdocs.yml` specifies the order, titles and nesting of the
-documentation pages.
-
-In principle, `mkdocs` is not mandatory on the local system to contribute to the project. But it
-also provides a builtin development server that allows to serve the documentation, i.e. it can
-preview the updated documentation locally before committing the changes to the repository.
-
-To make use of `mkdocs`, it is necessary to have two commands in mind
-
-```Bash
-~ mkdocs serve - Start the live-reloading docs server.
-~ mkdocs build - Build the documentation site.
-```
-
-#### Preview Using mkdocs
-
-Invoke`mkdocs serve`to build and preview the documentation. The documentation is automatically
-re-rendered and reloaded if the system detects updates (great!). By default, the builtin web server
-hosts the documentation at `http://127.0.0.1:8000`.
-
-```Bash
-~ cd /PATH/TO/hpc-compendium/doc.zih.tu-dresden.de
-~ mkdocs serve
-INFO    -  Building documentation...
-INFO    -  Cleaning site directory
-INFO    -  Documentation built in 0.08 seconds
-[I 210127 13:33:30 server:335] Serving on http://127.0.0.1:8000
-INFO    -  Serving on http://127.0.0.1:8000
-[I 210127 13:33:30 handlers:62] Start watching changes
-INFO    -  Start watching changes
-```
-
-Open `http://127.0.0.1:8000` with a web browser to preview the local copy of the documentation.
-
-#### Preview Using mkdocs With Dockerfile
-
-You can also use `docker` to build a container from the `Dockerfile`, if you are familiar with it.
-This may take a while, as mkdocs and other necessary software needs to be downloaded.
-Building a container with the documentation inside could be done with the following steps:
-
-```Bash
-cd /PATH/TO/hpc-compendium
-docker build -t hpc-compendium .
-```
-
-If you want to see how it looks in your browser, you can use shell commands to serve
-the documentation:
-
-```Bash
-docker run --name=hpc-compendium -p 8000:8000 --rm -it -w /docs --mount src="$(pwd)"/doc.zih.tu-dresden.de,target=/docs,type=bind hpc-compendium bash -c "mkdocs build --verbose && mkdocs serve -a 0.0.0.0:8000"
-```
-
-You can view the documentation via [http://localhost:8000](http://localhost:8000) in your browser, now.
-
-If that does not work, check if you can get the URL for your browser's address
-bar from a different terminal window:
-
-```Bash
-echo http://$(docker inspect -f "{{.NetworkSettings.IPAddress}}" $(docker ps -qf "name=hpc-compendium")):8000
-```
-
-The running container automatically takes care of file changes and rebuilds the
-documentation.  If you want to check whether the markdown files are formatted
-properly, use the following command:
-
-```Bash
-docker run --name=hpc-compendium --rm -it -w /docs --mount src="$(pwd)"/doc.zih.tu-dresden.de,target=/docs,type=bind hpc-compendium markdownlint docs
-```
-
-To check whether there are links that point to a wrong target, use
-(this may take a while and gives a lot of output because it runs over all files):
-
-```Bash
-docker run --name=hpc-compendium --rm -it -w /docs --mount src="$(pwd)"/doc.zih.tu-dresden.de,target=/docs,type=bind hpc-compendium bash -c "find docs -type f -name '*.md' | xargs -L1 markdown-link-check"
-```
-
-To check a single file, e. g. `doc.zih.tu-dresden.de/docs/software/big_data_frameworks.md`, use:
-
-```Bash
-docker run --name=hpc-compendium --rm -it -w /docs --mount src="$(pwd)"/doc.zih.tu-dresden.de,target=/docs,type=bind hpc-compendium markdown-link-check docs/software/big_data_frameworks.md
-```
-
-For spell-checking a single file, use:
-
-```Bash
-docker run --name=hpc-compendium --rm -it -w /docs/doc.zih.tu-dresden.de --mount src="$(pwd)",target=/docs,type=bind hpc-compendium ./util/check-spelling.sh <file>
-```
-
-For spell-checking all files, use:
-
-```Bash
-docker run --name=hpc-compendium --rm -it -w /docs/doc.zih.tu-dresden.de --mount src="$(pwd)",target=/docs,type=bind hpc-compendium ./util/check-spelling.sh
-```
-
-This outputs all words of all files that are unknown to the spell checker.
-To let the spell checker "know" a word, append it to
-`doc.zih.tu-dresden.de/wordlist.aspell`.
-
-#### Build Static Documentation
-
-To build the documentation, invoke `mkdocs build`. This will create a new directory named `public`
-which holds the generated static html/jss/css files. This command is used to build the documentation
-within the CI/CD pipeline. Thus, it should exit without error.
-
-```Shell Session
-~ cd /PATH/TO/hpc-compendium/doc.zih.tu-dresden.de
-~ mkdocs build
-INFO    -  Cleaning site directory
-INFO    -  Building documentation to directory: /PATH/to/hpc-compendium.git/doc.zih.tu-dresden.de/public
-INFO    -  Documentation built in 0.09 seconds
-```
-
-### Git Workflow
-
-It is crucial to keep your branch synchronized with the upstream repository when you are working
-locally on the documentation. At first, you should add a remote pointing to the official
-documentation.
-
-```Shell Session
-~ git remote add upstream-zih git@gitlab.hrz.tu-chemnitz.de:zih/hpc-compendium/hpc-compendium.git
-```
-
-Now, you have two remotes, namely *origin* and *upstream-zih*. The remote *origin* points to your fork,
-whereas *upstream-zih* points to the original documentation repository at GitLab Chemnitz.
-
-```Shell Session
-$ git remote -v
-origin  git@gitlab.hrz.tu-chemnitz.de:LOGIN/hpc-compendium.git (fetch)
-origin  git@gitlab.hrz.tu-chemnitz.de:LOGIN/hpc-compendium.git (push)
-upstream-zih  git@gitlab.hrz.tu-chemnitz.de:zih/hpc-compendium/hpc-compendium.git (fetch)
-upstream-zih  git@gitlab.hrz.tu-chemnitz.de:zih/hpc-compendium/hpc-compendium.git (push)
-```
-
-Next, you should synchronize your `main` branch with the upstream.
-
-```Shell Session
-~ git checkout main
-~ git pull upstream main
-```
-
-At this point, your `main` branch is up-to-date with the original documentation of HPC compendium.
-
-<!--To push your sync changes to your fork you can do the following:-->
-<!--git push origin main-->
-
-#### Making Changes and Merge Requests
-
-It is good git-practice to only use the `main` branch for synchronization with the upstream, not for
-changes, as outlined in the previous subsection. In order to commit to this documentation, create a
-new branch (a so-called feature branch) basing on the `main` branch and commit your changes to it.
-
-```Shell Session
-~ git checkout main
-~ git checkout -b <FEATUREBRANCH>
-# Edit file1, file2 etc.
-~ git add <file1> <file2>
-~ git commit -m <COMMIT MESSAGE>
-~ git push origin <FEATUREBRANCH>
-```
-
-The last command pushes the changes to your remote at branch `FEATUREBRANCH`. Now, it is time to
-incorporate the changes and improvements into the HPC Compendium. For this, create a
-[merge request](https://gitlab.hrz.tu-chemnitz.de/zih/hpc-compendium/hpc-compendium/-/merge_requests/new)
-to the `main` branch.
-
-### Important Branches
-
-There are two important branches in this repository:
-
-- Preview:
-  - Branch containing recent changes which will be soon merged to main branch (protected
-    branch)
-- Main: Branch which is deployed at doc.zih.tu-dresden.de holding the
-    current documentation (protected branch)
-
-If you are totally sure about your commit (e.g., fix a typo), it is only the following steps:
-
-  1. Synchronize branches
-  1. Edit the markdown file of interest
-  1. Commit change
-  1. Push commit to your fork and probably new branch
-  1. Pose Merge Request
-
-## Checks
-
-We have several checks on the markdown sources to ensure for a consistent and high quality of the
-documentation. These checks are run within the CI/CD pipeline and changes are only deployed to the
-HPC compendium, if the checks are passed. Thus, we **highly recommend** running the checks locally
-before committing and posing a merge request.
-
-* Markdown linter
-* Check internal and external links
-* Check code and command examples
-
-### Markdown Linter
-
-The [markdown linter client](https://github.com/igorshubovych/markdownlint-cli) helps to keep the
-markdown source code clean and consistent.
-
-Installation
-
-```Bash
-~ [sudo] npm [-g]  install markdownlint-cli
-```
-
-The configuration is stored in `.markdownlintrc`.
-The tool `markdownlint` can be run in dry or fix mode.
-The *dry* mode (default) only outputs findings, whereas in *fix* mode it resolves basic
-errors directly in the markdown files.
-
-```BAsh
-~ cd doc.zih.tu-dresden.de/
-~ markdownlint [--fix] docs/index.md
-docs/index.md:8:131 MD013/line-length Line length [Expected: 130; Actual: 138]
-```
-
-Before committing, invoke the script `util/lint-changes.sh` which calls the markdownlint tool for all
-(git-)changed markdown files.
-
-```Shell Session
-~ sh util/lint-changes.sh
-hpc-compendium-2.0-gitlab-tudzih git:(master) ✗ sh util/lint-changes.sh
-README.md:6 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]
-README.md:7 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 3]
-README.md:21 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]
-README.md:22 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Why is this not at gitlab.hrz.tu-chemnitz.de?"]
-[8< 8<]
-```
-
-### Check Links
-
-No one likes dead links. Therefore, we check the internal and external links within the markdown
-source files. For that, the script `util/check-links.sh` and the tool
-[markdown-link-check](https://github.com/tcort/markdown-link-check) can be used.
-
-The tool `markdown-link-check` checks links within a certain file (or using some shell magic for all
-markdown files, as depicted below). On the other hand, the script `util/check-links.sh` checks only
-links for files in the repository, which are "gifferent" ("gifferent" is a word composition from *git*
-and *different to main branch*).
-
-#### Markdown-link-check
-
-Installation (see [official documentation](https://github.com/tcort/markdown-link-check#installation))
-
-```Shell Session
-~ [sudo] npm [-g] install markdown-link-check
-```
-
-Run check
-
-```Shell Session
-~ cd doc.zih.tu-dresden.de/
-~ markdown-link-check docs/jobs/Slurm.md
-
-FILE: docs/jobs/Slurm.md
-[✖] Slurmgenerator
-[✖] Compendium.RunningNxGpuAppsInOneJob
-[✓] https://slurm.schedmd.com/sbatch.html
-[✖] BindingAndDistributionOfTasks
-[✓] http://slurm.schedmd.com/hdf5_profile_user_guide.html
-[✓] http://slurm.schedmd.com/sh5util.html
-[✓] mailto:hpcsupport@zih.tu-dresden.de
-[✓] http://slurm.schedmd.com/
-[✓] http://www.schedmd.com/slurmdocs/rosetta.html
-
-9 links checked.
-
-ERROR: 3 dead links found!
-[✖] Slurmgenerator → Status: 400
-[✖] Compendium.RunningNxGpuAppsInOneJob → Status: 400
-[✖] BindingAndDistributionOfTasks → Status: 400
-```
-
-In this example, all external links are fine, but three links to internal documents need to be
-fixed.
-
-To check the links within all markdown files in one sweep, some shell magic is necessary
-
-```Bash
-~ cd doc.zih.tu-dresden.de/
-~ find . -name \*.md -exec markdown-link-check {} \;
-```
-
-#### Check-links.sh
-
-The script `util/check-links.sh` checks links for all gifferent files, i.e., markdown files which
-are part of the repository and different to the `main` branch. Use this script before committing
-your changes to make sure your commit passes the CI/CD pipeline.
-
-### Check Code and Commands
-
-The script `xyz.sh` checks if the code chunks are runnable on a login node.
-It is invoked as follows ...
-
-### Check Pages Structure
-
-The script `util/check-no-floating.sh` first checks the hierarchy depth of the pages structure
-and the second check tests if every markdown file is included in the navigation section of the
-`mkdocs.yaml` file.
-
-The script is invoked and reports as follows
-
-```Bash
-~ sh doc.zih.tu-dresden.de/util/check-no-floating.sh doc.zih.tu-dresden.de
-HardwareTaurus.md is not included in nav
-BigDataFrameworksApacheSparkApacheFlinkApacheHadoop.md is not included in nav
-pika.md is not included in nav
-specific_software.md is not included in nav
-```
-
-## Content Rules
+# Content Rules
 
 **Remark:** Avoid using tabs both in markdown files and in `mkdocs.yaml`. Type spaces instead.
 
-### New Page and Pages Structure
+## New Page and Pages Structure
 
 The pages structure is defined in the configuration file mkdocs.yaml:
 
@@ -394,7 +27,7 @@ The sub-directory and file name should follow the pattern `fancy_title_and_more.
 Make sure that the new page **is not floating**, i.e., it can be reached directly from
 the documentation structure.
 
-### Markdown
+## Markdown
 
 1. Please keep things simple, i.e., avoid using fancy markdown dialects.
     * [Cheat Sheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet)
@@ -415,11 +48,11 @@ should be highlighted, etc. Code examples, longer than half screen height should
     [...]
     ```
 
-### Writing Style
+## Writing Style
 
 * Capitalize headings, e.g. *Exclusive Reservation of Hardware*
 
-### Spelling and Technical Wording
+## Spelling and Technical Wording
 
 To provide a consistent and high quality documentation, and help users to find the right pages,
 there is a list of conventions w.r.t. spelling and technical wording.
@@ -428,11 +61,10 @@ there is a list of conventions w.r.t. spelling and technical wording.
 * `I/O` not `IO`
 * `Slurm` not `SLURM`
 * `Filesystem` not `file system`
-* `ZIH system` and `ZIH systems` not `Taurus`, `HRSKII`, `our HPC systems` etc.
+* `ZIH system` and `ZIH systems` not `Taurus` etc. if possible
 * `Workspace` not `work space`
-* avoid term `HPC-DA`
 
-### Code Blocks and Command Prompts
+## Code Blocks and Command Prompts
 
 Showing commands and sample output is an important part of all technical documentation. To make
 things as clear for readers as possible and provide a consistent documentation, some rules have to
@@ -445,7 +77,7 @@ be followed.
 1. It should be clear from the prompt, where the command is run (e.g. local machine, login node or
    specific partition).
 
-#### Prompts
+### Prompts
 
 We follow this rules regarding prompts:
 
@@ -472,7 +104,7 @@ We follow this rules regarding prompts:
 * Using some magic, the prompt as well as the output is identified and will not be copied!
 * Stick to the [generic user name](#data-privacy-and-generic-user-name) `marie`.
 
-#### Code Blocks and Syntax Highlighting
+### Code Blocks and Syntax Highlighting
 
 This project makes use of the extension
 [pymdownx.highlight](https://squidfunk.github.io/mkdocs-material/reference/code-blocks/) for syntax
@@ -585,19 +217,18 @@ drwxr-xr-x   3 marie p_marie      4096 Feb 12  2020 data
 -rw-rw----   1 marie p_marie      4096 Jan 24  2020 readme.md
 ```
 
-### Mark Omissions
+## Mark Omissions
 
 If showing only a snippet of a long output, omissions are marked with `[...]`.
 
-### Mark Placeholders
-
+## Unix Rules
 Stick to the Unix rules on optional and required arguments, and selection of item sets:
 
 * `<required argument or value>`
 * `[optional argument or value]`
 * `{choice1|choice2|choice3}`
 
-## Graphics and Attachments
+# Graphics and Attachments
 
 All graphics and attachments are saved within `misc` directory of the respective sub directory in
 `docs`.
diff --git a/doc.zih.tu-dresden.de/docs/contrib/contribute_container.md b/doc.zih.tu-dresden.de/docs/contrib/contribute_container.md
index 6f6d74389ed848d3e52d10f623be470a48bda998..9a2ae4935e0a94b5a935f9611337b5b077314904 100644
--- a/doc.zih.tu-dresden.de/docs/contrib/contribute_container.md
+++ b/doc.zih.tu-dresden.de/docs/contrib/contribute_container.md
@@ -1,22 +1,36 @@
 # Contributing Using a Local Clone and a Docker Container
 
-see also: [https://gitlab.hrz.tu-chemnitz.de/zih/hpcsupport/hpc-compendium/-/blob/preview/doc.zih.tu-dresden.de/README.md]
+## Git Procedure
+
+Please follow this standard Git procedure for working with a local clone:
+
+1. Change to a local (unencrypted) filesystem. (We have seen problems running the container
+an ecryptfs filesystem. So you might
+want to use e.g. `/tmp` as root directory.)
+1. Get a clone of the Git: `git clone git@gitlab.hrz.tu-chemnitz.de:zih/hpc-compendium/hpc-compendium.git`
+1. Change to the root of the Git colen: `cd hpc-compendium`
+1. Create a new feature branch for you to work in. Ideally name it like the file you want
+to modify. `git checkout -b <BRANCHNAME>`. (Navigation section can be found in `mkdocs.yaml`.)
+1. Add/correct the documentation with your preferred editor.
+1. Run the correctness checks until everything is fine. - Incorrect files will be rejected
+automatically by our CI pipeline.
+1. Commit the changes with `git commit -m "<DESCRIPTION>" <FILE LIST>`. Include a description
+of the change and a list of all changed files.
+1. Push the local changes to the global feature branch with `git push origin <BRANCHNAME>`.
+1. As an output you get a https link. Follow it to create the merge request against the preview branch.
+
+You can find the details and command in the next section.
 
-## Prerequisites
+## Preparation
 
-Assuming you understand in principle how to work with our git. Now you need:
+Assuming you understand in principle how to work with our Git. Now you need:
 
 * a system with running Docker installation
 * all necessary access/execution rights
 * a local clone of the repository in the directory `./hpc-compendium`
 
-Remark: We have seen problems running the container an ecryptfs filesystem. So you might
-want to use `/tmp` as root directory.
-
-## Preparation
-
 Build the docker image. This might take a bit longer, but you have to
-run it only once in a while (when we have changed the Dockerfile).
+run it only once in a while.
 
 ```Bash
 cd hpc-compendium
@@ -53,7 +67,17 @@ the merge.
 
 ### Run the Proposed Checks Inside Container
 
-Remember to keep the local web server running in the other shell.
+In our continuous integration (CI) pipeline, a merge request triggers the automated check of
+
+* correct links,
+* correct spelling,
+* correct text format.
+
+If one of them fails the merge request will be recjected. To prevent this you can run these
+checks locally and adapt your files accordingly.
+
+!!! note
+    Remember to keep the local web server running in the other shell.
 
 First, change to the `hpc-compendium` directory and set the environment
 variable DC to save a lot of keystrokes :-)
@@ -64,15 +88,6 @@ export DC='docker exec -it hpc-compendium bash -c '
 
 and use it like this...
 
-#### Linter
-
-If you want to check whether the markdown files are formatted
-properly, use the following command:
-
-```Bash
-$DC 'markdownlint docs'
-```
-
 #### Link Checker
 
 To check a single file, e.g.
@@ -106,3 +121,18 @@ $DC ./util/check-spelling.sh
 This outputs all words of all files that are unknown to the spell checker.
 To let the spell checker "know" a word, append it to
 `doc.zih.tu-dresden.de/wordlist.aspell`.
+
+#### Linter
+
+If you want to check whether the markdown files are formatted
+properly, use the following command:
+
+```Bash
+$DC 'markdownlint docs'
+```
+
+
+
+
+
+
diff --git a/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md b/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md
index 06d1540232035b19224c084b358b1102a65c9461..04966d8c8454af490c46e525a772d9ad7bc04802 100644
--- a/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md
+++ b/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md
@@ -1,38 +1,33 @@
 # How To Contribute
 
-## Git Procedure
+## Contribute via Issue
 
-```Bash
-~ git clone git@gitlab.hrz.tu-chemnitz.de:zih/hpc-compendium/hpc-compendium.git
-~ cd hpc-compendium
-~ git checkout preview
-```
+Users can contribute to the documentation via the
+[issue tracking system](https://gitlab.hrz.tu-chemnitz.de/zih/hpc-compendium/hpc-compendium/-/issues).
+For that, open an issue to report typos and missing documentation or request for more precise
+wording etc.  ZIH staff will get in touch with you to resolve the issue and improve the
+documentation.
 
-## Transferring Content
+**Reminder:** Non-documentation issues and requests need to be send as ticket to
+[hpcsupport@zih.tu-dresden.de](mailto:hpcsupport@zih.tu-dresden.de).
 
-1. Grab a markdown source file from `twiki2md/root/` directory (a topic you are comfortable with)
-1. Find place in new structure according to
+## Contribute via Web IDE
 
-  * Create new feature branch holding your work `~ git checkout -b <BRANCHNAME>`, whereas
-  branch name can be `<FILENAME>` for simplicity
-  * Copy reviewed markdown source file to `docs/` directory via
-    `~ git mv twiki2md/root/<FILENAME>.md doc.zih.tu-dresden.de/docs/<SUBDIR>/<FILENAME>.md`
-  * Update navigation section in `mkdocs.yaml`
+GitLab offers a rich and versatile web interface to work with repositories. To fix typos and edit
+source files, just select the file of interest and click the `Edit` button. A text and commit
+editor are invoked: Do your changes, add a meaningful commit message and commit the changes.
 
-1. Commit and push to feature branch via
+The more sophisticated integrated Web IDE is reached from the top level menu of the repository or
+by selecting any source file.
 
-```Bash
-~ git commit docs/<SUBDIR>/<FILENAME>.md mkdocs.yaml -m "MESSAGE"
-~ git push origin <BRANCHNAME>
-```
+Other git services might have an equivalent web interface to interact with the repository. Please
+refer to the corresponding documentation for further information.
 
-1. Run checks locally and fix the issues. Otherwise the pipeline will fail.
+<!--This option of contributing is only available for users of-->
+<!--[gitlab.hrz.tu-chemnitz.de](https://gitlab.hrz.tu-chemnitz.de). Furthermore, -->
 
-    * [Check links](contrib_guide.md#check-links) (There might be broken links which can only be solved
-        with ongoing transfer of content.)
-    * [Check pages structure](contrib_guide.md#check-pages-structure)
-    * [Markdown Linter](contrib_guide.md#markdown-linter)
+## Contribute Using Git Locally
 
-1. Create
-  [merge request](https://gitlab.hrz.tu-chemnitz.de/zih/hpc-compendium/hpc-compendium/-/merge_requests)
-   against `preview` branch
+For experienced Git users, we provide a Docker containier that includes all checks of the CI engine
+used in the backend. Using them should ensure that mareg requests will not be blocked
+due to automatic checking. For details, see [Work Locally Using Containers](contrib/contribute_container) .
diff --git a/doc.zih.tu-dresden.de/mkdocs.yml b/doc.zih.tu-dresden.de/mkdocs.yml
index f3cf198a3f408ffc5ec36cd21ec82a399bd2783e..ca85de76f9292833c663a2193cd1a8a20896e11c 100644
--- a/doc.zih.tu-dresden.de/mkdocs.yml
+++ b/doc.zih.tu-dresden.de/mkdocs.yml
@@ -135,8 +135,8 @@ nav:
     - Windows Batchjobs: archive/windows_batch.md
   - Contribute:
     - Howto: contrib/howto_contribute.md
-    - Contribution Guide: contrib/contrib_guide.md
-    - Using Containers: contrib/contribute_container.md
+    - Content Rules: contrib/content_rules.md
+    - Work Locally Using Containers: contrib/contribute_container.md
     
 # Project Information
 site_name: ZIH HPC Compendium