Added some more nit fixes to the documentation.

content/en/docs/Tasks/creating-operator-bundle.md

@@ -73,7 +73,7 @@ etcd
 The `annotations.yaml` contains the following information as labels that are used to annotate the operator bundle container image:
 
 * The label `operators.operatorframework.io.bundle.mediatype.v1` reflects the media type or format of the operator bundle. It could be helm charts, plain Kubernetes manifests etc.
-* The label `operators.operatorframework.io.bundle.manifests.v1 `reflects the path in the image to the directory that contains the operator manifests. This label is reserved for the future use and is set to `manifests/` for the time being.
+* The label `operators.operatorframework.io.bundle.manifests.v1` reflects the path in the image to the directory that contains the operator manifests. This label is reserved for the future use and is set to `manifests/` for the time being.
 * The label `operators.operatorframework.io.bundle.metadata.v1` reflects the path in the image to the directory that contains metadata files about the bundle. This label is reserved for the future use and is set to `metadata/` for the time being.
 * The `manifests.v1` and `metadata.v1` labels imply the bundle type:
     * The value `manifests.v1` implies that this bundle contains operator manifests.

content/en/docs/Tasks/creating-operator-manifests.md

@@ -240,7 +240,7 @@ The absence of any required `nativeAPIs` from a cluster will pause the installat
 
 TODO: example status
 
-`nativeAPIs` is an optional field, but the more information you give OLM about the context in which your operator should be run, the more informed decisions OLM can make.
+`nativeAPIs` is an optional field, but the more information you give OLM about the context in which your operator should be running, the more informed decisions OLM can make.
 
 ## Packaging Additional Objects Alongside an Operator
 
@@ -257,7 +257,7 @@ Operators can include additional objects alongside their `CSV` in the `/manifest
 - PrometheusRule
 - ServiceMonitor
 - [PodDisruptionBudget](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-pod-disruption-budgets.md)
-- [PriorityClasse](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-priority-classes.md)
+- [PriorityClass](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-priority-classes.md)
 - [VerticalPodAutoscaler](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-vertical-pod-autoscaler.md)
 - ConsoleYAMLSample
 - ConsoleQuickStart

content/en/docs/Tasks/install-operator-with-olm.md

@@ -134,7 +134,7 @@ spec:
 
 Notice that `approval` has been set to `Manual` as well in order to keep OLM from immediately updating your Operator, if `1.1.0` happens to be superseded by a newer version in `my-catalog`. Follow the instructions from the [previous example](#example-install-the-latest-version-of-an-operator) to approve the initial `InstallPlan` for this `Subscription`, so `1.1.0` is allowed to be installed.
 
-If your intent is to pin an installed Operator to the particular version `1.1.0` you don't need to do anything. After approving the initial `InstallPlan` OLM will install version `1.1.0` of your Operator and keep it at that version. When updates are discovered in the catalog, OLM will wait not proceed unless you manual approve the update.
+If your intent is to pin an installed Operator to the particular version `1.1.0` you don't need to do anything. After approving the initial `InstallPlan` OLM will install version `1.1.0` of your Operator and keep it at that version. When updates are discovered in the catalog, OLM will wait not proceed unless you manually approve the update.
 
 [create-catsrc-doc]: /docs/tasks/make-catalog-available-on-cluster
 [subscription-doc]: /docs/concepts/crds/subscription