Update docs

Author: LEDfan

docs/README.md

@@ -2,4 +2,4 @@
 
 - [Deployment (with examples)](deployment/)
 - [Behavior in combination with ShinyProxy](shinyproxy.md)
-- [Prometheus monitoring](prometheus.md)
+- [Prometheus monitoring](prometheus.md)

docs/deployment/README.md

@@ -13,14 +13,14 @@ and dependencies of the operator.
   servers.
 - **ShinyProxy**: the ShinyProxy servers, these host the Shiny apps. You do not
   need to create these servers manually, since these are created by the
-  operator. Instead you define which servers to create and the operator creates
+  operator. Instead, you define which servers to create, and the operator creates
   all necessary Kubernetes resources, without affecting any existing server or
   causing downtime.
 - **Redis**: Redis is used by ShinyProxy (not by the operator) to implement
   session persistence. This ensures that when a ShinyProxy server is replaced,
   the user is still logged in. This provides a smooth transition when the
   operator replaces a ShinyProxy server.
-- **Skipper**: Skipper is used as an ingress controller. Currently this is the
+- **Skipper**: Skipper is used as an ingress controller. Currently, this is the
   only ingress controller supported by the operator. The reason is that the
   ingress controller is responsible for routing users to the correct ShinyProxy
   server. Skipper is the only ingress controller we found suitable for this
@@ -31,7 +31,7 @@ and dependencies of the operator.
 
 ## Tutorial using minikube
 
-This section provides an step-by-step tutorial on the basic deployment of the
+This section provides a step-by-step tutorial on the basic deployment of the
 ShinyProxy operator on minikube.
 
 1. This tutorial requires that you install some tools:
@@ -92,22 +92,22 @@ ShinyProxy operator on minikube.
    it.
 10. Try the other examples:
 
-  ```bash
-  kubectl delete namespace/shinyproxy
-  kubectl delete namespace/shinyproxy-operator                 # may fail
-  kubectl delete namespace/shinyproxy-dept2                    # may fail
-  kubectl delete namespace/my-namespace                        # may fail
-  kubectl delete namespace/redis                               # may fail
-  kubectl delete namespace/skipper                             # may fail
-  kubectl delete -n default ingress/ngingx-to-skipper-ingress  # may fail
-  kubectl delete -n skipper ingress/ngingx-to-skipper-ingress  # may fail
-  cd directory_of_example
-  kustomize build .  | k apply -f -
-  ```
+    ```bash
+    kubectl delete namespace/shinyproxy
+    kubectl delete namespace/shinyproxy-operator                 # may fail
+    kubectl delete namespace/shinyproxy-dept2                    # may fail
+    kubectl delete namespace/my-namespace                        # may fail
+    kubectl delete namespace/redis                               # may fail
+    kubectl delete namespace/skipper                             # may fail
+    kubectl delete -n default ingress/ngingx-to-skipper-ingress  # may fail
+    kubectl delete -n skipper ingress/ngingx-to-skipper-ingress  # may fail
+    cd directory_of_example
+    kustomize build .  | k apply -f -
+    ```
 
 ## Overview of examples
 
-The Operator is designed to be flexible and fit many type of deployments. This repository includes examples for many kind of deployments:
+The Operator is designed to be flexible and fit many type of deployments. This repository includes examples for many kinds of deployments:
 
 - *1-namespaced-hpa*:
   - Operator-mode: `namespaced`
@@ -118,7 +118,7 @@ The Operator is designed to be flexible and fit many type of deployments. This r
   - ShinyProxy-namespace: `shinyproxy`
   - URLs: `https://shinyproxy-demo.local`
 
-  This is a very simple deployment of the operator, were everything runs in the same namespace.
+  This is a very simple deployment of the operator, where everything runs in the same namespace.
 
 - *2-namespaced-ds*:
   - Operator-mode: `namespaced`
@@ -129,8 +129,8 @@ The Operator is designed to be flexible and fit many type of deployments. This r
   - ShinyProxy-namespace: `shinyproxy`
   - URLs: `https://shinyproxy-demo.local`
 
-  This deployment is very similar to the previous one, except that it runs Skipper using a `DaemonSet` instead of an automatically scaling `Deployment`. Using the `DaemonSet` ensures that every Kubernetes nodes contains a Skipper pod. This is useful when you want an predictable amount of Skipper pods. In the previous example, the cluster automatically scales the amount of Skipper pods according to the load of these pods. When properly configured, this ensures that Skipper has enough resources to
-  do its work, while not waisting resources.
+  This deployment is very similar to the previous one, except that it runs Skipper using a `DaemonSet` instead of an automatically scaling `Deployment`. Using the `DaemonSet` ensures that every Kubernetes nodes contains a Skipper pod. This is useful when you want a predictable amount of Skipper pods. In the previous example, the cluster automatically scales the amount of Skipper pods according to the load of these pods. When properly configured, this ensures that Skipper has enough resources to
+  do its work, while not wasting resources.
 
 - *3-clustered-hpa*:
   - Operator-mode: `clustered`
@@ -143,7 +143,7 @@ The Operator is designed to be flexible and fit many type of deployments. This r
     - `https://shinyproxy-demo.local`
     - `https://shinyproxy-demo2.local`
 
