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 67c9bb3a8e5482895d79d9cca57128acd1bb9c21..065f40b75db35cd0ec4ac5c3e1a8fa51347c546e 100644
--- a/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md
+++ b/doc.zih.tu-dresden.de/docs/contrib/howto_contribute.md
@@ -4,8 +4,8 @@
Ink is better than the best memory.
-In this section you will find information on the technical setup of this documentation, the applied
-content rules, Git workflow and certain ways to contribute.
+In this section you will find information about the technical setup of this documentation, the
+content rules that apply, the Git workflow, and specific ways to contribute.
Your contributions are highly welcome. This can range from fixing typos, improving the phrasing and
wording to adopting examples, command lines and adding new content. Our goal is to provide a
@@ -15,41 +15,41 @@ Moreover, is is constantly reviewed and updated.
## Technical Setup
This documentation is written in markdown and translated into static html pages using
-[mkdocs](https://www.mkdocs.org/). The single configuration file `mkdocs.yml` holds the pages
-structure as well as specification of the theme and extensions.
+[mkdocs](https://www.mkdocs.org/). The single configuration file `mkdocs.yml` contains the page
+structure as well as the specification of the theme and extensions.
We manage all essential files (markdown pages, graphics, configuration, theme, etc.) within a
[public Git repository](https://gitlab.hrz.tu-chemnitz.de/zih/hpcsupport/hpc-compendium),
-allowing for collaborative working and revision control. GitLab features offer different
+allowing for collaborative working and revision control. GitLab's features offer different
possibilities of contribution and ensure up-to-date and consistent content by including a review
-process. In principle, there are three possible ways how you can contribute to this documentation.
-These are outlined below.
+process. There are three possible ways how you can contribute to this documentation.
+These are described below.
!!! tip "Before you start"
Before you start your very first commit, please make sure that you are familiar with our
- [Git workflow](#git-workflow) and that you have at least skimmed the
+ [Git workflow](#git-workflow) and that you have at least skimmed through the
[Content Rules](content_rules.md).
## Git Workflow
-We employ a so-called Git feature workflow with development branch. In our case, the working branch
+We employ a so-called Git feature workflow with a development branch. In our case, the working branch
is called `preview` and is kept in parallel to the `main` branch.
-All contributions, e.g., new content, improved wording, fixed typos, etc, are added to separate
+All contributions, e.g., new content, improved wording, fixed typos, etc., are added to separate
feature branches which base on `preview`. If the contribution is ready, you will have to create a
-merge request back to the `preview` branch. A member of ZIH team will review the changes (four-eyes
-principle) and finally merge your changes to `preview`. All contributions need to pass the CI
-pipeline consisting of several checks to ensure compliance with the content rules. Please, don't
-worry too much about the checks. ZIH staff will help you with that. You will find more information
-on the [CI/CD pipeline](cicd-pipeline) in the eponymous subsection.
+merge request back to the `preview` branch. A member of the ZIH team will review the changes
+(four-eyes principle) and finally merge your changes to `preview`. All contributions need to pass
+through the CI pipeline consisting of several checks to ensure compliance with the content rules.
+Please, don't worry too much about the checks. The ZIH staff will help you with that. You can find
+more information about the [CI/CD pipeline](cicd-pipeline) in the eponymous subsection.
In order to publish the updates and make them visible in the compendium,
the changes on `preview` branch are either automatically merged into the `main` branch on every
Monday via a pipeline schedule, or manually by admin staff. Moreover, the `main` branch is deployed
to [https://compendium.hpc.tu-dresden.de](https://compendium.hpc.tu-dresden.de) and always reflects
-a production-ready state. Manual interventions are only necessary in case of merge conflicts. The
-admin staff will take care on this process.
+a production-ready state. Manual interventions are only necessary in case of merge conflicts.
+This process is handled by the admins.
???+ note "Graphic on Git workflow"
@@ -88,20 +88,20 @@ admin staff will take care on this process.
## Content Rules
-To ensure a high-quality and consistent documentation and to make it easier for readers to
-understand all content, we set some [Content rules](content_rules.md). Please follow
+To ensure a high-quality and consistent documentation, and to make it easier for readers to
+understand all content, we have established [Content rules](content_rules.md). Please follow
these rules regarding markdown syntax and writing style when contributing! Furthermore, reviewing
your changes takes less time and your improvements appear faster on the official documentation.
!!! note
If you contribute, you are fully and solely responsible for the content you create and have to
- ensure that you have the right to create it under the laws which apply.
+ ensure that you have the right to create it under applicable laws.
## Contribute via Issue
-You can contribute to the documentation via the
-[GitLab issue tracking system](https://gitlab.hrz.tu-chemnitz.de/zih/hpcsupport/hpc-compendium/-/issues).
+You can contribute to the documentation using
+[GitLab's issue tracking system](https://gitlab.hrz.tu-chemnitz.de/zih/hpcsupport/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.
@@ -119,22 +119,21 @@ documentation.
## Contribute via Web IDE
If you have a web browser (most probably you are using it to read this page) and want to contribute
-to the documentation, you are good to go. GitLab offers a rich and versatile web interface to work
-with repositories. To start fixing typos and edit source files, please find more information on the
-page [Contributing via web browser](contribute_browser.md).
+to the documentation, you are good to go. GitLab offers a rich and versatile web interface for
+working with repositories. To start fixing typos and edit source files, you can find more
+information on the page [Contributing via web browser](contribute_browser.md).
## Contribute via Local Clone
-For experienced Git users, we provide a Docker container that includes all checks of the CI engine
-used in the back-end. Using them should ensure that merge requests will not be blocked
-due to automatic checking.
-The page on [Contributing via local clone](contribute_container.md) provides you with the details
-about how to setup and use your local clone of the repository.
+For experienced Git users, we provide a Docker container that includes all the checks of the CI
+engine used in the backend. Using them should ensure that merge requests are not blocked due to
+automatic checks. The page [Contributing via local clone](contribute_container.md) provides you
+with the details about how to set up and use your local clone of the repository.
## CI/CD Pipeline
-All contributions need to pass the CI pipeline which consists of various checks to ensure, that the
-[content rules](content_rules.md) are met.
+All contributions need to pass through the CI pipeline which consists of various checks to ensure
+that the [content rules](content_rules.md) have been followed.
The stages of the CI/CD pipeline are defined in a `.gitlab.yaml` file. For security reasons, this
-file is managed in a second, private repository.
+file is maintained in a second, private repository.
diff --git a/doc.zih.tu-dresden.de/docs/data_lifecycle/workspaces.md b/doc.zih.tu-dresden.de/docs/data_lifecycle/workspaces.md
index a450eb22b3ea7cadb756d78bb15bcb5c04773de1..515628fb9be4aeb3ce5d01ef928026b521be5832 100644
--- a/doc.zih.tu-dresden.de/docs/data_lifecycle/workspaces.md
+++ b/doc.zih.tu-dresden.de/docs/data_lifecycle/workspaces.md
@@ -3,9 +3,8 @@
Storage systems differ in terms of capacity, streaming bandwidth, IOPS rate, etc. Price and
efficiency don't allow to have it all in one. That is why fast parallel filesystems at ZIH have
restrictions with regards to **age of files** and [quota](permanent.md#quotas). The mechanism of
-workspaces enables users to better manage their HPC data.
-
-The concept of workspaces is common and used at a large number of HPC centers.
+workspaces enables you to better manage your HPC data. It is common and used at a large number
+of HPC centers.
!!! note