Repository: owncloud/ocis
Pull request #3547 (2022-04-19 15:04:20)

Various grammar and typos
## Description
I noticed some, so let my IDE find more.

## How Has This Been Tested?
N/A

## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Technical debt
- [ ] Tests only (no source changes)

## Checklist:
- [ ] Code changes
- [ ] Unit tests added
- [ ] Acceptance tests added
- [ ] Documentation ticket raised: <link> 



Patch:
diff --git a/deployments/examples/oc10_ocis_parallel/.env b/deployments/examples/oc10_ocis_parallel/.env
index 7ba204577c4..111d8a20d16 100644
--- a/deployments/examples/oc10_ocis_parallel/.env
+++ b/deployments/examples/oc10_ocis_parallel/.env
@@ -8,7 +8,7 @@ DEMO_USERS=false
 
 ### Traefik settings ###
 TRAEFIK_LOG_LEVEL=
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
@@ -48,7 +48,7 @@ LDAP_ADMIN_PASSWORD=
 LDAP_MANAGER_DOMAIN=
 
 ### Keycloak ###
-# Domain of Keycloak, where you can find the managment and authentication frontend. Defaults to "keycloak.owncloud.test"
+# Domain of Keycloak, where you can find the management and authentication frontend. Defaults to "keycloak.owncloud.test"
 KEYCLOAK_DOMAIN=
 # Realm which to be used with oCIS. Defaults to "oCIS"
 KEYCLOAK_REALM=