-  In this example, the operator runs in `clustered` mode. Therefore the operator will look into all namespaces for `ShinyProxy` resources and deploy these resources in their respective namespace. This also requires Skipper to be run in clustered mode (in the previous examples it would only look at `Ingress`
+  In this example, the operator runs in `clustered` mode. Therefore, the operator will look into all namespaces for `ShinyProxy` resources and deploy these resources in their respective namespace. This also requires Skipper to be run in clustered mode (in the previous examples it would only look at `Ingress`
   definitions in the `shinyproxy` namespace.) This example also demonstrates how the Operator can be used in a multi-tenancy or multi-realm way. Each ShinyProxy server runs in its own namespace, isolated from the other servers. However, they are managed by a single operator.
 
 - *4-clustered-ds*:
@@ -168,7 +168,7 @@ The Operator is designed to be flexible and fit many type of deployments. This r
   - ShinyProxy-namespace: `shinyproxy`
   - URLs: `https://shinyproxy-demo.local`
 
-  Similar to example example 1, however, the `01_hello` app will now run in the
+  Similar to example 1, however, the `01_hello` app will now run in the
   `my-namespace` namespace instead of the `shinyproxy` namespace. In addition to the change in the `shinyproxy.yaml`, this configuration requires the definition of the extra namespace and the modification of the `ServiceAccount`
   of the ShinyProxy server.
 
@@ -185,9 +185,9 @@ The Operator is designed to be flexible and fit many type of deployments. This r
     - `https://shinyproxy-demo.local/shinyproxy3/`
 
   Based on example 2, this example shows how multi-tenancy can be achieved using
-  sub-paths instead of multiple domainnames. Each ShinyProxy server is made
-  available at the same domainname but at a different path under that
-  domainname.
+  sub-paths instead of multiple domain names. Each ShinyProxy server is made
+  available at the same domain name but at a different path under that
+  domain name.
 
 ## ShinyProxy CRD
 

docs/prometheus.md

@@ -52,11 +52,11 @@ This configuration automatically discovers all ShinyProxy servers.
 
 The above screenshot shows the `absolute_users_active` metric int the Prometheus
 UI. The `shinyproxy_realm` label is automatically added by ShinyProxy to every
-metric. The tag contains the resource name of the ShinyProxy server. Therefore
+metric. The tag contains the resource name of the ShinyProxy server. Therefore,
 this tag is not added to the metrics when ShinyProxy is not being run using the
 Operator. In the screenshot there are three ShinyProxy servers being managed by
 the ShinyProxy server and two servers using a traditional deployment. The
-`shinyproxy` realm has has two severs (instances) running (see the
+`shinyproxy` realm has two severs (instances) running (see the
 `shinyproxy_instance` label). The dashboard provided on the [ShinyProxy website](https://shinyproxy.io/documentation/usage-statistics/#micrometer) 
 is designed to work with multiple realms and multiple servers inside each realm.
 For example, when displaying the Active Users, the dashboard differentiates
@@ -65,5 +65,5 @@ between the different realms:
 ![Grafana UI](../.github/screenshots/grafana_active_users.png)
 
 The dashboard contains two variables which allow you to filter the panels by
-realm or app name. By default these are hidden, check the [ShinyProxy website](https://shinyproxy.io/documentation/usage-statistics/#variable-filters)
+realm or app name. By default, these are hidden, check the [ShinyProxy website](https://shinyproxy.io/documentation/usage-statistics/#variable-filters)
 to makes these visible.

docs/shinyproxy.md

@@ -13,13 +13,13 @@ connection and session of currently running apps. Every time the configuration
 of ShinyProxy is updated, the operator creates a new ShinyProxy server. The
 previous running server will not be removed by the operator immediately.
 Instead, it is kept around as long as users are running apps on that server.
-Theses users will stay on the old server, until they are transferred to the new
+These users will stay on the old server, until they are transferred to the new
 server. In contrast, new users will automatically get routed to the latest
 server and run their apps on that server.
 
 ## Transferring users to the latest ShinyProxy Server
 
-This sections describe the scenarios in which a user is transferred to the
+These sections describe the scenarios in which a user is transferred to the
 latest server.
 
 ### Scenario 1: user action
@@ -46,7 +46,7 @@ the latest version.
 **Note:** both messages can be disabled by setting the
 `proxy.operator.show-transfer-message-main-page` and
 `proxy.operator.show-transfer-message-app-page` options to `false` (in the
-ShinyProxy configuration). By default these messages are enabled.
+ShinyProxy configuration). By default, these messages are enabled.
 
 ### Scenario 2: After logout
 
@@ -97,7 +97,7 @@ server. This server will then redirect to the OpenID provider.
   the latest ShinyProxy server
 
 **Note:** this only works when the `proxy.operator.force-transfer` option is set
-to `true` (in the ShinyProxy configuration). By default this option is disabled.
+to `true` (in the ShinyProxy configuration). By default, this option is disabled.
 
 ### Scenario 5: Starting an app
 
@@ -111,8 +111,8 @@ to `true` (in the ShinyProxy configuration). By default this option is disabled.
 
 **Behavior:**
 
-- before ShinyProxy starts the request app, the user is transferred to the
+- before ShinyProxy starts the requested app, the user is transferred to the
   latest ShinyProxy server
 
 **Note:** this only works when the `proxy.operator.force-transfer` option is set
-to `true` (in the ShinyProxy configuration). By default this option is disabled.
+to `true` (in the ShinyProxy configuration). By default, this option is disabled.