diff --git a/.github/md_config.json b/.github/md_config.json
new file mode 100644
index 0000000..465a309
--- /dev/null
+++ b/.github/md_config.json
@@ -0,0 +1,7 @@
+{
+  "ignorePatterns": [
+    {
+      "pattern": "^(?!http).+"
+    }
+  ]
+}
diff --git a/.github/workflows/pull_request.yaml b/.github/workflows/pull_request.yaml
index 498218a..44dc1d1 100644
--- a/.github/workflows/pull_request.yaml
+++ b/.github/workflows/pull_request.yaml
@@ -1,7 +1,7 @@
 name: Pull Request
 
 on:
-  pull_request_target:
+  pull_request:
     branches:
       - master
 
@@ -12,6 +12,12 @@ env:
   REGISTRY: ghcr.io
 
 jobs:
+  qa:
+    uses: stakater/.github/.github/workflows/pull_request_doc_qa.yaml@v0.0.43
+    with:
+      MD_CONFIG: .github/md_config.json
+      DOC_SRC: README.md docs
+      MD_LINT_CONFIG: .markdownlint.yaml
   build:
     runs-on: ubuntu-latest
     name: Build
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..a47a9fc
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "vocabulary"]
+	path = vocabulary
+	url = git@github.com:stakater/vocabulary.git
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
new file mode 100644
index 0000000..77dfb50
--- /dev/null
+++ b/.markdownlint.yaml
@@ -0,0 +1,6 @@
+{
+  "MD007": { "indent": 4 },
+  "MD013": false,
+  "MD024": false,
+  "MD029": { "style": one },
+}
diff --git a/.vale.ini b/.vale.ini
new file mode 100644
index 0000000..56d1b75
--- /dev/null
+++ b/.vale.ini
@@ -0,0 +1,9 @@
+StylesPath = "vocabulary/styles"
+MinAlertLevel = warning
+
+Vocab = "Stakater"
+
+# Only check MarkDown files
+[*.md]
+
+BasedOnStyles = Vale
diff --git a/README.md b/README.md
index 8032dbe..4393840 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# ![](assets/web/reloader-round-100px.png) RELOADER
+# ![Reloader-logo](assets/web/reloader-round-100px.png) Reloader
 
 [![Go Report Card](https://goreportcard.com/badge/github.com/stakater/reloader?style=flat-square)](https://goreportcard.com/report/github.com/stakater/reloader)
 [![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](https://godoc.org/github.com/stakater/reloader)
@@ -17,9 +17,21 @@ We would like to watch if some change happens in `ConfigMap` and/or `Secret`; th
 
 Reloader can watch changes in `ConfigMap` and `Secret` and do rolling upgrades on Pods with their associated `DeploymentConfigs`, `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts`.
 
+## Enterprise Version
+
+Reloader is available in two different versions:
+
+1. Open Source version
+1. Enterprise Version, which includes:
+    - SLA for support and unique requests
+    - Slack Support
+    - Certified images
+
+Contact [`sales@stakater.com`](mailto:sales@stakater.com) for info about Reloader Enterprise.
+
 ## Compatibility
 
-Reloader is compatible with kubernetes >= 1.9
+Reloader is compatible with Kubernetes >= 1.9
 
 ## How to use Reloader
 
@@ -72,8 +84,8 @@ will always restart upon a change in configmaps or secrets it uses, regardless
 of whether they have the `reloader.stakater.com/match: "true"` annotation or
 not.
 
-We can also specify a specific configmap or secret which would trigger rolling upgrade only upon change in our specified configmap or secret, this way, it will not trigger rolling upgrade upon changes in all configmaps or secrets used in a deploymentconfig, deployment, daemonset, statefulset or rollout.
-To do this either set the auto annotation to `"false"` (`reloader.stakater.com/auto: "false"`) or remove it altogether, and use annotations for [Configmap](#Configmap) or [Secret](#Secret)
+We can also specify a specific configmap or secret which would trigger rolling upgrade only upon change in our specified configmap or secret, this way, it will not trigger rolling upgrade upon changes in all configmaps or secrets used in a `deploymentconfig`, `deployment`, `daemonset`, `statefulset` or `rollout`.
+To do this either set the auto annotation to `"false"` (`reloader.stakater.com/auto: "false"`) or remove it altogether, and use annotations for [Configmap](.#Configmap) or [Secret](.#Secret).
 
 ### Configmap
 
@@ -133,8 +145,8 @@ spec:
 
 ### NOTES
 
-- Reloader also supports [sealed-secrets](https://github.com/bitnami-labs/sealed-secrets). [Here](docs/Reloader-with-Sealed-Secrets.md) are the steps to use sealed-secrets with reloader.
-- For [rollouts](https://github.com/argoproj/argo-rollouts/) reloader simply triggers a change is up to you how you configure the rollout strategy.
+- Reloader also supports [sealed-secrets](https://github.com/bitnami-labs/sealed-secrets). [Here](docs/Reloader-with-Sealed-Secrets.md) are the steps to use sealed-secrets with Reloader.
+- For [`rollouts`](https://github.com/argoproj/argo-rollouts/) Reloader simply triggers a change is up to you how you configure the `rollout` strategy.
 - `reloader.stakater.com/auto: "true"` will only reload the pod, if the configmap or secret is used (as a volume mount or as an env) in `DeploymentConfigs/Deployment/Daemonsets/Statefulsets`
 - `secret.reloader.stakater.com/reload` or `configmap.reloader.stakater.com/reload` annotation will reload the pod upon changes in specified configmap or secret, irrespective of the usage of configmap or secret.
 - you may override the auto annotation with the `--auto-annotation` flag
@@ -150,17 +162,12 @@ spec:
 - you can configure the "reload strategy" with the `--reload-strategy=<strategy-name>` option (details below)
 
 ## Reload Strategies
-Reloader supports multiple "reload" strategies for performing rolling upgrades to resources. The following list describes them:
-- **env-vars**: When a tracked `configMap`/`secret` is updated, this strategy attaches a Reloader specific environment variable to any containers 
-  referencing the changed `configMap` or `secret` on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.).
-  This strategy can be specified with the `--reload-strategy=env-vars` argument. Note: This is the default reload strategy.
-- **annotations**: When a tracked `configMap`/`secret` is updated, this strategy attaches a `reloader.stakater.com/last-reloaded-from` pod template annotation
-  on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.). This strategy is useful when using resource syncing tools like ArgoCD, since it will not cause these tools
-  to detect configuration drift after a resource is reloaded. Note: Since the attached pod template annotation only tracks the last reload source, this strategy will reload any tracked resource should its 
-  `configMap` or `secret` be deleted and recreated.
-  This strategy can be specified with the `--reload-strategy=annotations` argument.
-  
 
+Reloader supports multiple "reload" strategies for performing rolling upgrades to resources. The following list describes them:
+
+- **env-vars**: When a tracked `configMap`/`secret` is updated, this strategy attaches a Reloader specific environment variable to any containers referencing the changed `configMap` or `secret` on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.). This strategy can be specified with the `--reload-strategy=env-vars` argument. Note: This is the default reload strategy.
+- **annotations**: When a tracked `configMap`/`secret` is updated, this strategy attaches a `reloader.stakater.com/last-reloaded-from` pod template annotation on the owning resource (e.g., `Deployment`, `StatefulSet`, etc.). This strategy is useful when using resource syncing tools like ArgoCD, since it will not cause these tools to detect configuration drift after a resource is reloaded. Note: Since the attached pod template annotation only tracks the last reload source, this strategy will reload any tracked resource should its `configMap` or `secret` be deleted and recreated. This strategy can be specified with the `--reload-strategy=annotations` argument.
+  
 ## Deploying to Kubernetes
 
 You can deploy Reloader by following methods:
@@ -175,26 +182,27 @@ kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/depl
 
 By default, Reloader gets deployed in `default` namespace and watches changes `secrets` and `configmaps` in all namespaces.
 
-Reloader can be configured to ignore the resources `secrets` and `configmaps` by passing the following args (`spec.template.spec.containers.args`) to its container :
+Reloader can be configured to ignore the resources `secrets` and `configmaps` by passing the following arguments (`spec.template.spec.containers.args`) to its container :
 
-| Args                             | Description          |
+| Argument                         | Description          |
 | -------------------------------- | -------------------- |
 | --resources-to-ignore=configMaps | To ignore configMaps |
 | --resources-to-ignore=secrets    | To ignore secrets    |
 
-**Note:** At one time only one of these resource can be ignored, trying to do it will cause error in Reloader. Workaround for ignoring both resources is by scaling down the reloader pods to `0`.
+**Note:** At one time only one of these resource can be ignored, trying to do it will cause error in Reloader. Workaround for ignoring both resources is by scaling down the Reloader pods to `0`.
 
-Reloader can be configured to only watch secrets/configmaps with one or more labels using the `--resource-label-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (ie. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors). 
+Reloader can be configured to only watch secrets/configmaps with one or more labels using the `--resource-label-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors).
 
 **Note:** The old `:` delimited key value mappings are deprecated and if provided will be translated to `key=value`. Likewise, if a wildcard value is provided (e.g. `key:*`) it will be translated to the standalone `key` which checks for key existence.
 
 These selectors can be combined together, for example with:
 
-```
+```yaml
 --resource-label-selector=reloader=enabled,key-exists,another-label in (value1,value2,value3)
 ```
 
 Only configmaps or secrets labeled like the following will be watched:
+
 ```yaml
 kind: ConfigMap
 apiVersion: v1
@@ -208,16 +216,18 @@ metadata:
   ...
 ```
 
-Reloader can be configured to only watch namespaces labeled with one or more labels using the `--namespace-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (ie. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors). 
+Reloader can be configured to only watch namespaces labeled with one or more labels using the `--namespace-selector` parameter. Supported operators are `!, in, notin, ==, =, !=`, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the [Kubernetes Docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors).
 
 **Note:** The old `:` delimited key value mappings are deprecated and if provided will be translated to `key=value`. Likewise, if a wildcard value is provided (e.g. `key:*`) it will be translated to the standalone `key` which checks for key existence.
 
 These selectors can be combined together, for example with:
-```
+
+```yaml
 --namespace-selector=reloader=enabled,test=true
 ```
 
 Only namespaces labeled as below would be watched and eligible for reloads:
+
 ```yaml
 kind: Namespace
 apiVersion: v1
@@ -229,7 +239,7 @@ metadata:
   ...
 ```
 
-### Vanilla kustomize
+### Vanilla Kustomize
 
 You can also apply the vanilla manifests by running the following command
 
@@ -255,7 +265,7 @@ namespace: reloader
 
 ### Helm Charts
 
-Alternatively if you have configured helm on your cluster, you can add reloader to helm from our public chart repository and deploy it via helm using below mentioned commands. Follow [this](docs/Helm2-to-Helm3.md) guide, in case you have trouble migrating reloader from Helm2 to Helm3
+Alternatively if you have configured helm on your cluster, you can add Reloader to helm from our public chart repository and deploy it via helm using below-mentioned commands. Follow [this](docs/Helm2-to-Helm3.md) guide, in case you have trouble migrating Reloader from Helm2 to Helm3.
 
 ```bash
 helm repo add stakater https://stakater.github.io/stakater-charts
@@ -265,7 +275,7 @@ helm repo update
 helm install stakater/reloader # For helm3 add --generate-name flag or set the release name
 ```
 
-**Note:** By default reloader watches in all namespaces. To watch in single namespace, please run following command. It will install reloader in `test` namespace which will only watch `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts` in `test` namespace.
+**Note:** By default Reloader watches in all namespaces. To watch in single namespace, please run following command. It will install Reloader in `test` namespace which will only watch `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts` in `test` namespace.
 
 ```bash
 helm install stakater/reloader --set reloader.watchGlobally=false --namespace test # For helm3 add --generate-name flag or set the release name
@@ -284,36 +294,38 @@ Reloader can be configured to only watch namespaces labeled with one or more lab
 
 | Parameter            | Description                                                                        | Type    |
 | ----------------     | ---------------------------------------------------------------------------------- | ------- |
-| namespaceSelector    | list of comma separated label selectors, if mulitple are provided they are ANDed   | string  |
+| namespaceSelector    | list of comma separated label selectors, if multiple are provided they are combined with the AND operator | string  |
 
 Reloader can be configured to only watch configmaps/secrets labeled with one or more labels using the `resourceLabelSelector` parameter
 
 | Parameter              | Description                                                                        | Type    |
 | ---------------------- | ---------------------------------------------------------------------------------- | ------- |
-| resourceLabelSelector  | list of comma separated label selectors, if mulitple are provided they are ANDed   | string  |
+| resourceLabelSelector  | list of comma separated label selectors, if multiple are provided they are combined with the AND operator | string  |
 
-**Note:** Both `namespaceSelector` & `resourceLabelSelector` can be used together. If they are then both conditions must be met for the configmap or secret to be eligible to trigger reload events. (e.g. If a configMap matches `resourceLabelSelector` but `namespaceSelector` does not match the namespace the configmap is in, it will be ignored)
+**Note:** Both `namespaceSelector` & `resourceLabelSelector` can be used together. If they are then both conditions must be met for the configmap or secret to be eligible to trigger reload events. (e.g. If a configMap matches `resourceLabelSelector` but `namespaceSelector` does not match the namespace the configmap is in, it will be ignored).
 
-You can also set the log format of Reloader to json by setting `logFormat` to `json` in values.yaml and apply the chart
+You can also set the log format of Reloader to json by setting `logFormat` to `json` in values.yaml and apply the chart.
 
-You can enable to scrape Reloader's Prometheus metrics by setting `serviceMonitor.enabled` or `podMonitor.enabled`  to `true` in values.yaml file. Service monitor will be removed in future releases of reloader in favour of Pod monitor.
+You can enable to scrape Reloader's Prometheus metrics by setting `serviceMonitor.enabled` or `podMonitor.enabled`  to `true` in values.yaml file. Service monitor will be removed in future releases of Reloader in favour of Pod monitor.
 
-**Note:** Reloading of OpenShift (DeploymentConfig) and/or Argo Rollouts has to be enabled explicitly because it might not be always possible to use it on a cluster with restricted permissions. This can be done by changing the following parameters:
+**Note:** Reloading of OpenShift (DeploymentConfig) and/or Argo `Rollouts` has to be enabled explicitly because it might not be always possible to use it on a cluster with restricted permissions. This can be done by changing the following parameters:
 
 | Parameter        | Description                                                                                                                              | Type    |
 |------------------|------------------------------------------------------------------------------------------------------------------------------------------| ------- |
 | isOpenshift      | Enable OpenShift DeploymentConfigs. Valid value are either `true` or `false`                                                             | boolean |
-| isArgoRollouts   | Enable Argo Rollouts. Valid value are either `true` or `false`                                                                           | boolean |
+| isArgoRollouts   | Enable Argo `Rollouts`. Valid value are either `true` or `false`                                                                           | boolean |
 | reloadOnCreate   | Enable reload on create events. Valid value are either `true` or `false`                                                                 | boolean |
-| syncAfterRestart | Enable sync after reloader restarts for **Add** events, works only when reloadOnCreate is `true`. Valid value are either `true` or `false` | boolean |
+| syncAfterRestart | Enable sync after Reloader restarts for **Add** events, works only when reloadOnCreate is `true`. Valid value are either `true` or `false` | boolean |
 
 **ReloadOnCreate** reloadOnCreate controls how Reloader handles secrets being added to the cache for the first time. If reloadOnCreate is set to true:
-* Configmaps/secrets being added to the cache will cause Reloader to perform a rolling update of the associated workload. 
-* When applications are deployed for the first time, Reloader will perform a rolling update of the associated workload. 
-* If you are running Reloader in HA mode all workloads will have a rolling update performed when a new leader is elected. 
 
-If ReloadOnCreate is set to false: 
-* Updates to configMaps/Secrets that occur while there is no leader will not be picked up by the new leader until a subsequent update of the configmap/secret occurs. In the worst case the window in which there can be no leader is 15s as this is the LeaseDuration.
+- Configmaps/secrets being added to the cache will cause Reloader to perform a rolling update of the associated workload.
+- When applications are deployed for the first time, Reloader will perform a rolling update of the associated workload.
+- If you are running Reloader in HA mode all workloads will have a rolling update performed when a new leader is elected.
+
+If ReloadOnCreate is set to false:
+
+- Updates to configMaps/Secrets that occur while there is no leader will not be picked up by the new leader until a subsequent update of the configmap/secret occurs. In the worst case the window in which there can be no leader is 15s as this is the LeaseDuration.
 
 ## Help
 
@@ -341,17 +353,17 @@ Please use the [issue tracker](https://github.com/stakater/Reloader/issues) to r
 ### Developing
 
 1. Deploy Reloader.
-2. Run `okteto up` to activate your development container.
-3. `make build`.
-4. `./Reloader`
+1. Run `okteto up` to activate your development container.
+1. `make build`.
+1. `./Reloader`
 
 PRs are welcome. In general, we follow the "fork-and-pull" Git workflow.
 
-1.  **Fork** the repo on GitHub
-2.  **Clone** the project to your own machine
-3.  **Commit** changes to your own branch
-4.  **Push** your work back up to your fork
-5.  Submit a **Pull request** so that we can review your changes
+1. **Fork** the repo on GitHub
+1. **Clone** the project to your own machine
+1. **Commit** changes to your own branch
+1. **Push** your work back up to your fork
+1. Submit a **Pull request** so that we can review your changes
 
 **NOTE:** Be sure to merge the latest from "upstream" before making a pull request!
 
diff --git a/docs/Alerting.md b/docs/Alerting.md
index f9ed7b6..3b41112 100644
--- a/docs/Alerting.md
+++ b/docs/Alerting.md
@@ -1,12 +1,18 @@
 # Alerting on Reload
-Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information   
 
-#### Enabling the feature
-In-order to enable this feature, you need to update the reloader.env.secret section of values.yaml providing the information needed for alert. 
-<pre>      ALERT_ON_RELOAD: [ true/false ] Default: false 
+Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information.
+
+## Enabling the feature
+
+In-order to enable this feature, you need to update the `reloader.env.secret` section of values.yaml providing the information needed for alert.
+
+```yaml
+      ALERT_ON_RELOAD: [ true/false ] Default: false 
       ALERT_SINK: [ slack/webhook ] Default: webhook
       ALERT_WEBHOOK_URL: Required if ALERT_ON_RELOAD is true
       ALERT_ADDITIONAL_INFO: Any additional information to be added to alert
+```
 
-#### Slack incoming-webhook creation docs
-https://api.slack.com/messaging/webhooks 
+## Slack incoming-webhook creation docs
+
+[Sending messages using Incoming Webhooks](https://api.slack.com/messaging/webhooks)
diff --git a/docs/Container Build.md b/docs/Container Build.md
index 61344f8..d48d438 100644
--- a/docs/Container Build.md	
+++ b/docs/Container Build.md	
@@ -1,41 +1,53 @@
-
 # Container Build
-> **WARNING:** As a user of Reloader there is no need to build containers, these are freely available here: https://hub.docker.com/r/stakater/reloader/
 
-Multi-architecture approach is based on original work by @mdh02038: https://github.com/mdh02038/Reloader
+> **WARNING:** As a user of Reloader there is no need to build containers, the open source version is available on [Docker Hub](https://hub.docker.com/r/stakater/reloader/).
 
-Images tested on linux/arm, linux/arm64 and linux/amd64.
+Multi-architecture approach is based on original work by [@mdh02038](https://github.com/mdh02038/Reloader).
 
-# Install Pre-Reqs
-The build environment requires the following packages (tested on Ubuntu 20.04):
-* golang
-* make
-* qemu (for arm, arm64 etc. emulation)
+Images are tested on linux/arm, linux/arm64 and linux/amd64.
+
+## Install Pre-Reqs
+
+The build environment requires the following packages (tested on `Ubuntu 20.04`):
+
+* Golang
+* `make`
+* `qemu` (for arm, arm64 etc. emulation)
 * binfmt-support
 * Docker engine
 
 ## Docker
-Follow instructions here: https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository
+
+Follow instructions on [Install using the apt repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository).
 
 Once installed, enable the experimental CLI:
-```
+
+```bash
 export DOCKER_CLI_EXPERIMENTAL=enabled
 ```
-Login, to enable publishing of packages:
-```
+
+Login to enable publishing of packages:
+
+```bash
 sudo docker login
 ```
+
 ## Remaining Pre-Reqs
+
 Remaining Pre-Reqs can be installed via:
-```
+
+```bash
 sudo apt install golang make qemu-user-static binfmt-support -y
 ```
 
-# Publish Multi-Architecture Image
+## Publish Multi-Architecture Image
+
 To build/ publish multi-arch Docker images clone repository and execute from repository root:
-```
+
+```bash
 sudo make release-all
 ```
 
-# Additional Links/ Info
-* *https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408
\ No newline at end of file
+## Additional Links/Info
+
+[Building Multi-Architecture Docker Images With `Buildx`](https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408)
diff --git a/docs/Helm2-to-Helm3.md b/docs/Helm2-to-Helm3.md
index 91f11fa..0b3fe6b 100644
--- a/docs/Helm2-to-Helm3.md
+++ b/docs/Helm2-to-Helm3.md
@@ -1,12 +1,13 @@
 # Helm2 to Helm3 Migration
 
-Follow below mentioned instructions to migrate reloader from Helm2 to Helm3
+Follow below-mentioned instructions to migrate Reloader from Helm2 to Helm3
 
-## Instrcutions:
+## Instructions
 
-There are 3 steps involved in migrating the reloader from Helm2 to Helm3.
+There are 3 steps involved in migrating the Reloader from Helm2 to Helm3.
+
+### Step 1
 
-### Step 1:
 Install the helm-2to3 plugin
 
 ```bash
@@ -17,15 +18,18 @@ helm3 2to3 convert <release-name>
 helm3 2to3 cleanup --release-cleanup --skip-confirmation
 ```
 
-### Step 2:
-Add the following Helm3 labels and annotations on reloader resources.
+### Step 2
+
+Add the following Helm3 labels and annotations on Reloader resources.
 
 Label:
 
 ```yaml
 app.kubernetes.io/managed-by=Helm
 ```
+
 Annotations:
+
 ```yaml
 meta.helm.sh/release-name=<release-name>
 meta.helm.sh/release-namespace=<namespace>
@@ -51,12 +55,14 @@ kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
 kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm
 ```
 
-### Step 3:
+### Step 3
+
 Upgrade to desired version
+
 ```bash
 helm3 repo add stakater https://stakater.github.io/stakater-charts
 
 helm3 repo update
 
 helm3 upgrade <release-name> stakater/reloader --version=v0.0.72
-```
\ No newline at end of file
+```
diff --git a/docs/How-it-works.md b/docs/How-it-works.md
index 37bde02..547c4c4 100644
--- a/docs/How-it-works.md
+++ b/docs/How-it-works.md
@@ -1,6 +1,6 @@
 # How it works?
 
-Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`.
+Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection Reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`.
 
 ## How change detection works
 
@@ -13,37 +13,35 @@ To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must hav
 - support for rolling upgrade strategy
 - specific annotation for `configmaps` or `secrets`
 
-The annotation value is comma separated list of `configmaps` or `secrets`. If a change is detected in data of these `configmaps` or `secrets`, reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
+The annotation value is comma separated list of `configmaps` or `secrets`. If a change is detected in data of these `configmaps` or `secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
 
 ### Annotation for Configmap
 
-For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`
+For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`, where the default annotation can be changed with the `--configmap-annotation` flag:
 
 ```yaml
 metadata:
   annotations:
     configmap.reloader.stakater.com/reload: "foo"
 ```
-<small>*the default annotation can be changed with the `--configmap-annotation` flag</small>
 
 ### Annotation for Secret
 
-For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation* to your `Deployment`
+For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation to your `Deployment`, where the default annotation can be changed with the `--secret-annotation` flag:
 
 ```yaml
 metadata:
   annotations:
     secret.reloader.stakater.com/reload: "foo"
 ```
-<small>*the default annotation can be changed with the `--secret-annotation` flag</small>
 
 Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Rollouts`
 
 ## How Rolling upgrade works?
 
-When reloader detects changes in configmap. It gets two objects of configmap. First object is an old configmap object which has a state before the latest change. Second object is new configmap object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If reloader finds any change in new configmap object, only then, it move forward with rolling upgrade.
+When Reloader detects changes in configmap. It gets two objects of configmap. First object is an old configmap object which has a state before the latest change. Second object is new configmap object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new configmap object, only then, it moves forward with rolling upgrade.
 
-After that, reloader gets the list of all deployments, daemonsets and statefulset and looks for above mentioned annotation for configmap. If the annotation value contains the configmap name, it then looks for an environment variable which can contain the configmap or secret data change hash.
+After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for configmap. If the annotation value contains the configmap name, it then looks for an environment variable which can contain the configmap or secret data change hash.
 
 ### Environment variable for Configmap
 
@@ -61,7 +59,7 @@ If Secret name is foo then
 STAKATER_FOO_SECRET
 ```
 
-If the environment variable is found then it gets its value and compares it with new configmap hash value. If old value in environment variable is different from new hash value then reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from configmap and updates the relevant `deployment`, `daemonset` or `statefulset`
+If the environment variable is found then it gets its value and compares it with new configmap hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from configmap and updates the relevant `deployment`, `daemonset` or `statefulset`
 
 Note: Rolling upgrade also works in the same way for secrets.
 
@@ -71,12 +69,14 @@ Reloader uses SHA1 to compute hash value. SHA1 is used because it is efficient a
 
 ## Monitor All Namespaces
 
-By default reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader`
-And render manifest file using helm command
+By default Reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the Reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader` and render manifest file using helm command:
+
 ```bash
 helm --namespace {replace this with namespace name} template . > reloader.yaml
 ```
-The output file can then be used to deploy reloader in specific namespace.
+
+The output file can then be used to deploy Reloader in specific namespace.
 
 ## Compatibility with helm install and upgrade
-Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of configmap's or secret's data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.
+
+Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in  `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of configmap's or secret's data. So  if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.
diff --git a/docs/Reloader-vs-k8s-trigger-controller.md b/docs/Reloader-vs-k8s-trigger-controller.md
index e9b64a9..7fea476 100644
--- a/docs/Reloader-vs-k8s-trigger-controller.md
+++ b/docs/Reloader-vs-k8s-trigger-controller.md
@@ -5,36 +5,42 @@ Reloader and k8s-trigger-controller are both built for same purpose. So there ar
 ## Similarities
 
 - Both controllers support change detection in configmap and secrets
-- Both controllers support deployment rollout
+- Both controllers support deployment `rollout`
 - Both controllers use SHA1 for hashing
 - Both controllers have end to end as well as unit test cases.
 
 ## Differences
 
-### Support for Daemonsets and Statefulsets.
+### Support for `Daemonsets` and `Statefulsets`
 
-#### k8s-trigger-controller:
-k8s-trigger-controller only support for deployment rollout. It does not support daemonsets and statefulsets rollout.
+#### `k8s-trigger-controller`
 
-#### Reloader:
-Reloader supports deployment rollout as well as daemonsets and statefulsets rollout.
+`k8s-trigger-controller` only support for deployment `rollout`. It does not support `daemonsets` and `statefulsets` `rollout`.
+
+#### Reloader
+
+Reloader supports deployment `rollout` as well as `daemonsets` and `statefulsets` `rollout`.
 
 ### Hashing usage
 
-#### k8s-trigger-controller:
-k8s-trigger-controller stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash`
+#### `k8s-trigger-controller`
+
+`k8s-trigger-controller` stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash`
+
+#### Reloader
 
-#### Reloader:
 Reloader stores the hash value in an environment variable `STAKATER_NAME_[SECRET|CONFIGMAP]`
 
 ### Customization
 
-#### k8s-trigger-controller:
-k8s-trigger-controller restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation
+#### `k8s-trigger-controller`
+
+`k8s-trigger-controller` restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation
+
+#### Reloader
 
-#### Reloader:
 Reloader allows you to customize the annotation to fit your needs with command line flags:
 
 - `--auto-annotation <annotation>`
 - `--configmap-annotation <annotation>`
-- `--secret-annotation <annotation>`
\ No newline at end of file
+- `--secret-annotation <annotation>`
diff --git a/docs/Reloader-with-Sealed-Secrets.md b/docs/Reloader-with-Sealed-Secrets.md
index 86a109e..363bc5b 100644
--- a/docs/Reloader-with-Sealed-Secrets.md
+++ b/docs/Reloader-with-Sealed-Secrets.md
@@ -1,11 +1,14 @@
-Below are the steps to use reloader with Sealed Secrets.
-1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets).
-2. Install the controller for sealed secrets
-3. Fetch the encryption certificate
-4. Encrypt the secret.
-5. Apply the secret.
-7. Install the tool which uses that sealed secret.
-8. Install Reloader.
-9. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see reloader working.
-10. Apply the updated sealed secret.
-11. Reloader will restart the pod to use that updated secret.
+# Using Reloader with Sealed Secrets
+
+Below are the steps to use Reloader with Sealed Secrets:
+
+1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets)
+1. Install the controller for sealed secrets
+1. Fetch the encryption certificate
+1. Encrypt the secret
+1. Apply the secret
+1. Install the tool which uses that sealed secret
+1. Install Reloader
+1. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see Reloader working
+1. Apply the updated sealed secret
+1. Reloader will restart the pod to use that updated secret
diff --git a/docs/Verify-Reloader-Working.md b/docs/Verify-Reloader-Working.md
index af27daa..8beb3a5 100644
--- a/docs/Verify-Reloader-Working.md
+++ b/docs/Verify-Reloader-Working.md
@@ -4,7 +4,7 @@ Reloader's working can be verified by three ways.
 
 ## Verify from logs
 
-Check the logs of reloader and verify that you can see logs looks like below, if you are able to find these logs then it means reloader is working.
+Check the logs of Reloader and verify that you can see logs looks like below, if you are able to find these logs then it means Reloader is working.
 
 ```text
 Changes Detected in test-object of type 'SECRET' in namespace: test-reloader
@@ -22,11 +22,11 @@ Below are the details that explain these logs:
 
 `SECRET` is the type of `test-object`. It can either be `SECRET` or `CONFIGMAP`
 
-### test-reloader
+### `test-reloader`
 
-`test-reloader` is the name of namespace in which reloader has detected the change.
+`test-reloader` is the name of namespace in which Reloader has detected the change.
 
-### test-resource
+### `test-resource`
 
 `test-resource` is the name of resource which is going to be updated
 
@@ -36,26 +36,27 @@ Below are the details that explain these logs:
 
 ## Verify by checking the age of Pod
 
-A pod's age can tell whether reloader is working correctly or not. If you know that a change in a `secret` or `configmap` has occurred, then check the relevant Pod's age immediately. It should be newly created few moments ago.
+A pod's age can tell whether Reloader is working correctly or not. If you know that a change in a `secret` or `configmap` has occurred, then check the relevant Pod's age immediately. It should be newly created few moments ago.
 
-### Verify from kubernetes Dashboard
+### Verify from Kubernetes Dashboard
 
 `kubernetes dashboard` can be used to verify the working of Reloader. After a change in `secret` or `configmap`, check the relevant Pod's age from dashboard. It should be newly created few moments ago.
 
 ### Verify from command line
 
-After a change in `secret` or `configmap`. Run the below mentioned command and verify that the pod is newly created.
+After a change in `secret` or `configmap`. Run the below-mentioned command and verify that the pod is newly created.
 
 ```bash
 kubectl get pods <pod name> -n <namespace name>
 ```
 
 ## Verify from metrics
-Some metrics are exported to prometheus endpoint `/metrics` on port `9090`.
 
-When reloader is unable to reload, `reloader_reload_executed_total{success="false"}` metric gets incremented and when it reloads successfully, `reloader_reload_executed_total{success="true"}` gets incremented. You will be able to see the following metrics, with some other metrics, at `/metrics` endpoint.
+Some metrics are exported to Prometheus endpoint `/metrics` on port `9090`.
 
-```
+When Reloader is unable to reload, `reloader_reload_executed_total{success="false"}` metric gets incremented and when it reloads successfully, `reloader_reload_executed_total{success="true"}` gets incremented. You will be able to see the following metrics, with some other metrics, at `/metrics` endpoint.
+
+```text
 reloader_reload_executed_total{success="false"} 15
 reloader_reload_executed_total{success="true"} 12
 ```
diff --git a/docs/features.md b/docs/features.md
index 3bcd395..4a2d026 100644
--- a/docs/features.md
+++ b/docs/features.md
@@ -2,7 +2,7 @@
 
 These are the key features of Reloader:
 
-1. Restart pod in a deployment on change in linked/related configmap's or secret's
-2. Restart pod in a daemonset on change in linked/related configmap's or secret's
-3. Restart pod in a statefulset on change in linked/related configmap's or secret's
-4. Restart pod in a rollout on change in linked/related configmap's or secret's
+1. Restart pod in a `deployment` on change in linked/related configmap's or secret's
+1. Restart pod in a `daemonset` on change in linked/related configmap's or secret's
+1. Restart pod in a `statefulset` on change in linked/related configmap's or secret's
+1. Restart pod in a `rollout` on change in linked/related configmap's or secret's
diff --git a/vocabulary b/vocabulary
new file mode 160000
index 0000000..899bf2d
--- /dev/null
+++ b/vocabulary
@@ -0,0 +1 @@
+Subproject commit 899bf2db35556f2e1abf5452081b7c3ad8f1765a