Documentation: Fix a few typos

Documentation/design/building-your-csv.md

@@ -190,7 +190,7 @@ It’s recommended to only list out the objects that are important to a human, n
 Essentially the same as for owned CRDs.
 
 ### APIService Resource Creation
-The Lifecycle Manage is responsible for creating or replacing the Service and APIService resources for each unique owned APIService.
+The Lifecycle Manager is responsible for creating or replacing the Service and APIService resources for each unique owned APIService.
 * Service pod selectors are copied from the CSV deployment matching the APIServiceDescription's DeploymentName.
 * A new CA key/cert pair is generated for for each installation and the base64 encoded CA bundle is embedded in the respective APIService resource.
 

Documentation/design/developing.md

@@ -55,7 +55,7 @@ kubectl apply -f ./custom-olm
     * do not overwrite the old one
 * Add any new CRDs to `deploy/chart/catalog_resources/<catalog>`
 * run `make update-catalog` to regen the catalog configmap
-* either apply the new configmap on it's own and restart catalog or, easier, just run:
+* either apply the new configmap on its own and restart the catalog or, easier, just run:
 
 ```sh
 ./scripts/package_release.sh 1.0.0-custom custom-olm ./Documentation/install/example-values.yaml

Documentation/design/operatorgroups.md

@@ -6,7 +6,7 @@ An `OperatorGroup` is an OLM resource that provides rudimentary multitenant conf
 
 * An `OperatorGroup` selects a set of target namespaces in which to generate required RBAC access for its member operators.
 * The set of target namespaces is provided via a comma-delimited string stored in the `olm.targetNamespaces` annotation. This annotation is applied to member operator's `ClusterServiceVersion` (CSV) instances and is projected into their deployments. It is accessible to operator containers using [The Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
-* An operator is said to be a [member of an `OperatorGroup`](#operatorgroup-membership) if its CSV exists in the same namespace as the `OperatorGroup` and its CSV's [`InstallModes` support the set of namespaces targetted by the `OperatorGroup`](#installmodes-and-supported-operatorgroups)
+* An operator is said to be a [member of an `OperatorGroup`](#operatorgroup-membership) if its CSV exists in the same namespace as the `OperatorGroup` and its CSV's [`InstallModes` support the set of namespaces targeted by the `OperatorGroup`](#installmodes-and-supported-operatorgroups)
 * In order to transition, a CSV must be an active member of an `OperatorGroup` that has no [provided API conflicts with intersecting `OperatorGroups`](#operatorgroup-intersection)
 
 ## OperatorGroup Membership
@@ -27,15 +27,15 @@ An `InstallMode` consists of an `InstallModeType` field and a boolean `Supported
 * `MultiNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects more than one namespace
 * `AllNamespaces`: If supported, the operator can be a member of an `OperatorGroup` that selects all namespaces (target namespace set is the empty string "")
 
-> Note: If a CSV's spec omit's an entry of `InstallModeType`, that type is considered unsupported unless support can be inferred by an existing entry that implicitly supports it.
+> Note: If a CSV's spec omits an entry of `InstallModeType`, that type is considered unsupported unless support can be inferred by an existing entry that implicitly supports it.
 
 ### UnsupportedOperatorGroup
 
 If a CSV's `InstallMode`s do not support the target namespace selection of the `OperatorGroup` in its namespace, the CSV will transition to a failure state with reason `UnsupportedOperatorGroup`. CSVs in a failed state for this reason will transition to pending once either the `OperatorGroups`'s target namespace selection changes to a supported configuration, or the CSV's `InstallMode`s are modified to support the `OperatorGroup`'s target namespace selection.
 
 ## Target Namespace Selection
 
-Selection of the set of namespaces by specifying a label selector with the `spec.selector` field:
+Select the set of namespaces by specifying a label selector with the `spec.selector` field:
 
 ```yaml
 apiVersion: operators.coreos.com/v1alpha2

Documentation/design/philosophy.md

@@ -160,11 +160,11 @@ We have two major components that handle the resources described above
 
 **What if I want lifecycle/packaging/discovery for kubernetes, but don't want to write an operator?**
 
-If you don't want to write an operator, the thing you want to package probably fits one of the standard shapes of software that can be deployed on a cluster. You can take advantage of OLM by writing a package the binds your application to one of our standard operators, like [helm-app-operator-kit](https://github.com/coreos/helm-app-operator-kit).
+If you don't want to write an operator, the thing you want to package probably fits one of the standard shapes of software that can be deployed on a cluster. You can take advantage of OLM by writing a package that binds your application to one of our standard operators, like [helm-app-operator-kit](https://github.com/coreos/helm-app-operator-kit).
 
 If your use-case doesn't fit one of our standard operators, that means you have domain-specific operational knowledge you need to encode into an operator, and you can take advantage of our Operator SDK for common operator tasks.
 
-**Why are dependencies between operators are expressed as a dependency on a CRD?**
+**Why are dependencies between operators expressed as a dependency on a CRD?**
 
 This decouples the actual dependency from the operation of the dependency. For example, Vault requires an EtcdCluster, but we should be able to update the etcd operator out of step with the vault operator.