Various grammar and typos

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.

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).
 

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.
 

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