diff --git a/deployments/examples/oc10_ocis_parallel/config/ldap/ldif/10_owncloud_schema.ldif b/deployments/examples/oc10_ocis_parallel/config/ldap/ldif/10_owncloud_schema.ldif
index bff48c367e5..85264d97de4 100644
--- a/deployments/examples/oc10_ocis_parallel/config/ldap/ldif/10_owncloud_schema.ldif
+++ b/deployments/examples/oc10_ocis_parallel/config/ldap/ldif/10_owncloud_schema.ldif
@@ -6,5 +6,5 @@ objectClass: olcSchemaConfig
 cn: owncloud
 olcAttributeTypes: ( 1.3.6.1.4.1.39430.1.1.1 NAME 'ownCloudQuota' DESC 'User Quota (e.g. 2 GB)' EQUALITY caseExactMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
 olcAttributeTypes: ( 1.3.6.1.4.1.39430.1.1.2 NAME 'ownCloudUUID' DESC 'A non-reassignable and persistent account ID)' EQUALITY uuidMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE )
-olcAttributeTypes: ( 1.3.6.1.4.1.39430.1.1.3 NAME 'ownCloudSelector' DESC 'A selector attribute for a route in the ownCloud Infinte Scale proxy)' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
+olcAttributeTypes: ( 1.3.6.1.4.1.39430.1.1.3 NAME 'ownCloudSelector' DESC 'A selector attribute for a route in the ownCloud Infinite Scale proxy)' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
 olcObjectClasses: ( 1.3.6.1.4.1.39430.1.2.1 NAME 'ownCloud' DESC 'ownCloud LDAP Schema' AUXILIARY MAY ( ownCloudQuota $ ownCloudUUID $ ownCloudSelector ) )
diff --git a/deployments/examples/oc10_ocis_parallel/config/oc10/10-custom-config.sh b/deployments/examples/oc10_ocis_parallel/config/oc10/10-custom-config.sh
index 543981d5e40..d930c64b36b 100755
--- a/deployments/examples/oc10_ocis_parallel/config/oc10/10-custom-config.sh
+++ b/deployments/examples/oc10_ocis_parallel/config/oc10/10-custom-config.sh
@@ -6,7 +6,7 @@ gomplate \
   -f /etc/templates/oidc.config.php \
   -o ${OWNCLOUD_VOLUME_CONFIG}/oidc.config.php
 
-# we need at least version 2.1.0 of the oenidconnect app
+# we need at least version 2.1.0 of the openidconnect app
 occ market:upgrade --major openidconnect
 occ app:enable openidconnect
 
diff --git a/deployments/examples/ocis_hello/.env b/deployments/examples/ocis_hello/.env
index 0e70f6b66dd..856e2b6bd42 100644
--- a/deployments/examples/ocis_hello/.env
+++ b/deployments/examples/ocis_hello/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_individual_services/.env b/deployments/examples/ocis_individual_services/.env
index 25569f9b31d..3d8358a8b0b 100644
--- a/deployments/examples/ocis_individual_services/.env
+++ b/deployments/examples/ocis_individual_services/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_keycloak/.env b/deployments/examples/ocis_keycloak/.env
index a2f80cefc63..7c0b9b1e768 100644
--- a/deployments/examples/ocis_keycloak/.env
+++ b/deployments/examples/ocis_keycloak/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=false
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_ldap/.env b/deployments/examples/ocis_ldap/.env
index a3eebbf4cae..f1c5232e762 100644
--- a/deployments/examples/ocis_ldap/.env
+++ b/deployments/examples/ocis_ldap/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_s3/.env b/deployments/examples/ocis_s3/.env
index b53901dc40d..682264433ab 100644
--- a/deployments/examples/ocis_s3/.env
+++ b/deployments/examples/ocis_s3/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_traefik/.env b/deployments/examples/ocis_traefik/.env
index 40120083645..f75e2d5fb90 100644
--- a/deployments/examples/ocis_traefik/.env
+++ b/deployments/examples/ocis_traefik/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/deployments/examples/ocis_wopi/.env b/deployments/examples/ocis_wopi/.env
index 66cfabeb7f7..44a465bbf9e 100644
--- a/deployments/examples/ocis_wopi/.env
+++ b/deployments/examples/ocis_wopi/.env
@@ -7,7 +7,7 @@ INSECURE=true
 DEMO_USERS=true
 
 ### Traefik settings ###
-# Serve Treafik dashboard. Defaults to "false".
+# Serve Traefik dashboard. Defaults to "false".
 TRAEFIK_DASHBOARD=
 # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
 TRAEFIK_DOMAIN=
diff --git a/docs/architecture/efficient-stat-polling.md b/docs/architecture/efficient-stat-polling.md
index f7b19cf5a6f..2fa31fe5c60 100644
--- a/docs/architecture/efficient-stat-polling.md
+++ b/docs/architecture/efficient-stat-polling.md
@@ -16,7 +16,7 @@ What does ETag propagation mean? Whenever a file changes its content or metadata
 {{<mermaid class="text-center">}}
 graph TD
   linkStyle default interpolate basis
-  
+
   subgraph final ETag propagation
     ert3(( etag:N )) --- el3(( etag:O )) & er3(( etag:N ))
     er3 --- erl3(( etag:O )) & err3(( etag:N ))
@@ -27,7 +27,7 @@ graph TD
     er2 --- erl2(( etag:O )) & err2(( etag:N ))
   end
 
-  subgraph initial file change 
+  subgraph initial file change
     ert(( etag:O )) --- el(( etag:O )) & er(( etag:O ))
     er --- erl(( etag:O )) & err(( etag:N ))
   end
@@ -48,9 +48,9 @@ graph TD
 
   ec( client ) -->|"stat()"|ert
 
-  subgraph  
+  subgraph
     ert(( )) --- el(( )) & er(( ))
-    er --- erl(( )) & err(( ))  
+    er --- erl(( )) & err(( ))
   end
 {{</mermaid>}}
 
@@ -65,21 +65,21 @@ graph TD
 
   ec( client ) -->|"stat()"|ert
 
-  subgraph  
+  subgraph
     ert(( )) --- el(( )) & er(( ))
     er --- erl(( )) & err(( ))
   end
-  
+
   mc( client ) -->|"stat()"|mrt
 
-  subgraph  
+  subgraph
     mrt(( )) --- ml(( )) & mr(( ))
     mr --- mrl(( )) & mrr(( ))
   end
 
   fc( client ) -->|"stat()"|frt
 
-  subgraph  
+  subgraph
     frt(( )) --- fl(( )) & fr(( ))
     fr --- frl(( )) & frr(( ))
   end
@@ -88,14 +88,14 @@ graph TD
 ## Sharing
 *Storage providers* are responsible for persisting shares as close to the storage as possible.
 
-One implementation may persist shares using ACLs, another might use custom extended attributes. The chosen implementation is storage specific and always a tradeoff between various requirements. Yet, the goal is to treat the storage provider as the single source of truth for all metadata. 
+One implementation may persist shares using ACLs, another might use custom extended attributes. The chosen implementation is storage specific and always a tradeoff between various requirements. Yet, the goal is to treat the storage provider as the single source of truth for all metadata.
 
-If users can bypass the storage provider using eg. `ssh` additional mechanisms needs to make sure no inconsistencies arise:
+If users can bypass the storage provider using e.g. `ssh` additional mechanisms needs to make sure no inconsistencies arise:
 - the ETag must still be propagated in a tree, eg using inotify, a policy engine or workflows triggered by other means
-- deleted files should land in the trash (eg. `rm` could be wrapped to move files to trash)
+- deleted files should land in the trash (e.g. `rm` could be wrapped to move files to trash)
 - overwriting files should create a new version ... other than a fuse fs I see no way of providing this for normal posix filesystems. Other storage backends that use the s3 protocol might provide versions natively.
 
-The storage provider is also responsible for keeps track of references eg. using a shadow tree that users normally cannot see or representing them as symbolic links in the filesystem (Beware of symbolic link cycles. The clients are currently unaware of them and would flood the filesystem).
+The storage provider is also responsible for keeps track of references e.g. using a shadow tree that users normally cannot see or representing them as symbolic links in the filesystem (Beware of symbolic link cycles. The clients are currently unaware of them and would flood the filesystem).
 
 To prevent write amplification ETags must not propagate across references. When a file that was shared by einstein changes the ETag must not be propagated into any share recipients tree.
 
@@ -106,7 +106,7 @@ graph TD
 
   ec( einsteins client ) -->|"stat()"|ert
 
-  subgraph  
+  subgraph
     ml --- mlr(( ))
     mrt(( )) --- ml(( )) & mr(( ))
     mr --- mrl(( )) & mrr(( ))
@@ -114,11 +114,11 @@ graph TD
 
   mlr -. reference .-> er
 
-  subgraph  
+  subgraph
     ert(( )) --- el(( )) & er(( ))
     er --- erl(( )) & err(( ))
   end
-  
+
   mc( maries client ) -->|"stat()"|mrt
 
 {{</mermaid>}}
@@ -151,14 +151,14 @@ graph TD
   mvr --- mrt
   fvr --- frt
 
-  subgraph  
+  subgraph
     ert(( )) --- el(( )) & er(( ))
     er --- erl(( )) & err(( ))
   end
-  
+
   mc( client ) -->|"stat()"|mvr
 
-  subgraph  
+  subgraph
     mrt(( )) --- ml(( )) & mr(( ))
     ml --- mlm(( ))
     mr --- mrl(( )) & mrr(( ))
@@ -169,7 +169,7 @@ graph TD
 
   fc( client ) -->|"stat()"|fvr
 
-  subgraph  
+  subgraph
     frt(( )) --- fl(( )) & fr(( ))
     fr --- frl(( )) & frr(( ))
   end
diff --git a/docs/clients/rclone/webdav-sync-oidc.md b/docs/clients/rclone/webdav-sync-oidc.md
index a6d99593e6d..2360ff97a75 100644
--- a/docs/clients/rclone/webdav-sync-oidc.md
+++ b/docs/clients/rclone/webdav-sync-oidc.md
@@ -15,7 +15,7 @@ Rclone itself is not able to open and maintain an OpenID Connect session. But it
 
 ### Setting up the OIDC-agent
 
-You need to install the [OIDC-agent](https://github.com/indigo-dc/oidc-agent) from your OS' package repository (eg. [Debian](https://github.com/indigo-dc/oidc-agent#debian-packages) or [MacOS](https://github.com/indigo-dc/oidc-agent#debian-packages)).
+You need to install the [OIDC-agent](https://github.com/indigo-dc/oidc-agent) from your OS' package repository (e.g. [Debian](https://github.com/indigo-dc/oidc-agent#debian-packages) or [MacOS](https://github.com/indigo-dc/oidc-agent#debian-packages)).
 
 
 ### Configuring the the OIDC-agent
@@ -63,4 +63,4 @@ We now can use Rclone to sync the local folder `/tmp/test` to `/test` in your oC
 rclone sync :local:/tmp :webdav:/test
 ```
 
-If your oCIS doesn't use valid SSL certificates, you may need to use `rclone --no-check-certificate sync ...`. 
+If your oCIS doesn't use valid SSL certificates, you may need to use `rclone --no-check-certificate sync ...`.
diff --git a/docs/extensions/glauth/configuration-hints.md b/docs/extensions/glauth/configuration-hints.md
index 9ca9532953f..8f03b721537 100644
--- a/docs/extensions/glauth/configuration-hints.md
+++ b/docs/extensions/glauth/configuration-hints.md
@@ -13,4 +13,4 @@ geekdocFilePath: configuration-hints.md
 
 The default setup does not use a fallback backend. It can be enabled by setting the `GLAUTH_FALLBACK_DATASTORE` environment variable.
 
-When using `owncloud` make sure to use the full URL to the [ownCloud 10 graph api app](https://github.com/owncloud/graphapi) endpoint, eg.: `GLAUTH_FALLBACK_SERVERS="https://demo.owncloud.com/apps/graphapi/v1.0"`
+When using `owncloud` make sure to use the full URL to the [ownCloud 10 graph api app](https://github.com/owncloud/graphapi) endpoint, e.g.: `GLAUTH_FALLBACK_SERVERS="https://demo.owncloud.com/apps/graphapi/v1.0"`
diff --git a/docs/extensions/storage/apps.md b/docs/extensions/storage/apps.md
index 1ca902ba69c..748e19d9484 100644
--- a/docs/extensions/storage/apps.md
+++ b/docs/extensions/storage/apps.md
@@ -11,7 +11,7 @@ oCIS is all about files. But most of the time you want to do something with file
 
 ## App provider capability
 
-The capabilities endpoint (eg. `https://localhost:9200/ocs/v1.php/cloud/capabilities?format=json`) gives you following capabilities which are relevant for the app provider:
+The capabilities endpoint (e.g. `https://localhost:9200/ocs/v1.php/cloud/capabilities?format=json`) gives you following capabilities which are relevant for the app provider:
 
 ```json
 {
@@ -399,7 +399,7 @@ You will receive a file id of the freshly created file, which you can use to ope
   }
   ```
 
-- `filename` is invalid (eg. includes a path segment)
+- `filename` is invalid (e.g. includes a path segment)
 
   HTTP status code: 400
 
@@ -428,7 +428,7 @@ App drivers represent apps, if the app is not able to register itself. Currently
 
 ### CS3org WOPI server app driver
 
-The CS3org WOPI server app driver is included in oCIS by default. It needs at least one WOPI compliant app (eg. Collabora, OnlyOffice or Microsoft Online Online Server) or a CS3org WOPI bridge supported app (CodiMD or Etherpad) and the CS3org WOPI server.
+The CS3org WOPI server app driver is included in oCIS by default. It needs at least one WOPI compliant app (e.g. Collabora, OnlyOffice or Microsoft Online Online Server) or a CS3org WOPI bridge supported app (CodiMD or Etherpad) and the CS3org WOPI server.
 
 Here is a closer look at the configuration of the actual app provider in a docker-compose example (see also [full example](https://github.com/owncloud/ocis/blob/master/deployments/examples/ocis_wopi/docker-compose.yml)):
 
diff --git a/docs/extensions/storage/proposedchanges.md b/docs/extensions/storage/proposedchanges.md
index c306a4005bb..9d43b887def 100644
--- a/docs/extensions/storage/proposedchanges.md
+++ b/docs/extensions/storage/proposedchanges.md
@@ -19,7 +19,7 @@ Currently, when a user accepts a share, a cs3 reference is created in the users
 
 Furthermore, the *gateway* treats `/home/shares` different than any other path: it will stat all children and calculate an etag to allow clients to discover changes in accepted shares. This requires the storage provider to cooperate and provide this special `/shares` folder in the root of a users home when it is accessed as a home storage. That is the origin of the `enable_home` config flag that needs to be implemented for every storage driver.
 
-In order to have a single source of truth we need to make the *share manager* aware of the mount point. We can then move all the logic that aggregates the etag in the share folder to a dedicated *shares storage provider* that is using the *share manager* for persistence. The *shares storage provider* would provide a `/shares` namespace outside of `/home` that lists all accepted shares for the current user. As a result the storage drivers no longer need to have a `enable_home` flag that jails users into their home. The `/home/shares` folder would move outside of the `/home`. In fact `/home` will no longer be needed, because the home folder concept can be implemented as a space: `CreateHome` would create a `personal` space on the. 
+In order to have a single source of truth we need to make the *share manager* aware of the mount point. We can then move all the logic that aggregates the etag in the share folder to a dedicated *shares storage provider* that is using the *share manager* for persistence. The *shares storage provider* would provide a `/shares` namespace outside of `/home` that lists all accepted shares for the current user. As a result the storage drivers no longer need to have a `enable_home` flag that jails users into their home. The `/home/shares` folder would move outside of the `/home`. In fact `/home` will no longer be needed, because the home folder concept can be implemented as a space: `CreateHome` would create a `personal` space on the.
 
 Work on this is done in https://github.com/cs3org/reva/pull/2023
 
@@ -39,9 +39,9 @@ Work is done in https://github.com/cs3org/reva/pull/1866
 
 ## URL escaped string representation of a CS3 reference
 
-For the spaces concept we introduced the `/dav/spaces/` endpoint. It encodes a cs3 *reference* in a URL compatible way. 
+For the spaces concept we introduced the `/dav/spaces/` endpoint. It encodes a cs3 *reference* in a URL compatible way.
 1. We can separate the path using a `/`: `/dav/spaces/<spaceid>/<path>`
-2. The `spaceid` currently is a cs3 resourceid, consisting of `<storageid>` and `<opaqueid>`. Since the opaqueid might contain `/` eg. for the local driver we have to urlencode the spaceid.
+2. The `spaceid` currently is a cs3 resourceid, consisting of `<storageid>` and `<opaqueid>`. Since the opaqueid might contain `/` e.g. for the local driver we have to urlencode the spaceid.
 
 To access resources by id we need to make the `/dav/meta/<resourceid>` able to list directories... Otherwise id based navigation first has to look up the path. Or we use the libregraph api for id based navigation.
 
@@ -52,8 +52,8 @@ A *reference* is a logical concept. It identifies a [*resource*]({{< ref "#resou
 While all components are optional, only three cases are used:
 | format | example | description |
 |-|-|-|
-| `!:<absolute_path>` | `!:/absolute/path/to/file.ext` | absolute path | 
-| `<storage_space>!:<relative_path>` | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!:path/to/file.ext` | path relative to the root of the storage space | 
+| `!:<absolute_path>` | `!:/absolute/path/to/file.ext` | absolute path |
+| `<storage_space>!:<relative_path>` | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!:path/to/file.ext` | path relative to the root of the storage space |
 | `<storage_space>!<root>:<relative_path>` | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!c3cf23bb-8f47-4719-a150-1d25a1f6fb56:to/file.ext` | path relative to the specified node in the storage space, used to reference resources without disclosing parent paths |
 
 `<storage_space>` should be a UUID to prevent references from breaking when a *user* or [*storage space*]({{< ref "#storage-spaces" >}}) gets renamed. But it can also be derived from a migration of an oc10 instance by concatenating an instance identifier and the numeric storage id from oc10, e.g. `oc10-instance-a$1234`.
@@ -81,8 +81,8 @@ The `:`, `!` and `$` are chosen from the set of [RFC3986 sub delimiters](https:/
 | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!56f7ceca-e7f8-4530-9a7a-fe4b7ec8089a:` | node id in the given storage space, `:` must be present |
 | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62` | root of the storage space, all delimiters omitted, can be distinguished by the `/` |
 
-## space providers 
-When looking up an id based resource the reference must use a logical space id, not a CS3 resource id. Otherwise id based requests, which only have a resourceid consisting of a storage id and a node id cannot be routed to the correct storage provider if the storage has moved from one storage provider to another. 
+## space providers
+When looking up an id based resource the reference must use a logical space id, not a CS3 resource id. Otherwise id based requests, which only have a resourceid consisting of a storage id and a node id cannot be routed to the correct storage provider if the storage has moved from one storage provider to another.
 
 if the registry routes based on the storageid AND the nodeid it has to keep a cache of all nodeids in order to route all requests for a storage space (which consists of storage it + nodeid) to the correct storage provider. the correct resourceid for a node in a storage space would be `<storageid>$<rootnodeid>!<nodeid>`. The `<storageid>$<rootnodeid>` part allow the storage registry to route all id based requests to the correct storage provider. This becomes relevant when the storage space was moved from one storage provider to another. The storage space id remains the same, but the internal address and port change.
 
@@ -107,11 +107,11 @@ The TUS upload can take metadata, for PUT we might need a header.
 
 ### Space id vs resource id vs storage id
 
-We have `/dav/meta/<fileid>` where the `fileid` is a string that was returned by a PROPFIND or by the `/graph/v1.0/me/drives/` endpoint? That returns a space id and the root drive item which has an `id` 
+We have `/dav/meta/<fileid>` where the `fileid` is a string that was returned by a PROPFIND or by the `/graph/v1.0/me/drives/` endpoint? That returns a space id and the root drive item which has an `id`
 
 Does that `id` have a specific format? We currently concatenate as `<storageid>!<nodeid>`.
 
-A request against `/dav/meta/fileid` will use the reva storage registry to look up a path. 
+A request against `/dav/meta/fileid` will use the reva storage registry to look up a path.
 
 What if the storage space is moved to another storage provider. This happens during a migration:
 
diff --git a/docs/extensions/storage/users.md b/docs/extensions/storage/users.md
index a1e6e0180c6..14428712506 100644
--- a/docs/extensions/storage/users.md
+++ b/docs/extensions/storage/users.md
@@ -7,14 +7,14 @@ geekdocEditPath: edit/master/docs/extensions/storage
 geekdocFilePath: users.md
 ---
 
-TODO add this to the storage overview? or is this a different part? That should be started as a separate service ? And documented elsewhere, eg. in the accounts?
+TODO add this to the storage overview? or is this a different part? That should be started as a separate service ? And documented elsewhere, e.g. in the accounts?
 
 ### User and Group provisioning
 
 In oc10 users are identified by a username, which cannot change, because it is used as a foreign key in several tables. For oCIS we are internally identifying users by a UUID, while using the username in the WebDAV and OCS APIs for backwards compatability. To distinguish this in the URLs we are using `<username>` instead of `<userid>`. You may have encountered `<user_layout>`, which refers to a template that can be configured to build several path segments by filling in user properties, e.g. the first  character of the username (`{{substr 0 1 .Username}}/{{.Username}}`), the identity provider (`{{.Id.Idp}}/{{.Username}}`) or the email (`{{.Mail}}`)
 
 {{< hint warning >}}
-Make no mistake, the [OCS Provisioning API](https://doc.owncloud.com/server/developer_manual/core/apis/provisioning-api.html) uses `userid` while it actually is the username, because it is what you use to login. 
+Make no mistake, the [OCS Provisioning API](https://doc.owncloud.com/server/developer_manual/core/apis/provisioning-api.html) uses `userid` while it actually is the username, because it is what you use to login.
 {{< /hint >}}
 
 We are currently working on adding [user management through the CS3 API](https://github.com/owncloud/ocis/pull/1930) to handle user and group provisioning (and deprovisioning).
diff --git a/docs/ocis/_index.md b/docs/ocis/_index.md
index 73c3bcc15dc..87d7407d462 100644
--- a/docs/ocis/_index.md
+++ b/docs/ocis/_index.md
@@ -13,9 +13,9 @@ geekdocFilePath: _index.md
 Welcome to oCIS, the modern file-sync and share platform, which is based on our knowledge and experience with the PHP based [ownCloud server](https://owncloud.com/#server).
 
 ### The idea of federated storage
-To creata a truly federated storage architecture oCIS breaks down the old ownCloud 10 user specific namespace, which is assembled on the server side, and makes the individual parts accessible to clients as storage spaces and storage space registries.
+To create a truly federated storage architecture oCIS breaks down the old ownCloud 10 user specific namespace, which is assembled on the server side, and makes the individual parts accessible to clients as storage spaces and storage space registries.
 
-The below diagram shows the core conceps that are the foundation for the new architecture:
+The below diagram shows the core concepts that are the foundation for the new architecture:
 - End user devices can fetch the list of *storage spaces* a user has access to, by querying one or multiple *storage space registries*. The list contains a unique endpoint for every *storage space*.
 - [*Storage space registries*]({{< ref "../extensions/storage/terminology#storage-space-registries" >}}) manage the list of storage spaces a user has access to. They may subscribe to *storage spaces* in order to receive notifications about changes on behalf of an end users mobile or desktop client.
 - [*Storage spaces*]({{< ref "../extensions/storage/terminology#storage-spaces" >}}) represent a collection of files and folders. A users personal files are contained in a *storage space*, a group or project drive is a *storage space*, and even incoming shares are treated and implemented as *storage spaces*. Each with properties like owners, permissions, quota and type.
@@ -29,9 +29,9 @@ To share something with Marie, Einstein would open `https://cloud.zurich.test`.
 
 After locating a folder that he wants to share with Marie he enters her email `marie@paris.test` in the sharing dialog to grant her the editor role. This, in effect, creates a new *storage space* that is registered with the *storage space registry* at `https://cloud.zurich.test`.
 
-Einstein copies the URL in the browser (or an email with the same URL is sent automatically, or the storage registries use a backchannel mechanism). It contains the most specific `storage space id` and a path relative to it: `https://cloud.zurich.test/#/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path`.
+Einstein copies the URL in the browser (or an email with the same URL is sent automatically, or the storage registries use a back-channel mechanism). It contains the most specific `storage space id` and a path relative to it: `https://cloud.zurich.test/#/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path`.
 
-When Marie enters that URL she will be presented with a login form on the `https://cloud.zurich.test` instance, because the share was created on that domain. If `https://cloud.zurich.test` trusts her OpenID Connect identity provider `https://idp.paris.test` she can log in. This time, the *storage space registry* discovery will come up with `https://cloud.paris.test` though. Since that registry is different than the registry tied to `https://cloud.zurich.test` oCIS web can look up the *storage space* `716199a6-00c0-4fec-93d2-7e00150b1c84` and register the WebDAV URL `https://cloud.zurich.test/dav/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path` in Maries *storage space registry* at `https://cloud.paris.test`. When she accepts that share her clients will be able to sync the new *storage space* at `https://cloud.zurich.test`.
+When Marie enters that URL she will be presented with a login form on the `https://cloud.zurich.test` instance, because the share was created on that domain. If `https://cloud.zurich.test` trusts her OpenID Connect identity provider `https://idp.paris.test` she can log in. This time, the *storage space registry* discovery will come up with `https://cloud.paris.test` though. Since that registry is different than the registry tied to `https://cloud.zurich.test` oCIS web can look up the *storage space* `716199a6-00c0-4fec-93d2-7e00150b1c84` and register the WebDAV URL `https://cloud.zurich.test/dav/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path` in Marie's *storage space registry* at `https://cloud.paris.test`. When she accepts that share her clients will be able to sync the new *storage space* at `https://cloud.zurich.test`.
 
 ### oCIS microservice runtime
 
@@ -48,13 +48,13 @@ oCIS runtime to the individual extensions.
 
 While the [go-micro](https://go-micro.dev/) framework provides abstractions as well as implementations for the different components in a microservice architecture, it uses a more developer focused runtime philosophy: It is used to download services from a repo, compile them on the fly and start them as individual processes. For oCIS we decided to use a more admin friendly runtime: You can download a single binary and start the contained oCIS extensions with a single `bin/ocis server`. This also makes packaging easier.
 
-We use [ocis-pkg](https://github.com/owncloud/ocis/tree/master/ocis-pkg) to configure the default implementations for the go-micro [grpc server](https://github.com/asim/go-micro/tree/v3.5.0/plugins/server/grpc), [client](https://github.com/asim/go-micro/tree/v3.5.0/plugins/client/grpc) and [mdns registry](https://github.com/asim/go-micro/blob/v3.5.0/registry/mdns_registry.go), swapping them out as needed, eg. to use the [kubernetes registry plugin](https://github.com/asim/go-micro/tree/v3.5.0/plugins/registry/kubernetes).
+We use [ocis-pkg](https://github.com/owncloud/ocis/tree/master/ocis-pkg) to configure the default implementations for the go-micro [grpc server](https://github.com/asim/go-micro/tree/v3.5.0/plugins/server/grpc), [client](https://github.com/asim/go-micro/tree/v3.5.0/plugins/client/grpc) and [mdns registry](https://github.com/asim/go-micro/blob/v3.5.0/registry/mdns_registry.go), swapping them out as needed, e.g. to use the [kubernetes registry plugin](https://github.com/asim/go-micro/tree/v3.5.0/plugins/registry/kubernetes).
 
 ### REVA
-A lot of embedded services in oCIS are built upon the [REVA](https://reva.link/) runtime. We decided to bundle some of the [CS3 services](https://github.com/cs3org/cs3apis) to logically group them. A [home storage provider](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L93-L108), which is dealing with [metadata](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ProviderAPI), and the corresponding [data provider](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L109-L123), which is dealing with [up and download](https://cs3org.github.io/cs3apis/#cs3.gateway.v1beta1.FileUploadProtocol), are one example. The [frontend](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go) with the [oc flavoured webdav](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L132-L138), [ocs handlers](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L139-L148) and a [datagateway](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L126-L131) are another.
+A lot of embedded services in oCIS are built upon the [REVA](https://reva.link/) runtime. We decided to bundle some of the [CS3 services](https://github.com/cs3org/cs3apis) to logically group them. A [home storage provider](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L93-L108), which is dealing with [metadata](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ProviderAPI), and the corresponding [data provider](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L109-L123), which is dealing with [up and download](https://cs3org.github.io/cs3apis/#cs3.gateway.v1beta1.FileUploadProtocol), are one example. The [frontend](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go) with the [oc flavoured webdav](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L132-L138), [ocs handlers](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L139-L148) and a [data-gateway](https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L126-L131) are another.
 
 ### Protocol driven development
-Interacting with oCIS involves a multitude af APIs. The server and all clients rely on [OpenID Connect](https://openid.net/connect/) for authentication. The [embedded LibreGraph Connect](https://github.com/owncloud/ocis/tree/master/idp) can be replaced with any other OpenID Connect Identity Provider. Clients use the [WebDAV](http://webdav.org/) based [oc sync protocol](https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md) to manage files and folders, [ocs to manage shares](https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html) and [TUS](https://tus.io/protocols/resumable-upload.html) to upload files in a resumable way. On the server side [REVA](https://reva.link/) is the reference implementation of the [CS3 apis](https://github.com/cs3org/cs3apis) which is defined using [protobuf](https://developers.google.com/protocol-buffers/). By embedding [glauth](https://github.com/glauth/glauth/), oCIS provides a read-only [LDAP](https://tools.ietf.org/html/rfc2849) interface to make accounts, including guests available to firewalls and other systems. In the future, we are looking into [the Microsoft Graph API](https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0), which is based on [odata](http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html), as a well defined REST/JSON dialect for the existing endpoints.
+Interacting with oCIS involves a multitude af APIs. The server and all clients rely on [OpenID Connect](https://openid.net/connect/) for authentication. The [embedded LibreGraph Connect](https://github.com/owncloud/ocis/tree/master/idp) can be replaced with any other OpenID Connect Identity Provider. Clients use the [WebDAV](http://webdav.org/) based [oc sync protocol](https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md) to manage files and folders, [ocs to manage shares](https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html) and [TUS](https://tus.io/protocols/resumable-upload.html) to upload files in a resumable way. On the server side [REVA](https://reva.link/) is the reference implementation of the [CS3 apis](https://github.com/cs3org/cs3apis) which is defined using [protobuf](https://developers.google.com/protocol-buffers/). By embedding [glauth](https://github.com/glauth/glauth/), oCIS provides a read-only [LDAP](https://tools.ietf.org/html/rfc2849) interface to make accounts, including guests available to firewalls and other systems. In the future, we are looking into [the Microsoft Graph API](https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0), which is based on [odata](http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html), as a well-defined REST/JSON dialect for the existing endpoints.
 
 ### Acceptance test suite
 We run a huge [test suite](https://github.com/owncloud/core/tree/master/tests), which originated in ownCloud 10 and continues to grow. A detailed description can be found in the developer docs for [testing]({{< ref "development/testing" >}}).
diff --git a/docs/ocis/adr/0001-introduce-accounts-service.md b/docs/ocis/adr/0001-introduce-accounts-service.md
index aab625c9a4f..e9fae408dae 100644
--- a/docs/ocis/adr/0001-introduce-accounts-service.md
+++ b/docs/ocis/adr/0001-introduce-accounts-service.md
@@ -36,7 +36,7 @@ Chosen option: "GLAuth wraps accounts service", because we need write access to
 
 ### Positive Consequences
 
-* We can build a self contained user management in the accounts service and can adjust it to our requirements.
+* We can build a self-contained user management in the accounts service and can adjust it to our requirements.
 * We do not rely on an LDAP server which would only be possible by implementing write support in the LDAP libraries used by GLAuth (hard to estimate effort, when will that be merged upstream).
 
 ### Negative Consequences
diff --git a/docs/ocis/adr/0004-support-hot-migration.md b/docs/ocis/adr/0004-support-hot-migration.md
index e1077ad09c1..058528853c4 100644
--- a/docs/ocis/adr/0004-support-hot-migration.md
+++ b/docs/ocis/adr/0004-support-hot-migration.md
@@ -19,7 +19,7 @@ Migration is one of the most important topics of the oCIS story. We need to prov
 
 ## Decision Drivers
 
-- Do not lose file blob or meta data.
+- Do not lose file blob or metadata.
   - To prevent a sync surge from clients the etag for files should be migrated.
   - To prevent internal links from breaking or pointing to wrong files the file id of existing files needs to be migrated.
   - To prevent data loss trash and version blobs should be migrated.
@@ -27,7 +27,7 @@ Migration is one of the most important topics of the oCIS story. We need to prov
   - To prevent internal shares the share type, permissions and expiry needs to be migrated.
   - To prevent public links from breaking the url token, permissions, expiry and password needs to be migrated.
   - *What about federated shares?*
-  - *What about additional share permissions, eg. comment on office files?*
+  - *What about additional share permissions, e.g. comment on office files?*
 - Legacy clients need to keep working
   - To keep existing clients working the `remote.php/webdav` and `dav/files/<username>` webdav endpoints as well as the ocs API need to be available.
 - *What about [app passwords/tokens](https://doc.owncloud.com/server/user_manual/personal_settings/security.html#app-passwords-tokens)?*
@@ -55,7 +55,7 @@ Chosen option: "\[option 1\]", because \[justification. e.g., only option, which
 
 ### Cold Migration
 
-The migration happens while the service is offline. File metadata, blobs and share data is exported from ownCloud 10 and imported in oCIS. This can happen user by user, where every user export would contain the file blobs, their metadata, trash, versions, shares and all metadata that belongs to the users storage. To prevent group shares from breaking, users in the same groups must be migrated in batch. Depending on the actual group shares in an instance this may effectively require a complete migration in a single batch. 
+The migration happens while the service is offline. File metadata, blobs and share data is exported from ownCloud 10 and imported in oCIS. This can happen user by user, where every user export would contain the file blobs, their metadata, trash, versions, shares and all metadata that belongs to the users storage. To prevent group shares from breaking, users in the same groups must be migrated in batch. Depending on the actual group shares in an instance this may effectively require a complete migration in a single batch.
 
 - Good, because oCIS can be tested in a staging system without writing to the production system.
 - Good, because file layout on disk can be changed to support new storage driver capabilities.
@@ -76,5 +76,5 @@ The migration happens in subsequent stages while the service is online.
 
 ## Links
 
-        
-- [Clarify responsibilities of share providers and storage providers · Issue #1377 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/1377) because the share manager for oCIS should store share information on the storage system. And [storageprovider should persist share creator · Issue #93 · cs3org/cs3apis (github.com)](https://github.com/cs3org/cs3apis/issues/93) finally: [eos: store share id in inherited xattr · Issue #543 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/543)
+
+- [Clarify responsibilities of share providers and storage providers · Issue #1377 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/1377) because the share manager for oCIS should store share information on the storage system. And [storage provider should persist share creator · Issue #93 · cs3org/cs3apis (github.com)](https://github.com/cs3org/cs3apis/issues/93) finally: [eos: store share id in inherited xattr · Issue #543 · cs3org/reva (github.com)](https://github.com/cs3org/reva/issues/543)
diff --git a/docs/ocis/adr/0005-cs3-api-account-management.md b/docs/ocis/adr/0005-cs3-api-account-management.md
index 6a03be84d13..b37cc3fe740 100644
--- a/docs/ocis/adr/0005-cs3-api-account-management.md
+++ b/docs/ocis/adr/0005-cs3-api-account-management.md
@@ -155,7 +155,7 @@ Creating an account using the first option looks currently is implemented in ven
 └──────────────────────────────────────────────────┘
 ```
 
-As explained before, during this flow no Reva middlewares are ran. Creating an account will only use the embedded accounts js file alongside a minted jwt token (by the oCIS proxy) to communicate with the accounts service.
+As explained before, during this flow no Reva middlewares are run. Creating an account will only use the embedded accounts js file alongside a minted jwt token (by the oCIS proxy) to communicate with the accounts service.
 
 ### Add account management to the CS3 API
 
diff --git a/docs/ocis/adr/0007-api-for-spaces.md b/docs/ocis/adr/0007-api-for-spaces.md
index 7d4d42f4a5d..e86dd0a1fb8 100644
--- a/docs/ocis/adr/0007-api-for-spaces.md
+++ b/docs/ocis/adr/0007-api-for-spaces.md
@@ -151,6 +151,6 @@ Meaningful fields of the root element in the context of the Open Graph API:
 
 ### Open Topics
 
-- What are the WebDAV pathes for Trashbin, Versions
+- What are the WebDAV paths for Trashbin, Versions
     + option: additional entries in the reply struct
 - The identitySet object used for "owner" and "coowner" require to implement the [https://docs.microsoft.com/de-de/graph/api/resources/identityset?view=graph-rest-1.0](IdentitySet) JSON object, which contains information that seems to be of limited benefit for oCIS. An alternative would be to implement a simpler identity object for oCIS and use that.
diff --git a/docs/ocis/adr/0009-extension-template.md b/docs/ocis/adr/0009-extension-template.md
index 05d1cc922b3..7ac7ead3d10 100644
--- a/docs/ocis/adr/0009-extension-template.md
+++ b/docs/ocis/adr/0009-extension-template.md
@@ -66,6 +66,6 @@ Create a git repository with an extension containing the boilerplate code.
 We have the ocis-hello repository which acts as an example extension containing a grpc and http service and a web UI. It also demonstrates the usage of the settings service.
 
 * Good, because it contains a bit more code than just the plain boilerplate
-* Good, because the integration into oCIS is already tested for the Hello extension (eg. with Proxy and Settings). This will ensure, that the example extension is up to date.
+* Good, because the integration into oCIS is already tested for the Hello extension (e.g. with Proxy and Settings). This will ensure, that the example extension is up-to-date.
 * Bad, because if you don't require all features you have to delete stuff
 
diff --git a/docs/ocis/adr/0010-policy-enforcement.md b/docs/ocis/adr/0010-policy-enforcement.md
index d49794718ca..31f2e0f67fe 100644
--- a/docs/ocis/adr/0010-policy-enforcement.md
+++ b/docs/ocis/adr/0010-policy-enforcement.md
@@ -49,7 +49,7 @@ Chosen option: option 2; Use third party libraries such as Open Policy Agent (a
 
 ## Chosen option approach
 
-Make use of [overloading Open Policy Agent's input](https://www.openpolicyagent.org/docs/latest/external-data/#option-2-overload-input) along with an external storage source (instead of an OPA service) in conjunction with go-micro's gRPC client wrappers (a.k.a middlewares) to leverage policy rules evaluation.
+Make use of [overloading Open Policy Agent's input](https://www.openpolicyagent.org/docs/latest/external-data/#option-2-overload-input) along with an external storage source (instead of an OPA service) in conjunction with go-micro's gRPC client wrappers (a.k.a. middlewares) to leverage policy rules evaluation.
 
 ### Terminology
 
@@ -68,7 +68,7 @@ New terms are defined to refer to new mental models:
 
 However, for this to be usable it needs state. The Rego engine works with input and data, where data is essentially a database the input is tried against, in order to expand this poc to include functionality such as counters (i.e: give access to the thumbnails only to 50 users) we need an external storage, and consequentially, Rego needs to have an option to load data from an external storage. There is an entire chapter in the documentation regarding external data: https://www.openpolicyagent.org/docs/latest/external-data/. The most "natural" option (option 5) states:
 
-> OPA includes functionality for reaching out to external servers during evaluation. This functionality handles those cases where there is too much data to synchronize into OPA, JWTs are ineffective, or policy requires information that must be as up to date as possible.
+> OPA includes functionality for reaching out to external servers during evaluation. This functionality handles those cases where there is too much data to synchronize into OPA, JWTs are ineffective, or policy requires information that must be as up-to-date as possible.
 
 This is a natural option because it requires service-to-service communication, and by definition using microservices it should come "natural to us". Another approach is using JWT (which we already use) to encode the necessary data into the JWT and handing it over to rego as "data". The issue with this approach is that depending on the features of the licenses the JWT might grow and be filled with noise and redundancy (this is, unless a new token is issued for licensing purposes).
 
diff --git a/docs/ocis/adr/0011-global-url-format.md b/docs/ocis/adr/0011-global-url-format.md
index ce46f322367..4d4fe1b2808 100644
--- a/docs/ocis/adr/0011-global-url-format.md
+++ b/docs/ocis/adr/0011-global-url-format.md
@@ -26,7 +26,7 @@ When the URL contains a `fileid` parameter the server will look up the correspon
 GET https://demo.owncloud.com/apps/files/?dir=/path/to/resource
 ```
 
-The `dir` parameter is then used to make a WebDAV request against the `/dav/files` endpoint of the currently logged in user:
+The `dir` parameter is then used to make a WebDAV request against the `/dav/files` endpoint of the currently logged-in user:
 
 ```
 PROPFIND https://demo.owncloud.com/remote.php/dav/files/demo/path/to/resource
@@ -42,7 +42,7 @@ https://demo.owncloud.com/#/files/list/all/path/to/resource
 
 Currently, there is no `fileid` like parameter in the browser URL, making bookmarks of it fragile (they break when a bookmarked folder is renamed).
 
-The oCIS web UI just takes the path and uses the `/webdav` endpoint of the currently logged in user:
+The oCIS web UI just takes the path and uses the `/webdav` endpoint of the currently logged-in user:
 
 ```
 PROPFIND https://demo.owncloud.com/remote.php/webdav/path/to/resource
@@ -78,7 +78,7 @@ This ADR is limited to the scope of "how will a web client deal with the browser
 
 
 {{< hint >}}
-@jfd: The graph api returns a `path` in the `parentReference`, which is part of the `root` in a `drive` resource. But it contains a value in the namespace of the `graph` endpoint, eg.: `/drive/root:/Bilder` for the `/Bilder` folder in the root of the currently logged in users personal drive/space. Which is again relative to the drive. To give the clients a way to determine the mount point we need to add a new `mountpath/point/alias` property.
+@jfd: The graph api returns a `path` in the `parentReference`, which is part of the `root` in a `drive` resource. But it contains a value in the namespace of the `graph` endpoint, e.g.: `/drive/root:/Bilder` for the `/Bilder` folder in the root of the currently logged-in users personal drive/space. Which is again relative to the drive. To give the clients a way to determine the mount point we need to add a new `mountpath/point/alias` property.
 {{< /hint >}}
 
 ## Decision Drivers
@@ -130,7 +130,7 @@ It contains a path and a `fileid` (which takes precedence).
 * Bad, because URLs still contain a long prefix `(/index.php)/apps/files`
 * Bad, because the `fileid` needs to be accompanied by a `storageid` to allow efficient routing in ocis
 * Bad, because if not configured properly an additional `/index.php` prefixes the route
-* Bad, because powerusers cannot navigate by updating only the path in the URL, as the `fileid` takes precedence. They have to delete the `fileid` to navigate
+* Bad, because power users cannot navigate by updating only the path in the URL, as the `fileid` takes precedence. They have to delete the `fileid` to navigate
 
 ### ID based URLs
 
@@ -160,7 +160,7 @@ There is a customized ownCloud instance that uses path only based URLs:
 | `https://demo.owncloud.com/apps/files/?dir=/path/to/resource&` | sub folder `/path/to/resource` |
 
 * Good, because the URLs reveal the full path context to users
-* Good, because powerusers can navigate by updating the path in the url
+* Good, because power users can navigate by updating the path in the url
 * Bad, because the web UI needs to look up the space id in a registry to build an API request for the `/dav/space` endpoint
 * Bad, because the bookmarks break when someone renames a folder in the path
 * Bad, because there is no id that can be used as a fallback lookup mechanism
@@ -185,7 +185,7 @@ There is a customized ownCloud instance that uses path only based URLs:
 * Good, because the web UI does not need to look up the space id in a registry to build an API request for the `/dav/space` endpoint
 * Good, because the URLs reveal a relevant path context to users
 * Good, because everything after the `#` is not sent to the server, building the webdav request to list the folder is offloaded to the clients
-* Good, because powerusers can navigate by updating the path in the url
+* Good, because power users can navigate by updating the path in the url
 * Bad, because the current ids are uuid based, leading to very long URLs where the path component nearly vanishes between two very long strings
 * Bad, because the `#` in the URL is just a technical requirement
 * Bad, because ocis web requires a `/#/files/s` at the root of the route to distinguish the files app from other apps
@@ -266,14 +266,14 @@ In order to be able to copy and paste URLs all resources must be uniquely identi
 * An url shortener can create urls like `/s/<token>` which could be used as a stable link to a resource.
 * Links for anonymous users will resolve to `/public/<token>`
 
-The alias namespace hierarchy and depth can be pre determined by the admin. Even if aliases change the `id` parameter prevents bookmarks from breaking. A user can decide to build a different hierarchy by using his own registry.
+The alias namespace hierarchy and depth can be pre-determined by the admin. Even if aliases change the `id` parameter prevents bookmarks from breaking. A user can decide to build a different hierarchy by using his own registry.
 
-What about shares? Similar to `/home` it must reflect the user: `/shares/einstein` would list all shares *by* einstein for the currently logged in user. The ui needs to apply the same URL rewriting as for space based URLs: when navigating into a share the URL has to switch from `/personal/einstein/relative/path/to/shared/resource` to `/shares/einstein/<unique and potentially namespaced alias for shared resource>`. When more than one `resource` was shared a name collision would occur. To prevent this we can use ids `/shares/einstein/id/<resource_id` or namespaced aliases `/shares/einstein/files/alias`. Similar to the `/trash` prefix we could treat `/shares` as a filter for the shared resources a user has access to, but that would disclose unshared path segments in personal spaces. We could make that a feature and let users create an alias for a shared resource, similar as for public links. Then they can decide if they want to disclose the full path in their personal space (or another workspace) or if they want to use an alias which is then accessed at `/shares/einstein/<alias>`. As a default we could take the alias at creation time from the filename. That way two shares to a resource with the same name, eg.: `/personal/einstein/project AAA/foo` and `/personal/einstein/project BBB/foo` would lead to `/shares/einstein/foo` (a CS3 internal reference to `/personal/einstein/project AAA/foo`) and `/shares/einstein/foo (2)` (a CS3 internal reference to `/personal/einstein/project BBB/foo`). `foo (2)` would keep its name even when `foo` is deleted or renamed. Well an id as the alias might be better then, because users might rename these aliases, which would break URLs if they have been bookmarked. In any case this would make end user more aware of what they share AND it would allow them to choose an arbitrary context for the links they want to send out: personal internal share URLs.
+What about shares? Similar to `/home` it must reflect the user: `/shares/einstein` would list all shares *by* einstein for the currently logged-in user. The ui needs to apply the same URL rewriting as for space based URLs: when navigating into a share the URL has to switch from `/personal/einstein/relative/path/to/shared/resource` to `/shares/einstein/<unique and potentially namespaced alias for shared resource>`. When more than one `resource` was shared a name collision would occur. To prevent this we can use ids `/shares/einstein/id/<resource_id` or namespaced aliases `/shares/einstein/files/alias`. Similar to the `/trash` prefix we could treat `/shares` as a filter for the shared resources a user has access to, but that would disclose unshared path segments in personal spaces. We could make that a feature and let users create an alias for a shared resource, similar as for public links. Then they can decide if they want to disclose the full path in their personal space (or another workspace) or if they want to use an alias which is then accessed at `/shares/einstein/<alias>`. As a default we could take the alias at creation time from the filename. That way two shares to a resource with the same name, e.g.: `/personal/einstein/project AAA/foo` and `/personal/einstein/project BBB/foo` would lead to `/shares/einstein/foo` (a CS3 internal reference to `/personal/einstein/project AAA/foo`) and `/shares/einstein/foo (2)` (a CS3 internal reference to `/personal/einstein/project BBB/foo`). `foo (2)` would keep its name even when `foo` is deleted or renamed. Well an id as the alias might be better then, because users might rename these aliases, which would break URLs if they have been bookmarked. In any case this would make end user more aware of what they share AND it would allow them to choose an arbitrary context for the links they want to send out: personal internal share URLs.
 
 With these different namespaces the `/files` part in the URL becomes obsolete, because the files application can be registered for multiple namespaces: `/personal`, `/workspaces`, `/shares`, `/trash` ...
 
 * Good, because it contains a global path
-* Good, because spaces with namespaced aliases can by bookmarked and copied into mails or chat without disclosing unshared path segments, as the space is supposed to be shared
+* Good, because spaces with namespaced aliases can be bookmarked and copied into mails or chat without disclosing unshared path segments, as the space is supposed to be shared
 * Good, because the UI can detect broken paths and notify the user to update his bookmark if the resource could be found by `id`
 * Good, because the `/files` part might only be required for `id` only based lookup to let the web ui know which app is responsible for the route
 * Good, because it turns shares into deliberately named spaces in `/shares/<owner>/<alias>`
@@ -297,7 +297,7 @@ When a file is selected the filename also becomes part of the URL so individual
 
 If navigation is id based we need to look up the path for the id so we can make a webdav request, or we need to implement the graph drives and driveItem resources.
 
-The URL  `https://<host>/files?id=<resource_id>̀` is sent to the server. It has to look up the correct path and redirect the request, including the the path. But that would make all bookmarks contain tha path again, even if paths were configured to not be part of the URL.
+The URL  `https://<host>/files?id=<resource_id>̀` is sent to the server. It has to look up the correct path and redirect the request, including the path. But that would make all bookmarks contain tha path again, even if paths were configured to not be part of the URL.
 
 The `/meta/<fileid>` webdav endpoint can be used to look up the path with property `meta-path-for-user`.
 
@@ -307,7 +307,7 @@ For now, we would use path based navigation with URLs like this:
 https://<host>/files</namespaced/alias></relative/path/to/resource>?id=<resource_id>
 ```
 
-This means that only the _resource path_ is part of the URL path. Any other parameter, eg. file `id`, `page` or sort order must be given as URL parameters.
+This means that only the _resource path_ is part of the URL path. Any other parameter, e.g. file `id`, `page` or sort order must be given as URL parameters.
 
 - [ ] To make lookup by id possible we need to implement the `/meta/<fileid>` endpoint so the sdk can use it to look up the path. We should not implement a redirect on the ocis server side because the same redirect logic would need to be added to oc10. Having it in ocis web is the right place.
 
@@ -316,5 +316,5 @@ This means that only the _resource path_ is part of the URL path. Any other para
 Public links would have the same format: `https://<host>/files?id=<resource_id>` The web UI has to detect if the user is logged in or not and adjust the ui accordingly.
 
 {{< hint warning >}}
-Since there is no difference between public and private files a logged in user cannot see the public version of a link unless he logs out.
+Since there is no difference between public and private files a logged-in user cannot see the public version of a link unless he logs out.
 {{< /hint >}}
diff --git a/docs/ocis/adr/0012-tracing.md b/docs/ocis/adr/0012-tracing.md
index 7fb7f06fca0..3c258badb0c 100644
--- a/docs/ocis/adr/0012-tracing.md
+++ b/docs/ocis/adr/0012-tracing.md
@@ -46,4 +46,4 @@ Chosen option: option 3; Migrate to OpenTelemetry. OpenCensus is deprecated, and
 - The unit that ultimately does the work will change the state of the span to error if any occurred.
 
 
-With this premises, this is by no means a fixed document and the more we learn about the usage of an instance the more context we can add to the traces.
+With these premises, this is by no means a fixed document and the more we learn about the usage of an instance the more context we can add to the traces.
diff --git a/docs/ocis/adr/0013-locking.md b/docs/ocis/adr/0013-locking.md
index 6785b2d2509..8da189d5dcc 100644
--- a/docs/ocis/adr/0013-locking.md
+++ b/docs/ocis/adr/0013-locking.md
@@ -44,15 +44,15 @@ The CS3org WOPI server creates a `.sys.wopilock.<filename>.` and `.~lock.<filena
 
 **File based locking is bad**, because:
 
-- lock files should be checked by all partys manipulating files (eg. the WebDAV api)
+- lock files should be checked by all parties manipulating files (e.g. the WebDAV api)
 - lock files can be deleted by everyone
 - you can not lock files in a file-only share (you need a folder share to create a lock file besides the original file)
 
-If we have file based locks, we can also sync them with eg. the Desktop Client.
+If we have file based locks, we can also sync them with e.g. the Desktop Client.
 
 **Syncing lock files is good**: because
 
-- native office applications can notice lock files by the WOPI server and vice versa (Libre Office also creates `.lock.<filename>#` files)
+- native office applications can notice lock files by the WOPI server and vice versa (LibreOffice also creates `.lock.<filename>#` files)
 
 **Syncing lock files is bad**, because:
 
@@ -70,7 +70,7 @@ We remove or disable the file based locking of the CS3org WOPI server.
 
 **No locking is bad**, because:
 
-- merging changes from different versions is a pain, since there is no way to calculate differences for most of the files (eg. docx or xlsx files)
+- merging changes from different versions is a pain, since there is no way to calculate differences for most of the files (e.g. docx or xlsx files)
 - no locking breaks the WOPI specs, as the CS3 WOPI server won't be capable to honor the WOPI Lock related operations
 
 ### CS3 API locking
@@ -78,7 +78,7 @@ We remove or disable the file based locking of the CS3org WOPI server.
 - Add CS3 API for resource (files, directories) locking, unlocking and checking locks
   - locking always with timeout
   - lock creation is a "create-if-not-exists" operation
-  - locks need to have arbitrary metadata (eg. the CS3 WOPI server is stateless by storing information on / in the locks)
+  - locks need to have arbitrary metadata (e.g. the CS3 WOPI server is stateless by storing information on / in the locks)
 - Implement WebDAV locking using the CS3 API
 - Implement Locking in storage drivers
 - Change CS3 WOPI server to use CS3 API locking mechanism
@@ -89,7 +89,7 @@ We remove or disable the file based locking of the CS3org WOPI server.
 - you can lock files on the actual storage (if the storage supports that -> storage driver dependent)
 - you can lock files in ownCloud 10 when using the ownCloudSQL storage driver in the migration deployment (but oC10 Collabora / OnlyOffice also need to implement locking, to fully leverage that)
 - clients can get the lock information via the api without ignoring / hiding lock file changes
-- clients can use the lock information to lock the file in their context (eg. via some file explorer integration)
+- clients can use the lock information to lock the file in their context (e.g. via some file explorer integration)
 
 **CS3 API locking is bad**, because:
 
diff --git a/docs/ocis/adr/0015-events.md b/docs/ocis/adr/0015-events.md
index 9c6ceb2e904..5358f47db38 100644
--- a/docs/ocis/adr/0015-events.md
+++ b/docs/ocis/adr/0015-events.md
@@ -19,7 +19,7 @@ To be able to implement simple, flexible and independent inter service communica
 
 ### Example: Email Notification
 
-A simple example is the notification feature for oCIS: Users should receive an email when another user shares a file with them. The information, that the file was shared should go out as an event from a storage provider or share manager, carrying the information which file was shared to which receiver. A potential notification service that sends out the email listens to these kind of events and sends the email out once on every received event of that specific type.
+A simple example is the notification feature for oCIS: Users should receive an email when another user shares a file with them. The information, that the file was shared should go out as an event from a storage provider or share manager, carrying the information which file was shared to which receiver. A potential notification service that sends out the email listens to these kinds of events and sends the email out once on every received event of that specific type.
 
 ## Decision Drivers
 
@@ -40,17 +40,17 @@ A simple example is the notification feature for oCIS: Users should receive an e
 
 Reva will get a messaging service that is available to all services within oCIS and Reva. It is considered as one of the mandatory services of the oCIS system. If the messaging backend is not running, neither Reva nor oCIS can be considered healthy and should shut down.
 
-All oCIS- and Reva-services can connect to the messaging bus and send so called events. The sender gets an immediate return if handing the event to the message bus was succesful or not.
+All oCIS- and Reva-services can connect to the messaging bus and send so-called events. The sender gets an immediate return if handing the event to the message bus was successful or not.
 
 The sender can not make any assumptions when the message is delivered to any receiving service. Depending on the QoS model (as proposed as alternatives in this ADR) it might even be not guaranteed that the event is delivered at all. Also, the sender can not know if zero, one or many services are listening to that event.
 
 #### Event Data
 
-Events are identified by their namespace and their respective name. The namespace is delimited by dots and starts with either "reva" or "ocis" or an future extension name. It is followed by the name of the sending service and an unique name of the event.
+Events are identified by their namespace and their respective name. The namespace is delimited by dots and starts with either "reva" or "ocis" or a future extension name. It is followed by the name of the sending service and an unique name of the event.
 
 Example: `ocis.ocdav.delete` - an event with that name sent out if an WebDAV DELETE request arrived in the oCDav service.
 
-An event can carry a payload which is encoded as json object. (See for example [NATS](https://docs.nats.io/using-nats/developer/sending/structure) ). There are no pre defined members in that object, it is fully up to the sender which data will be included in the payload. Receivers must be robust to deal with changes.
+An event can carry a payload which is encoded as json object. (See for example [NATS](https://docs.nats.io/using-nats/developer/sending/structure) ). There are no pre-defined members in that object, it is fully up to the sender which data will be included in the payload. Receivers must be robust to deal with changes.
 
 #### Quality of Service
 
@@ -82,7 +82,7 @@ Exactly as described above, but with a higher service level quality.
 
 #### Quality of Service
 
-Events are sent with "At least once" quality of service. That means the events will remain in the queue until they are received by all receivers. This puts more responsability on the event bus and adds state to the events. Given that the event queue can be considered the backbone of the system, it is required to be running.
+Events are sent with "At least once" quality of service. That means the events will remain in the queue until they are received by all receivers. This puts more responsibility on the event bus and adds state to the events. Given that the event queue can be considered the backbone of the system, it is required to be running.
 
 #### Pros
 
diff --git a/docs/ocis/adr/0017-allow-read-only-external-user-management.md b/docs/ocis/adr/0017-allow-read-only-external-user-management.md
index 879171b3705..9da53c9584e 100644
--- a/docs/ocis/adr/0017-allow-read-only-external-user-management.md
+++ b/docs/ocis/adr/0017-allow-read-only-external-user-management.md
@@ -16,7 +16,7 @@ geekdocFilePath: 0017-allow-read-only-external-user-management.md
 oCIS needs to be integrated with various external Authentication and Identity Management Systems.
 Usually oCIS will have no administrative access to such a system and we will not be allowed to
 reconfigure it to suit our needs (e.g. we will not be able to enhance the schema of an already existing
-LDAP Directory). In most of the cases our access will be read-only. 
+LDAP Directory). In most of the cases our access will be read-only.
 
 Sidenote: There is a difference between users, identities and accounts: A user may have multiple
 identities which he can authenticate with, e.g. his facebook, twitter, microsoft or google
@@ -27,8 +27,8 @@ provider to another.
 There are different cases where oCIS requires access to users:
 
 1. While we settled on using OpenID Connect (OIDC) as the authentication protocol for oCIS, we
-   we need to build a user object during authentication with at least an account UUID (to identify
-   the account) and the email or a name (for display purposes). 
+   need to build a user object during authentication with at least an account UUID (to identify
+   the account) and the email or a name (for display purposes).
 2. When searching for share recipients we need to be able to query existing users in the external
    identity management system
 3. When listing files we need to be able to look up a users display properties (username, email,
@@ -49,7 +49,7 @@ of stable identifier for users:
 * oCIS should be a single binary that can run out of the box without external dependencies like an
   LDAP server.
 * Time: we want to build a release candidate asap.
-* oCIS should be easy to integrate with standard external identity mangement systems
+* oCIS should be easy to integrate with standard external identity management systems
 
 ## Considered Options
 
@@ -73,7 +73,7 @@ to support both scenarios.
 
 ## Pros and Cons of the Options <!-- optional -->
 
-### External identity management system is read only and provides an interface to query users (e.g. Coporate Active Directy)
+### External identity management system is read only and provides an interface to query users (e.g. Corporate Active Directory)
 
 IdP sends sub & iss and mail or username claims, Identity Management System provides APIs (e.g.
 LDAP, SCIM, REST ...) to lookup additional user information. All oCIS services use the CS3 API to
@@ -82,20 +82,20 @@ the APIs provided by the IdM.
 
 * Good, because we can rely on the external identity management
 * Good, because ocis services only need to know about the CS3 user provider API, which acts as an
-  abstraction layer for different identitiy management systems
+  abstraction layer for different identity management systems
 * Good, because there is only a single source of truth (the external IdM) and we don't need to
   implement a synchronization mechanism to maintain an internal user database (we will likely need
   some form of caching though, see below)
-* Bad, because the identity managment needs to provide a stable, persistent, non-reassignable user
+* Bad, because the identity management needs to provide a stable, persistent, non-reassignable user
   identifier for an account, e.g. `owncloudUUID` or `ms-DS-ConsistencyGuid`
-* Bad, because we need to implment tools that can change the account id when it did change anyway
+* Bad, because we need to implement tools that can change the account id when it did change anyway
 * Bad, because without caching we will hammer the identity management system with lookup requests
 
 ### External identity management system is read only and does NOT provide an API to query users
 
 Idp sends sub & iss and mail or username claims. We need to provision an internal account mapping,
 creating a unique ID, upon the first login of a user to be able to look up user properties by account
-id. 
+id.
 
 * Good, because this has very little external requirements
 * Good, because we have accounts fully under our control
diff --git a/docs/ocis/adr/0019-file-search-index.md b/docs/ocis/adr/0019-file-search-index.md
index 870753d643c..2e6ecf52a50 100644
--- a/docs/ocis/adr/0019-file-search-index.md
+++ b/docs/ocis/adr/0019-file-search-index.md
@@ -29,7 +29,7 @@ Sharing adds more complexity because the index also needs to react to create, de
 * Be able to construct intelligent searches based on metadata
 * Allow the user to filter the search queries based on metadata
 * Basic File Search needs to be implemented out of the box without external dependencies
-* The Search Indexing Service should be replacable with more sophisticated technologies like Elasticsearch
+* The Search Indexing Service should be replaceable with more sophisticated technologies like Elasticsearch
 * Make use of the spaces architecture to shard search indexes by space
 * The Search Indexing Service needs to deal with multiple users accessing the same resources due to shares
 * The Search Service should be compatible with different search indexing technologies
diff --git a/docs/ocis/adr/0020-file-search-query-language.md b/docs/ocis/adr/0020-file-search-query-language.md
index b6d4dac2ce4..1317cdff3d9 100644
--- a/docs/ocis/adr/0020-file-search-query-language.md
+++ b/docs/ocis/adr/0020-file-search-query-language.md
@@ -13,18 +13,18 @@ geekdocFilePath: 0018-file-search-query-language.md
 
 ## Context and Problem Statement
 
-From the users perspective, the interface to search is just a single form field where the user enters one or more search terms. The minimum expectation is that the search returns file names and links to files that
+From the users perspective, the interface to search is just a single form field where the user enters one or more search terms. The minimum expectation is that the search returns file names and links to files that:
 
 * have a file name that contains at least one of the search terms
 * contain at least one of the search terms in the file contents
-* have meta data that is equal or contains one of the search terms
+* have metadata that is equal or contains one of the search terms
 
 ## Decision Drivers
 
 * The standard user should not be bothered by a query syntax
 * The power user should also be able to narrow his search with an efficient and flexible syntax
 * We need to consider different backend technologies which we need to access through an abstraction layer
-* Using different indexing systems should lead to a slightly different feature set whitout changing the syntax completely
+* Using different indexing systems should lead to a slightly different feature set without changing the syntax completely
 
 ## Considered Options
 
@@ -65,16 +65,16 @@ The Lucene Query Parser syntax supports advanced queries like term, phrase, wild
 * Good, because it is a well documented and powerful syntax
 * Good, because it is very close to the Elasticsearch and the Solr syntax which enhances compatibility
 * Bad, because there is no powerful and well tested query parser for golang available
-* Bad, because it adds complexity and fulfilling all the different query usecases can be an "uphill battle"
+* Bad, because it adds complexity and fulfilling all the different query use-cases can be an "uphill battle"
 
 ### Solr Query Language
 
-Solr is highly reliable, scalable and fault tolerant, providing distributed indexing, replication and load-balanced querying, automated failover and recovery, centralized configuration and more. Solr powers the search and navigation features of many of the world's largest internet sites.
+Solr is highly reliable, scalable and fault-tolerant, providing distributed indexing, replication and load-balanced querying, automated failover and recovery, centralized configuration and more. Solr powers the search and navigation features of many of the world's largest internet sites.
 
 * Good, because it is a well documented and powerful syntax
 * Good, because it is very close to the Elasticsearch and the Lucene syntax which enhances compatibility
 * Good, because it has a strong community with large resources and knowledge
-* Bad, because it adds complexity and fulfilling all the different query usecases can be an "uphill battle"
+* Bad, because it adds complexity and fulfilling all the different query use-cases can be an "uphill battle"
 
 ### Elasticsearch Query Language
 
@@ -83,8 +83,8 @@ Elasticsearch provides a full Query DSL (Domain Specific Language) based on JSON
 * Good, because it is a well documented and powerful syntax
 * Good, because it is very close to the Elasticsearch and the Solr syntax which enhances compatibility
 * Good, because there is a stable and well tested go client which brings a query builder
-* Good, because it could be used as the query language which supports different search backends by just implementing what is needed for our usecase
-* Bad, because it adds complexity and fulfilling all the different query usecases can be an "uphill battle"
+* Good, because it could be used as the query language which supports different search backends by just implementing what is needed for our use-case
+* Bad, because it adds complexity and fulfilling all the different query use-cases can be an "uphill battle"
 
 ## Links
 
diff --git a/docs/ocis/deployment/_index.md b/docs/ocis/deployment/_index.md
index d2db1b8eb98..e3fc175fda4 100644
--- a/docs/ocis/deployment/_index.md
+++ b/docs/ocis/deployment/_index.md
@@ -34,7 +34,7 @@ oCIS uses two system users which are needed for being operational:
 
 Both have simple default passwords which need to be changed. Currently, changing a password is only possible on the command line. You need to run `ocis accounts update --password <new-password> <id>` for both users.
 
-The new password for the Reva Inter Operability Platform user must be made available to oCIS by using the environment variable `STORAGE_LDAP_BIND_PASSWORD`. The same applies to the new Kopano IDP user password, which needs do be made available to oCIS in `IDP_LDAP_BIND_PASSWORD`.
+The new password for the Reva Inter Operability Platform user must be made available to oCIS by using the environment variable `STORAGE_LDAP_BIND_PASSWORD`. The same applies to the new Kopano IDP user password, which needs to be made available to oCIS in `IDP_LDAP_BIND_PASSWORD`.
 
 Furthermore, oCIS uses a shared secret to sign JWT tokens for inter service authorization, which also needs to be changed by the user.
 You can change it by setting the `OCIS_JWT_SECRET` environment variable for oCIS to a random string.
diff --git a/docs/ocis/deployment/basic-remote-setup.md b/docs/ocis/deployment/basic-remote-setup.md
index 4227a88e1f1..eaa95ac7025 100644
--- a/docs/ocis/deployment/basic-remote-setup.md
+++ b/docs/ocis/deployment/basic-remote-setup.md
@@ -11,7 +11,7 @@ geekdocFilePath: basic-remote-setup.md
 
 The default configuration of the oCIS binary and the `owncloud/ocis` docker image assume, that you access oCIS on `localhost`. This enables you to do quick testing and development without any configuration.
 
-If you need to access oCIS running in a docker container, on a VM or a remote machine via an other hostname than `localhost`, you need to configure this hostname in oCIS. The same applies if you are not using hostnames but instead an IP (eg. `192.168.178.25`).
+If you need to access oCIS running in a docker container, on a VM or a remote machine via another hostname than `localhost`, you need to configure this hostname in oCIS. The same applies if you are not using hostnames but instead an IP (e.g. `192.168.178.25`).
 
 ## Start the oCIS fullstack server from binary
 
@@ -31,7 +31,7 @@ For the following examples you need to have the oCIS binary in your current work
 
 ### Using automatically generated certificates
 
-In order to run oCIS with automatically generated and self signed certificates please execute following command. You need to replace `your-host` with an IP or hostname. Since you have only self signed certificates you need to have `OCIS_INSECURE` set to `true`.
+In order to run oCIS with automatically generated and self-signed certificates please execute following command. You need to replace `your-host` with an IP or hostname. Since you have only self-signed certificates you need to have `OCIS_INSECURE` set to `true`.
 
 ```bash
 OCIS_INSECURE=true \
diff --git a/docs/ocis/deployment/bridge.md b/docs/ocis/deployment/bridge.md
index 2551ac0440f..80a665a6f07 100644
--- a/docs/ocis/deployment/bridge.md
+++ b/docs/ocis/deployment/bridge.md
@@ -9,7 +9,7 @@ geekdocFilePath: bridge.md
 
 {{< toc >}}
 
-We are planning to build a bridge from ownCloud 10 to ocis. The idea is to have a reverse proxy infront of ownCloud 10 that will forward requests to ownCloud 10 or ocis-reva, depending on the migration status of the logged in user.
+We are planning to build a bridge from ownCloud 10 to ocis. The idea is to have a reverse proxy in front of ownCloud 10 that will forward requests to ownCloud 10 or ocis-reva, depending on the migration status of the logged-in user.
 
 This document is a work in progress of the current setup.
 
@@ -80,7 +80,7 @@ We are going to use the built binary and ownCloud 10 graphapi app to turn ownClo
 
 #### configure it
 
-While ocis can be configured using environment variables, eg. for a docker compose setup we are going to use a more traditional config file here.
+While ocis can be configured using environment variables, e.g. for a docker compose setup we are going to use a more traditional config file here.
 Create a config file for ocis in either `/etc/ocis`, `$HOME/.ocis` or `./.config`. You can use `.json`, `.yaml` or `.toml`. I will use toml here, because ... reasons.
 
 ```toml
@@ -191,7 +191,7 @@ ERROR:
 
 #### Set environment variables
 
-The built in [libregraph/lico](https://github.com/libregraph/lico) needs environment variables to configure the LDAP server:
+The built-in [libregraph/lico](https://github.com/libregraph/lico) needs environment variables to configure the LDAP server:
 ```console
 export OCIS_URL=https://ocis.ocis.test
 export IDP_LDAP_URI=ldap://127.0.0.1:9125
@@ -226,7 +226,7 @@ $ ocis/bin/ocis idp server --iss http://127.0.0.1:9130 --signing-kid gen1-2020-0
 
 {{< hint warning >}}
 * TODO: the port in the `--iss` needs to be changed when hiding the idp behind the proxy
-* TODO: the signing keys and encryption keys should be precerated so they are reused between restarts. Otherwise all client sessions will become invalid when restarting the IdP.
+* TODO: the signing keys and encryption keys should be precreated so they are reused between restarts. Otherwise all client sessions will become invalid when restarting the IdP.
 {{< /hint >}}
 
 
@@ -275,7 +275,7 @@ $ bin/web server --web-config-server https://cloud.example.com --oidc-authority
 `ocis-web` needs to know
 - `--web-config-server https://cloud.example.com` is ownCloud url with webdav and ocs endpoints (oc10 or ocis)
 - `--oidc-authority https://192.168.1.100:9130` the openid connect issuing authority, in our case `oidc-idp`, running on port 9130
-- `--oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration` the openid connect configuration endpoint, typically the issuer host with `.well-known/openid-configuration`, but there are cases when another endpoint is used, eg. ping identity provides multiple endpoints to separate domains
+- `--oidc-metadata-url https://192.168.1.100:9130/.well-known/openid-configuration` the openid connect configuration endpoint, typically the issuer host with `.well-known/openid-configuration`, but there are cases when another endpoint is used, e.g. ping identity provides multiple endpoints to separate domains
 - `--oidc-client-id ocis` the client id we will register later with `ocis-idp` in the `identifier-registration.yaml`
 
 ### Patch owncloud
@@ -304,7 +304,7 @@ $CONFIG = [
     'client-id' => 'ocis',
     'loginButtonName' => 'OpenId Connect @ Konnectd',
   ],
-  'debug' => true, // if using self signed certificates
+  'debug' => true, // if using self-signed certificates
   // allow the different domains access to the ocs and webdav endpoints:
   'cors.allowed-domains' => [
     'https://cloud.example.com',
diff --git a/docs/ocis/deployment/kubernetes.md b/docs/ocis/deployment/kubernetes.md
index 3a47c1feb0b..3edf35caa21 100644
--- a/docs/ocis/deployment/kubernetes.md
+++ b/docs/ocis/deployment/kubernetes.md
@@ -17,7 +17,7 @@ Formally described as:
 
 _[source](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)_
 
-Without getting too deep in definitions, and for the purpose of compactness, Kubernetes can be summarized as a way of managing containers that run applications to ensure that there is no downtime and a optimal usage of resources. It provides with a framework in which to run distributed systems.
+Without getting too deep in definitions, and for the purpose of compactness, Kubernetes can be summarized as a way of managing containers that run applications to ensure that there is no downtime and an optimal usage of resources. It provides with a framework in which to run distributed systems.
 
 Kubernetes provides you with:
 - **Service discovery and load balancing**: Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
diff --git a/docs/ocis/deployment/monitoring-tracing.md b/docs/ocis/deployment/monitoring-tracing.md
index 139a8e7b133..5de3c1b6b11 100644
--- a/docs/ocis/deployment/monitoring-tracing.md
+++ b/docs/ocis/deployment/monitoring-tracing.md
@@ -13,7 +13,7 @@ Monitoring and tracing gives developers and admin insights into a complex system
 
 If you are a developer and want to trace during developing you should have a look at [example server setup]({{< ref "../development/tracing" >}}).
 
-This documentation describes how to set up a long running monitoring & tracing infrastructure for one or multiple oCIS servers or deployments. After reading this guide, you also should know everything needed to integrate oCIS into your existing monitoring and tracing infrastructure.
+This documentation describes how to set up a long-running monitoring & tracing infrastructure for one or multiple oCIS servers or deployments. After reading this guide, you also should know everything needed to integrate oCIS into your existing monitoring and tracing infrastructure.
 
 # Overview about the proposed solution
 
@@ -25,7 +25,7 @@ We assume that you already have oCIS deployed on one or multiple servers by usin
 
 Telegraf will collect host metrics (CPU, RAM, network, processes, ...) and docker metrics (per container CPU, RAM, network, ...). Telegraf is also configured to scrape metrics from Prometheus metric endpoints which oCIS exposes, this is done by the Prometheus input plugin . The metrics from oCIS and all other metrics gathered will be exposed with the Prometheus output plugin and can therefore be scraped by our monitoring & tracing server.
 
-Jaeger agent is is being configured as target for traces in oCIS. It then will receive traces from all oCIS extensions, add some process tags to them and forward them to our Jaeger collector on our monitoring & tracing server.
+Jaeger agent is being configured as target for traces in oCIS. It then will receive traces from all oCIS extensions, add some process tags to them and forward them to our Jaeger collector on our monitoring & tracing server.
 
 For more information and how to deploy it, see [monitoring & tracing client](https://github.com/owncloud-devops/monitoring-tracing-client).
 
diff --git a/docs/ocis/deployment/oc10_ocis_parallel.md b/docs/ocis/deployment/oc10_ocis_parallel.md
index cceb3047149..b771e76133a 100644
--- a/docs/ocis/deployment/oc10_ocis_parallel.md
+++ b/docs/ocis/deployment/oc10_ocis_parallel.md
@@ -12,7 +12,7 @@ geekdocFilePath: oc10_ocis_parallel.md
 ## Overview
 
 - This setup reflects [stage 6 of the oC10 to oCIS migration plan]({{< ref "migration#stage-6-parallel-deployment" >}})
-- Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+- Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 - OpenLDAP server with demo users
 - LDAP admin interface to edit users
 - Keycloak as OpenID Connect provider in federation with the LDAP server
@@ -35,7 +35,7 @@ geekdocFilePath: oc10_ocis_parallel.md
 - four domains set up and pointing to your server
   - cloud.\* for serving oCIS
   - keycloak.\* for serving Keycloak
-  - ldap .\* for serving the LDAP managment UI
+  - ldap .\* for serving the LDAP management UI
   - traefik.\* for serving the Traefik dashboard
 
 See also [example server setup]({{< ref "preparing_server" >}})
@@ -60,7 +60,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
       ### Traefik settings ###
       TRAEFIK_LOG_LEVEL=
-      # Serve Treafik dashboard. Defaults to "false".
+      # Serve Traefik dashboard. Defaults to "false".
       TRAEFIK_DASHBOARD=
       # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
       TRAEFIK_DOMAIN=
@@ -100,7 +100,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
       LDAP_MANAGER_DOMAIN=
 
       ### Keycloak ###
-      # Domain of Keycloak, where you can find the managment and authentication frontend. Defaults to "keycloak.owncloud.test"
+      # Domain of Keycloak, where you can find the management and authentication frontend. Defaults to "keycloak.owncloud.test"
       KEYCLOAK_DOMAIN=
       # Realm which to be used with oC10 and oCIS. Defaults to "owncloud"
       KEYCLOAK_REALM=
@@ -112,17 +112,17 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oC10 and oCIS frontend in `CLOUD_DOMAIN=`, eg. `CLOUD_DOMAIN=cloud.owncloud.test`.
+  Set your domain for the oC10 and oCIS frontend in `CLOUD_DOMAIN=`, e.g. `CLOUD_DOMAIN=cloud.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
   By default ownCloud 10 will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OC10_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
@@ -130,11 +130,11 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   In oder to change the default link open action which defaults to the classic UI (`OWNCLOUD_WEB_REWRITE_LINKS=false`) you can set it to `OWNCLOUD_WEB_REWRITE_LINKS=true`. This will lead to links being opened in ownCloud Web.
 
-  The OpenLDAP server in this example deployment has an admin users, which is also used as bind user in order to keep theses examples simple. You can change the default password "admin" to a different one by setting it to `LDAP_ADMIN_PASSWORD=...`.
+  The OpenLDAP server in this example deployment has an admin users, which is also used as bind user in order to keep these examples simple. You can change the default password "admin" to a different one by setting it to `LDAP_ADMIN_PASSWORD=...`.
 
-  Set your domain for the LDAP manager UI in `LDAP_MANAGER_DOMAIN=`, eg. `ldap.owncloud.test`.
+  Set your domain for the LDAP manager UI in `LDAP_MANAGER_DOMAIN=`, e.g. `ldap.owncloud.test`.
 
-  Set your domain for the Keycloak administration panel and authentication endpoints to `KEYCLOAK_DOMAIN=` eg. `KEYCLOAK_DOMAIN=keycloak.owncloud.test`.
+  Set your domain for the Keycloak administration panel and authentication endpoints to `KEYCLOAK_DOMAIN=` e.g. `KEYCLOAK_DOMAIN=keycloak.owncloud.test`.
 
   Changing the used Keycloak realm can be done by setting `KEYCLOAK_REALM=`. This defaults to the ownCloud realm `KEYCLOAK_REALM=owncloud`. The ownCloud realm will be automatically imported on startup and includes our demo users.
 
@@ -152,7 +152,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 
diff --git a/docs/ocis/deployment/ocis_hello.md b/docs/ocis/deployment/ocis_hello.md
index 2afd77a633d..5b4dc1fa1fc 100644
--- a/docs/ocis/deployment/ocis_hello.md
+++ b/docs/ocis/deployment/ocis_hello.md
@@ -13,7 +13,7 @@ geekdocFilePath: ocis_hello.md
 
 - oCIS running behind Traefik as reverse proxy
 - oCIS Hello extension runs beside the main oCIS stack and providing the Hello functionality
-- Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+- Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_hello)
 
@@ -21,7 +21,7 @@ The docker stack consists of 3 containers. One of them is Traefik, a proxy which
 
 The next container is oCIS itself in a configuration like the [oCIS with Traefik example]({{< ref "ocis_traefik" >}}), except that for this example a custom proxy and web UI configuration is used to enable the oCIS Hello extension.
 
-The oCIS Hello extension is running in another container and enables you to use its' functionality from within ownCloud Web.
+The oCIS Hello extension is running in another container and enables you to use its functionality from within ownCloud Web.
 
 ## Server Deployment
 
@@ -53,7 +53,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
       INSECURE=true
 
       ### Traefik settings ###
-      # Serve Treafik dashboard. Defaults to "false".
+      # Serve Traefik dashboard. Defaults to "false".
       TRAEFIK_DASHBOARD=
       # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
       TRAEFIK_DOMAIN=
@@ -85,17 +85,17 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
   By default the oCIS Hello extension will be started in the `latest` version. If you want to start a specific version of oCIS Hello set the version to `OCIS_HELLO_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis-hello/tags?page=1&ordering=last_updated).
 
@@ -111,7 +111,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 
diff --git a/docs/ocis/deployment/ocis_individual_services.md b/docs/ocis/deployment/ocis_individual_services.md
index bb8de24f289..198af51d8d7 100644
--- a/docs/ocis/deployment/ocis_individual_services.md
+++ b/docs/ocis/deployment/ocis_individual_services.md
@@ -12,8 +12,8 @@ geekdocFilePath: ocis_individual_services.md
 ## Overview
 
 * oCIS running behind Traefik as reverse proxy
-* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
-* oCIS running as individual services (each extension in it's own containers)
+* Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
+* oCIS running as individual services (each extension in its own containers)
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_individual_services)
 
@@ -51,7 +51,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
   INSECURE=true
 
   ### Traefik settings ###
-  # Serve Treafik dashboard. Defaults to "false".
+  # Serve Traefik dashboard. Defaults to "false".
   TRAEFIK_DASHBOARD=
   # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
   TRAEFIK_DOMAIN=
@@ -81,17 +81,17 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default ocis will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
   You also can run more than one instance of the service by setting `OCIS_SCALE` to number greater than one.
 
@@ -106,7 +106,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 ## Local setup
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 ```
diff --git a/docs/ocis/deployment/ocis_keycloak.md b/docs/ocis/deployment/ocis_keycloak.md
index 7d8c189ca89..8980bd1b9cb 100644
--- a/docs/ocis/deployment/ocis_keycloak.md
+++ b/docs/ocis/deployment/ocis_keycloak.md
@@ -13,7 +13,7 @@ geekdocFilePath: ocis_keycloak.md
 
 * oCIS and Keycloak running behind Traefik as reverse proxy
 * Keycloak acting as the IDP for oCIS
-* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+* Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_keycloak)
 
@@ -55,7 +55,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
   INSECURE=true
 
   ### Traefik settings ###
-  # Serve Treafik dashboard. Defaults to "false".
+  # Serve Traefik dashboard. Defaults to "false".
   TRAEFIK_DASHBOARD=
   # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
   TRAEFIK_DOMAIN=
@@ -96,21 +96,21 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
   If you want to change the OIDC client id of th ownCloud Web frontend, you can do this by setting the name to `OCIS_OIDC_CLIENT_ID=`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
-  Set your domain for the Keycloak administration panel and authentication endpoints to `KEYCLOAK_DOMAIN=` eg. `KEYCLOAK_DOMAIN=keycloak.owncloud.test`.
+  Set your domain for the Keycloak administration panel and authentication endpoints to `KEYCLOAK_DOMAIN=` e.g. `KEYCLOAK_DOMAIN=keycloak.owncloud.test`.
 
   Changing the used Keycloak realm can be done by setting `KEYCLOAK_REALM=`. This defaults to the oCIS realm `KEYCLOAK_REALM=oCIS`. The oCIS realm will be automatically imported on startup and includes our demo users.
 
@@ -127,7 +127,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 ## Local setup
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 ```
diff --git a/docs/ocis/deployment/ocis_ldap.md b/docs/ocis/deployment/ocis_ldap.md
index 655dae94cc3..e39396b5e3f 100644
--- a/docs/ocis/deployment/ocis_ldap.md
+++ b/docs/ocis/deployment/ocis_ldap.md
@@ -12,7 +12,7 @@ geekdocFilePath: ocis_ldap.md
 
 ## Overview
 
-- Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+- Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 - OpenLDAP server with demo users
 - LDAP admin interface to edit users
 - oCIS running behind Traefik as reverse proxy
@@ -27,7 +27,7 @@ geekdocFilePath: ocis_ldap.md
 - Linux server with docker and docker-compose installed
 - four domains set up and pointing to your server
   - ocis.\* for serving oCIS
-  - ldap .\* for serving the LDAP managment UI
+  - ldap .\* for serving the LDAP management UI
   - traefik.\* for serving the Traefik dashboard
 
 See also [example server setup]({{< ref "preparing_server" >}})
@@ -51,7 +51,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
   INSECURE=true
 
   ### Traefik settings ###
-  # Serve Treafik dashboard. Defaults to "false".
+  # Serve Traefik dashboard. Defaults to "false".
   TRAEFIK_DASHBOARD=
   # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
   TRAEFIK_DOMAIN=
@@ -83,21 +83,21 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=cloud.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=cloud.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
-  The OpenLDAP server in this example deployment has an admin users, which is also used as bind user in order to keep theses examples simple. You can change the default password "admin" to a different one by setting it to `LDAP_ADMIN_PASSWORD=...`.
+  The OpenLDAP server in this example deployment has an admin users, which is also used as bind user in order to keep these examples simple. You can change the default password "admin" to a different one by setting it to `LDAP_ADMIN_PASSWORD=...`.
 
-  Set your domain for the LDAP manager UI in `LDAP_MANAGER_DOMAIN=`, eg. `ldap.owncloud.test`.
+  Set your domain for the LDAP manager UI in `LDAP_MANAGER_DOMAIN=`, e.g. `ldap.owncloud.test`.
 
   Now you have configured everything and can save the file.
 
@@ -111,7 +111,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 
diff --git a/docs/ocis/deployment/ocis_s3.md b/docs/ocis/deployment/ocis_s3.md
index b129ac66316..4e4ef41217a 100644
--- a/docs/ocis/deployment/ocis_s3.md
+++ b/docs/ocis/deployment/ocis_s3.md
@@ -14,7 +14,7 @@ geekdocFilePath: ocis_s3.md
 * oCIS running behind Traefik as reverse proxy
 * MinIO as S3 compatible storage provider
 * oCIS is configured to use S3 as user storage provider
-* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+* Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_s3)
 
@@ -22,7 +22,7 @@ The docker stack consists 3 containers. One of them is Traefik, a proxy which is
 
 The next container is oCIS itself in a configuration like the [oCIS with Traefik example]({{< ref "ocis_traefik" >}}), except that it will use S3 as user storage.
 
-The last container is MinIO, providing a S3 compatible API, where oCIS will store its' data.
+The last container is MinIO, providing a S3 compatible API, where oCIS will store its data.
 
 ## Server Deployment
 
@@ -55,7 +55,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
       INSECURE=true
 
       ### Traefik settings ###
-      # Serve Treafik dashboard. Defaults to "false".
+      # Serve Traefik dashboard. Defaults to "false".
       TRAEFIK_DASHBOARD=
       # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
       TRAEFIK_DOMAIN=
@@ -94,23 +94,23 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
-  Set your domain for the MinIO frontend in `MINIO_DOMAIN=`, eg. `MINIO_DOMAIN=minio.owncloud.test`. If you are using other S3-compatible providers you need to configure the respective endpoint here.
+  Set your domain for the MinIO frontend in `MINIO_DOMAIN=`, e.g. `MINIO_DOMAIN=minio.owncloud.test`. If you are using other S3-compatible providers you need to configure the respective endpoint here.
 
   If you like you can change the default name of the S3 bucket by setting `MINIO_BUCKET=` to a different value.
 
-  You also must override the S3 bucket credentials in `MINIO_ACCESS_KEY` and `MINIO_SECRET_KEY` in order to secure your MinIO instance. Choose some random strings eg. from the output of `openssl rand -base64 32`.
+  You also must override the S3 bucket credentials in `MINIO_ACCESS_KEY` and `MINIO_SECRET_KEY` in order to secure your MinIO instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`.
 
   Now you have configured everything and can save the file.
 
@@ -123,7 +123,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 ## Local setup
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 ```
diff --git a/docs/ocis/deployment/ocis_traefik.md b/docs/ocis/deployment/ocis_traefik.md
index 49bfcfd6323..14a60e1ec3f 100644
--- a/docs/ocis/deployment/ocis_traefik.md
+++ b/docs/ocis/deployment/ocis_traefik.md
@@ -12,7 +12,7 @@ geekdocFilePath: ocis_traefik.md
 ## Overview
 
 * oCIS running behind Traefik as reverse proxy
-* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+* Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_traefik)
 
@@ -50,7 +50,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
   INSECURE=true
 
   ### Traefik settings ###
-  # Serve Treafik dashboard. Defaults to "false".
+  # Serve Traefik dashboard. Defaults to "false".
   TRAEFIK_DASHBOARD=
   # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
   TRAEFIK_DOMAIN=
@@ -78,17 +78,17 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default ocis will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
   Now you have configured everything and can save the file.
 
@@ -101,7 +101,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 ## Local setup
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` on Windows to `C:\Windows\System32\Drivers\etc\hosts` file like this:
 ```
diff --git a/docs/ocis/deployment/ocis_wopi.md b/docs/ocis/deployment/ocis_wopi.md
index 5b8e7f22279..01e070c9b78 100644
--- a/docs/ocis/deployment/ocis_wopi.md
+++ b/docs/ocis/deployment/ocis_wopi.md
@@ -18,7 +18,7 @@ OnlyOffice and CodiMD are not yet fully integrated and there are known issues. F
 * oCIS, Wopi server, Collabora, OnlyOffice and CodiMD running behind Traefik as reverse proxy
 * Collabora, OnlyOffice and CodiMD enable you to edit documents in your browser
 * Wopi server acts as a bridge to make the oCIS storage accessible to Collabora, OnlyOffice and CodiMD
-* Traefik generating self signed certificates for local setup or obtaining valid SSL certificates for a server setup
+* Traefik generating self-signed certificates for local setup or obtaining valid SSL certificates for a server setup
 
 [Find this example on GitHub](https://github.com/owncloud/ocis/tree/master/deployments/examples/ocis_wopi)
 
@@ -64,7 +64,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
     INSECURE=true
 
     ### Traefik settings ###
-    # Serve Treafik dashboard. Defaults to "false".
+    # Serve Traefik dashboard. Defaults to "false".
     TRAEFIK_DASHBOARD=
     # Domain of Traefik, where you can find the dashboard. Defaults to "traefik.owncloud.test"
     TRAEFIK_DOMAIN=
@@ -120,17 +120,17 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   You are installing oCIS on a server and Traefik will obtain valid certificates for you so please remove `INSECURE=true` or set it to `false`.
 
-  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` eg. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
+  If you want to use the Traefik dashboard, set TRAEFIK_DASHBOARD to `true` (default is `false` and therefore not active). If you activate it, you must set a domain for the Traefik dashboard in `TRAEFIK_DOMAIN=` e.g. `TRAEFIK_DOMAIN=traefik.owncloud.test`.
 
-  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (eg. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
+  The Traefik dashboard is secured by basic auth. Default credentials are the user `admin` with the password `admin`. To set your own credentials, generate a htpasswd (e.g. by using [an online tool](https://htpasswdgenerator.de/) or a cli tool).
 
   Traefik will issue certificates with LetsEncrypt and therefore you must set an email address in `TRAEFIK_ACME_MAIL=`.
 
   By default oCIS will be started in the `latest` version. If you want to start a specific version of oCIS set the version to `OCIS_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/owncloud/ocis/tags?page=1&ordering=last_updated).
 
-  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, eg. `OCIS_DOMAIN=ocis.owncloud.test`.
+  Set your domain for the oCIS frontend in `OCIS_DOMAIN=`, e.g. `OCIS_DOMAIN=ocis.owncloud.test`.
 
-  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings eg. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
+  You also must override the default secrets in `IDP_LDAP_BIND_PASSWORD`, `STORAGE_LDAP_BIND_PASSWORD`, `OCIS_JWT_SECRET`, `STORAGE_TRANSFER_SECRET` and `OCIS_MACHINE_AUTH_API_KEY`  in order to secure your oCIS instance. Choose some random strings e.g. from the output of `openssl rand -base64 32`. For more information see [secure an oCIS instance]({{< ref "./#secure-an-ocis-instance" >}}).
 
   By default the CS3Org WOPI server will also be started in the `latest` version. If you want to start a specific version of it, you can set the version to `WOPISERVER_DOCKER_TAG=`. Available versions can be found on [Docker Hub](https://hub.docker.com/r/cs3org/wopiserver/tags?page=1&ordering=last_updated).
 
@@ -140,7 +140,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 
   Now it's time to set up Collabora and you need to configure the domain of Collabora in `COLLABORA_DOMAIN=`.
 
-  If you want to use the Collabora admin panel you need to set user name and passwort for in `COLLABORA_ADMIN_USER=` and `COLLABORA_ADMIN_PASSWORD=`.
+  If you want to use the Collabora admin panel you need to set user name and password for in `COLLABORA_ADMIN_USER=` and `COLLABORA_ADMIN_PASSWORD=`.
 
   Next up is OnlyOffice, which also needs a domain in `ONLYOFFICE_DOMAIN=`.
 
@@ -157,7 +157,7 @@ See also [example server setup]({{< ref "preparing_server" >}})
 ## Local setup
 For a more simple local ocis setup see [Getting started]({{< ref "../getting-started" >}})
 
-This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
+This docker stack can also be run locally. One downside is that Traefik can not obtain valid SSL certificates and therefore will create self-signed ones. This means that your browser will show scary warnings. Another downside is that you can not point DNS entries to your localhost. So you have to add static host entries to your computer.
 
 On Linux and macOS you can add them to your `/etc/hosts` files like this:
 ```
diff --git a/docs/ocis/deployment/systemd.md b/docs/ocis/deployment/systemd.md
index 8ac0a1d8f27..18de3fcd10a 100644
--- a/docs/ocis/deployment/systemd.md
+++ b/docs/ocis/deployment/systemd.md
@@ -40,7 +40,7 @@ For reasons of simplicity we are using the root user and group to run oCIS which
 
 
 In the service definition we referenced `/etc/ocis/ocis.env` as our file containing environment variables for the oCIS process.
-In order to create the file we need first to create the folder `/etc/ocis/` and than we can add the actual `/etc/ocis/ocis.env` with following content:
+In order to create the file we need first to create the folder `/etc/ocis/` and then we can add the actual `/etc/ocis/ocis.env` with following content:
 
 ```
 OCIS_URL=https://some-hostname-or-ip:9200
@@ -57,7 +57,7 @@ PROXY_TRANSPORT_TLS_CERT=/etc/ocis/proxy/server.crt
 PROXY_TRANSPORT_TLS_KEY=/etc/ocis/proxy/server.key
 ```
 
-Please change your `OCIS_URL` in order to reflect your actual deployment. If you are using self signed certificates you need to set `OCIS_INSECURE=true` in `/etc/ocis/ocis.env`.
+Please change your `OCIS_URL` in order to reflect your actual deployment. If you are using self-signed certificates you need to set `OCIS_INSECURE=true` in `/etc/ocis/ocis.env`.
 
 
 ## Starting the oCIS service
diff --git a/docs/ocis/development/debugging.md b/docs/ocis/development/debugging.md
index d213e752946..15aaf5bb81b 100644
--- a/docs/ocis/development/debugging.md
+++ b/docs/ocis/development/debugging.md
@@ -13,7 +13,7 @@ geekdocFilePath: debugging.md
 
 As a single binary for easy deployment running `ocis server` just forks itself to start all the services, which makes debugging those processes a little harder.
 
-Ultimately, we want to be able to stop a single service using eg. `ocis kill web` so that you can start the service you want to debug in debug mode. We need to [change the way we fork processes](https://github.com/owncloud/ocis/issues/77) though, otherwise the runtime will automatically restart a service if killed.
+Ultimately, we want to be able to stop a single service using e.g. `ocis kill web` so that you can start the service you want to debug in debug mode. We need to [change the way we fork processes](https://github.com/owncloud/ocis/issues/77) though, otherwise the runtime will automatically restart a service if killed.
 
 ### Start ocis
 
@@ -135,7 +135,7 @@ bin/ocis --log-level=$LOG_LEVEL proxy &
 # kill 17628
 ```
 
-4. Start the service you are interested in in debug mode. When using make to build the binary there is already a `bin/ocis-debug` binary for you. When running an IDE tell it which service to start by providing the corresponding sub command, eg. `bin\ocis-debug reva-frontend`.
+4. Start the service you are interested in debug mode. When using make to build the binary there is already a `bin/ocis-debug` binary for you. When running an IDE tell it which service to start by providing the corresponding sub command, e.g. `bin\ocis-debug reva-frontend`.
 
 ### Gather error messages
 
@@ -160,7 +160,7 @@ This popped up when I tried to add `marie` as a collaborator in ownCloud Web. Th
 ```
 
 {{< hint info >}}
-The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser.
+The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, e.g. by grabbing it from the browser.
 {{< /hint >}}
 {{< hint danger >}}
 TODO add ocis cli tool to obtain a bearer token.
@@ -190,7 +190,7 @@ The last line gives us a hint where the log message originated: `.../github.com/
 95:     }
 ```
 
-Ok, so this seems to be a convenience method that is called from multiple places an also handles errors. Unfortunately, this hides the actual source of the error. We could set a breakpoint in line 94 and reproduce the problem, which can be a lot harder than just clicking the share button or sending a curl request again. So let us see what else the log tells us.
+Ok, so this seems to be a convenience method that is called from multiple places and also handles errors. Unfortunately, this hides the actual source of the error. We could set a breakpoint in line 94 and reproduce the problem, which can be a lot harder than just clicking the share button or sending a curl request again. So let us see what else the log tells us.
 
 The previous line tells us that a Stat request failed: `uri=/cs3.gateway.v1beta1.GatewayAPI/Stat`. This time the line is written by the grpc log interceptor. What else is there?
 
@@ -214,7 +214,7 @@ replace github.com/cs3org/reva => ../reva
 ```
 
 {{< hint info >}}
-The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, eg. by grabbing it from the browser.
+The username and password only work when basic auth is available. Otherwise you have to obtain a bearer token, e.g. by grabbing it from the browser.
 {{< /hint >}}
 
 Rebuild ocis to make sure the dependency is used. It should be sufficient to just restart the service you want to debug.
diff --git a/docs/ocis/development/extensions.md b/docs/ocis/development/extensions.md
index cef08f3bcd9..9eaf3219763 100644
--- a/docs/ocis/development/extensions.md
+++ b/docs/ocis/development/extensions.md
@@ -42,7 +42,7 @@ ownCloud Web allows you to write an extension for itself and therefore offers a
 
 To make ownCloud Web pick up your extension, you need to activate it in the configuration like seen in the [Hello extension](https://owncloud.dev/extensions/ocis_hello/running/#configure-and-start-ocis).
 
-For a consistent look and feel, ownCloud Web uses a external design library, the [ownCloud design system](https://github.com/owncloud/owncloud-design-system). Since its classes and components are available through the wrapping `web runtime`, we highly recommend you to leverage it in your extension as well.
+For a consistent look and feel, ownCloud Web uses an external design library, the [ownCloud design system](https://github.com/owncloud/owncloud-design-system). Since its classes and components are available through the wrapping `web runtime`, we highly recommend you to leverage it in your extension as well.
 
 ### Settings
 
@@ -52,7 +52,7 @@ An extension likely has some behaviour which the user can configure. Fundamental
 
 The Proxy is an API gateway and acts as the single connection point where all external request from users and devices need to pass through.
 
-To make sure that requests can reach your extension's API, you need to register one or multiple endpoints at the proxy. The registration is a easy task and can be seen best on the [oCIS Hello example](https://owncloud.dev/extensions/ocis_hello/running/#configure-and-start-ocis).
+To make sure that requests can reach your extension's API, you need to register one or multiple endpoints at the proxy. The registration is an easy task and can be seen best on the [oCIS Hello example](https://owncloud.dev/extensions/ocis_hello/running/#configure-and-start-ocis).
 
 As files in ownCloud must always stay private (unless you share them with your friends or coworkers), requests to oCIS have an authenticated user context. This user context is also available to your extension and can be used to interact with the user's files. How to get the user context and authentication can be seen on the [oCIS Hello example](https://owncloud.dev/extensions/ocis_hello/settings/#account-uuid).
 
diff --git a/docs/ocis/development/getting-started.md b/docs/ocis/development/getting-started.md
index 8fa756efb6a..a01001b6cdc 100644
--- a/docs/ocis/development/getting-started.md
+++ b/docs/ocis/development/getting-started.md
@@ -25,9 +25,9 @@ If you find tools needed besides the mentioned above, please feel free to open a
 
 ## Repository structure
 
-oCIS consists of multiple micro services, also called extensions. We started by having standalone repositories for each of them, but quickly noticed that this adds a time consuming overhead for developers. So we ended up with a monorepo housing all the extensions in one repository.
+oCIS consists of multiple microservices, also called extensions. We started by having standalone repositories for each of them, but quickly noticed that this adds a time-consuming overhead for developers. So we ended up with a monorepo housing all the extensions in one repository.
 
-Each extension lives in a subfolder (eg. `accounts` or `settings`) within this repository as an independent Go module, following the [golang-standard project-layout](https://github.com/golang-standards/project-layout). They have common Makefile targets and can be used to change, build and run individual extensions. This allows us to version and release each extension independently.
+Each extension lives in a subfolder (e.g. `accounts` or `settings`) within this repository as an independent Go module, following the [golang-standard project-layout](https://github.com/golang-standards/project-layout). They have common Makefile targets and can be used to change, build and run individual extensions. This allows us to version and release each extension independently.
 
 The `ocis` folder contains our [go-micro](https://github.com/asim/go-micro/) and [suture](https://github.com/thejerf/suture) based runtime. It is used to import all extensions and implements commands to manage them, similar to a small orchestrator. With the resulting oCIS binary you can start single extensions or even all extensions at the same time.
 
diff --git a/docs/ocis/getting-started/_index.md b/docs/ocis/getting-started/_index.md
index 534d7bde054..685c37168d5 100644
--- a/docs/ocis/getting-started/_index.md
+++ b/docs/ocis/getting-started/_index.md
@@ -72,7 +72,7 @@ When you're using oCIS with self-signed certificates, you need to set the enviro
 {{< /hint >}}
 
 {{< hint warming >}}
-When you're creating the [demo users]({{< ref "./demo-users" >}}) by setting `ACCOUNTS_DEMO_USERS_AND_GROUPS=true`, you need to be sure that this instance is not used in prodution because the passwords are public.
+When you're creating the [demo users]({{< ref "./demo-users" >}}) by setting `ACCOUNTS_DEMO_USERS_AND_GROUPS=true`, you need to be sure that this instance is not used in production because the passwords are public.
 {{< /hint >}}
 
 {{< hint warning >}}
diff --git a/docs/ocis/getting-started/demo-users.md b/docs/ocis/getting-started/demo-users.md
index 1865446d93e..5eba9483f56 100644
--- a/docs/ocis/getting-started/demo-users.md
+++ b/docs/ocis/getting-started/demo-users.md
@@ -10,7 +10,7 @@ geekdocFilePath: demo-users.md
 oCIS has the option to create demo users during the first startup. These enable you to do quick testing and developing.
 
 {{< hint info >}}
-To create the demo users, run the inital setup step with an additional environment variable.
+To create the demo users, run the initial setup step with an additional environment variable.
 `ACCOUNTS_DEMO_USERS_AND_GROUPS=true ./bin/ocis server` will generate the demo users listed in the table below. By default, it only generates the admin and one user for IDP and Reva respectively.
 {{< /hint >}}
 
diff --git a/docs/ocis/migration.md b/docs/ocis/migration.md
index 75fecff6c03..5d4121f9780 100644
--- a/docs/ocis/migration.md
+++ b/docs/ocis/migration.md
@@ -269,7 +269,7 @@ _Feel free to add your question as a PR to this document using the link at the t
 <div style="break-after: page"></div>
 
 ### Stage-5: introduce user aware proxy
-In the previous stages oCIS was only accessible for administrators with access to the network. To expose only a single service to the internet, oCIS comes with a user aware proxy that can be used to route requests to the existing ownCloud 10 installation or oCIS, based on the authenticated user. The proxy uses OIDC to identify the logged in user and route them to the configured backend.
+In the previous stages oCIS was only accessible for administrators with access to the network. To expose only a single service to the internet, oCIS comes with a user aware proxy that can be used to route requests to the existing ownCloud 10 installation or oCIS, based on the authenticated user. The proxy uses OIDC to identify the logged-in user and route them to the configured backend.
 
 #### User impact
 The IP address of the ownCloud host changes. There is no change for the file sync and share functionality when requests are handled by the oCIS codebase as it uses the same database and storage system as owncloud 10.
@@ -537,7 +537,7 @@ data
 │   ├── thumbnails
 │   │   └── 123
 │   │   │   ├── 2048-1536-max.png
-│   │   │   └── 32-32.png                 // the file id, eg. of /Photos/Portugal.jpg
+│   │   │   └── 32-32.png                 // the file id, e.g. of /Photos/Portugal.jpg
 │   └── uploads
 ├── marie
 │   ├── cache
@@ -553,7 +553,7 @@ data
 
 The *data directory* may also contain subfolders for ownCloud 10 applications like `avatars`, `gallery`, `files_external` and `cache`.
 
-When an object storage is used as the primary storage all file blobs are stored by their file id and a prefix, eg.: `urn:oid:<fileid>`.
+When an object storage is used as the primary storage all file blobs are stored by their file id and a prefix, e.g.: `urn:oid:<fileid>`.
 
 The three types of blobs we need to migrate are stored in
 - `files` for file blobs, the current file content,
diff --git a/docs/ocis/release_notes.md b/docs/ocis/release_notes.md
index 8c549af25a0..a69beade157 100644
--- a/docs/ocis/release_notes.md
+++ b/docs/ocis/release_notes.md
@@ -20,7 +20,7 @@ The most prominent changes in ownCloud Infinite Scale 1.20.0 and ownCloud Web 5.
 * All sharing options (users & links) are now united in one panel in ownCloud Web. [web#6701](https://github.com/owncloud/web/pull/6701)
 * The "Media Viewer" in ownCloud Web has been renamed to "Preview". [web#6514](https://github.com/owncloud/web/pull/6514)
 * ownCloud Web now has support for audio playback in "Preview" (e.g., MP3, WAV, FLAC, OGG). [web#6514](https://github.com/owncloud/web/pull/6514)
-* The feedback link in ownCloud Web is now customizable. See https://owncloud.dev/clients/web/getting-started/#options for more information. [web#6702](https://github.com/owncloud/web/issues/6702) 
+* The feedback link in ownCloud Web is now customizable. See https://owncloud.dev/clients/web/getting-started/#options for more information. [web#6702](https://github.com/owncloud/web/issues/6702)
 * ownCloud Web now supports full screen mode for external apps like web office. [web#6688](https://github.com/owncloud/web/pull/6688)
 * ownCloud Web introduces an integrated PDF viewer that user native browser capabilities. [web#6654](https://github.com/owncloud/web/pull/6654)
 * The Text Editor in ownCloud Web has received a couple of improvements. [web#6667](https://github.com/owncloud/web/pull/6667)
@@ -150,7 +150,7 @@ We are currently in a Tech Preview state and breaking changes may occur at any t
 
 ## ownCloud Infinite Scale 1.17.0 Technology Preview
 
-Version 1.17.0 brings major changes, new features and improvements. The Infinite Scale backend introduces an event system as an important platform component and adds support for file locking. ownCloud Web 5.0.0 comes with a full rework of the design and user experience and introduces initial support for the 'Spaces' feauture. Additionally ownCloud Web now supports Collabora Online with the ownCloud 10 backend.
+Version 1.17.0 brings major changes, new features and improvements. The Infinite Scale backend introduces an event system as an important platform component and adds support for file locking. ownCloud Web 5.0.0 comes with a full rework of the design and user experience and introduces initial support for the 'Spaces' feature. Additionally ownCloud Web now supports Collabora Online with the ownCloud 10 backend.
 
 The most prominent changes in ownCloud Infinite Scale 1.17.0 and ownCloud Web 5.0.0 comprise:
 
@@ -529,7 +529,7 @@ You have to follow these steps to be able to access your data again in oCIS:
 1. stop oCIS
 1. navigate to `/var/tmp/ocis/storage/users/nodes/root/`
 1. in this directory you will find directories with UUID as names. These are the home folders of the oCIS users. Find the ones with content your oCIS users uploaded to oCIS.
-1. create an temporary directory eg. `/tmp/dereferenced-ocis-storage`
+1. create an temporary directory e.g. `/tmp/dereferenced-ocis-storage`
 1. copy the data from oCIS to the temporary directory while dereferencing symlinks. On Linux you can do this by running `cp --recursive --dereference /var/tmp/ocis/storage/users/nodes/root/ /tmp/dereferenced-ocis-storage`
 1. you now have a backup of all users data in `/tmp/dereferenced-ocis-storage` and can follow our recommended update strategy above
 
diff --git a/docs/ocis/release_roadmap.md b/docs/ocis/release_roadmap.md
index ab8a234cd54..b54e8293553 100644
--- a/docs/ocis/release_roadmap.md
+++ b/docs/ocis/release_roadmap.md
@@ -7,7 +7,7 @@ geekdocEditPath: edit/master/docs/ocis
 geekdocFilePath: release_roadmap.md
 ---
 
-You may have asked yourself why there are major version 1 tags in our GitHub repository but the Readme still states `ownCloud Infinite Scale is currently in a technical preview state. It will be subject to a lot of changes and is not yet ready for general production deployments.`. How can that be if its a major version 1?
+You may have asked yourself why there are major version 1 tags in our GitHub repository but the Readme still states `ownCloud Infinite Scale is currently in a technical preview state. It will be subject to a lot of changes and is not yet ready for general production deployments.`. How can that be if it's a major version 1?
 
 Our initial and also our current plan is to stick to SemVer as versioning scheme. But sometimes there are other factors which cross your plans. Therefore we started releasing oCIS with version `1.0.0 Tech Preview`.
 
@@ -19,7 +19,7 @@ We will be fixing bugs if you report them and truly appreciate every report and
 
 We are going to stick to major version 1 until we feel confident about running oCIS in production environments. As a consequence of this we cannot raise the major version, like SemVer requires it, even if we need to introduce breaking changes. We will do our best to avoid breaking changes. If there is no way to circumvent this, we will add an automatic migration or at least point out manual migration steps, since we as oCIS developers are already using oCIS on a personal basis. The best place to see if a breaking change happens is our changelog which is available for every release. If things are not working out for you please contact us immediately. We want to know about this and solve it for you.
 
-It isn't our intention to scare you with our addendum "Tech Preview". We want you to have a clear picture of what you can expect from oCIS. You could take it as a disclaimer or even compare it to running an Linux kernel in alpha stage. It can be very pleasing to be on the latest codebase but you could also find yourself with a lot of problems arising because of that.
+It isn't our intention to scare you with our addendum "Tech Preview". We want you to have a clear picture of what you can expect from oCIS. You could take it as a disclaimer or even compare it to running a Linux kernel in alpha stage. It can be very pleasing to be on the latest codebase but you could also find yourself with a lot of problems arising because of that.
 
 You clearly can expect a totally new experience of file-sync and share with oCIS and we want you to use it now - but with understanding and caution.
 
diff --git a/docs/ocis/storage-backends/cephfs.md b/docs/ocis/storage-backends/cephfs.md
index fa3de4357d0..d46af51cc1c 100644
--- a/docs/ocis/storage-backends/cephfs.md
+++ b/docs/ocis/storage-backends/cephfs.md
@@ -13,14 +13,14 @@ oCIS intends to make the aspects of existing storage systems available as transp
 
 ## Development
 
-The cephfs development happens in a [Reva branch](https://github.com/cs3org/reva/pull/1209) and is currently driven by CERN. 
+The cephfs development happens in a [Reva branch](https://github.com/cs3org/reva/pull/1209) and is currently driven by CERN.
 
 ## Architecture
 
 In the original approach the driver was based on the [localfs](https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go) driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create subvolumes for user homes and maintain a file id to path mapping using symlinks.
 
 ## Implemented Aspects
-The recursive change time built ino cephfs is used to implement the etag propagation expected by the ownCloud clients. This allows oCIS to pick up changes that have been made by external tools, bypassing any oCIS APIs. 
+The recursive change time built ino cephfs is used to implement the etag propagation expected by the ownCloud clients. This allows oCIS to pick up changes that have been made by external tools, bypassing any oCIS APIs.
 
 Like other filesystems cephfs uses inodes and like most other filesystems inodes are reused. To get stable file identifiers the current cephfs driver assigns every node a file id and maintains a custom fileid to path mapping in a system directory:
 ```
@@ -42,7 +42,7 @@ Versions are not file but snapshot based, a [native feature of cephfs](https://d
 
 Trash is not implemented, as cephfs has no native recycle bin and instead relies on the snapshot functionality that can be triggered by end users. It should be possible to automatically create a snapshot before deleting a file. This needs to be explored.
 
-Shares [are be mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#diff-5e532e61f99bffb5754263bc6ce75f84a30c6f507a58ba506b0b487a50eda1d9R168-R224) supported by cephfs. The share manager is used to persist the intent of a share and can be used to periodically verify or reset the ACLs on cephfs.
+Shares [are mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#diff-5e532e61f99bffb5754263bc6ce75f84a30c6f507a58ba506b0b487a50eda1d9R168-R224) supported by cephfs. The share manager is used to persist the intent of a share and can be used to periodically verify or reset the ACLs on cephfs.
 
 ## Future work
 - The spaces concept matches cephfs subvolumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup.
@@ -51,8 +51,8 @@ Shares [are be mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#di
 - As it basically provides two lists, *shared with me* and *shared with others*, we could persist them directly on cephfs!
   - If needed for redundancy, the share manager can be run multiple times, backed by the same cephfs
   - To save disk io the data can be cached in memory, and invalidated using stat requests.
-- A good tradeoff would be a folder for each user with a json file for each list. That way, we only have to open and read a single file when the user want's to list the shares.    
-- To allow deprovisioning a user the data should by sharded by userid. That way all share information belonging to a user can easily be removed from the system. If necessary it can also be restored easily by copying the user specific folder back in place.
+- A good tradeoff would be a folder for each user with a json file for each list. That way, we only have to open and read a single file when the user want's to list the shares.
+- To allow deprovisioning a user the data should be sharded by userid. That way all share information belonging to a user can easily be removed from the system. If necessary it can also be restored easily by copying the user specific folder back in place.
 - For consistency over metadata any file blob data, backups can be done using snapshots.
 - An example where einstein has shared a file with marie would look like this on disk:
 ```
@@ -74,4 +74,4 @@ Shares [are be mapped to ACLs](https://github.com/cs3org/reva/pull/1209/files#di
     └── marie
         └── sharedWithMe.json
 ```
-- The fileids should [not be based on the path](https://github.com/cs3org/reva/pull/1209/files#diff-eba5c8b77ccdd1ac570c54ed86dfa7643b6b30e5625af191f789727874850172R125-R127) and instead use a uuid that is also persisted in the extended attributes to allow rebuilding the index from scratch if necessary.
\ No newline at end of file
+- The fileids should [not be based on the path](https://github.com/cs3org/reva/pull/1209/files#diff-eba5c8b77ccdd1ac570c54ed86dfa7643b6b30e5625af191f789727874850172R125-R127) and instead use a uuid that is also persisted in the extended attributes to allow rebuilding the index from scratch if necessary.
diff --git a/docs/ocis/storage-backends/eos.md b/docs/ocis/storage-backends/eos.md
index d3be56b3852..bcdf628e530 100644
--- a/docs/ocis/storage-backends/eos.md
+++ b/docs/ocis/storage-backends/eos.md
@@ -115,7 +115,7 @@ If the problem persists, please check the [troubleshooting section about uploads
 
 ## Further exploration
 
-EOS has a built in shell that you can enter using
+EOS has a built-in shell that you can enter using
 ```
 $ docker-compose exec mgm-master eos
 # ---------------------------------------------------------------------------
@@ -223,7 +223,7 @@ The ocis logs can be accessed using `docker-compose logs ocis`. Add `-f` for fol
 
 1. `docker-compose exec ocis make clean build` to update the binary
 2. `docker-compose exec ocis ./bin/ocis kill <service>` to kill the service
-3. `docker-compose exec ocis ./bin/ocis run <service>` to start the service. Do not forget to set any env vars, eg.
+3. `docker-compose exec ocis ./bin/ocis run <service>` to start the service. Do not forget to set any env vars, e.g.
   `docker-compose exec -e STORAGE_HOME_DRIVER=eoshome -e STORAGE_DRIVER_EOS_LAYOUT="{{substr 0 1 .Id.OpaqueId}}/{{.Id.OpaqueId}}"  ocis ./bin/ocis run storage-home`
 
 ### Creation and upload of files does not work


Test patch:
diff --git a/docs/ocis/development/testing.md b/docs/ocis/development/testing.md
index 5d6a5d34954..58270b65f1b 100644
--- a/docs/ocis/development/testing.md
+++ b/docs/ocis/development/testing.md
@@ -55,7 +55,7 @@ This must be pointing to a valid feature definition.
 
 ### oCIS image to be tested (or: skip build and take existing image)
 
-By default, the tests will be run against the docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag `OCIS_IMAGE_TAG=...` which must contain an available docker tag of the [owncloud/ocis registry on Docker Hub](https://hub.docker.com/r/owncloud/ocis) (eg. 'latest').
+By default, the tests will be run against the docker image built from your current working state of the oCIS repository. For some purposes it might also be handy to use a oCIS image from Docker Hub. Therefore you can provide the optional flag `OCIS_IMAGE_TAG=...` which must contain an available docker tag of the [owncloud/ocis registry on Docker Hub](https://hub.docker.com/r/owncloud/ocis) (e.g. 'latest').
 
 ```
 make -C tests/acceptance/docker localApiTests-apiAccountsHashDifficulty-ocis OCIS_IMAGE_TAG=latest