Fix typos in documentation

keps/0002-dynamic-instances.md

@@ -33,7 +33,7 @@ This KEP aims to make the end user experience for operators more specific to the
 
 Currently, the interface for using operators in KUDO is generic. Users create an `Instance` CRD with specs. Operator developers and users expect to be able to use contextual business objects for their operators instead of generic objects. This enables a more focused experience for users of KEP.
 
-The goal of this KEP is to improve the end user UX through dynamic instances. Other than the ability to specfiy CRDs, and adjusting existing operator development instances to accomodate this change, it is not the goal of this KEP to change the operator development UX.
+The goal of this KEP is to improve the end user UX through dynamic instances. Other than the ability to specfiy CRDs, and adjusting existing operator development instances to accommodate this change, it is not the goal of this KEP to change the operator development UX.
 
 ### Goals
 

keps/0005-cluster-resources-for-crds.md

@@ -83,7 +83,7 @@ should probably be created
 
 #### Story 4
 
-OperatorVersions require the existance of CRDs that are not controlled by Kudo (e.g. ETCD Operator) and require those to be installed when FV is enabled.
+OperatorVersions require the existence of CRDs that are not controlled by Kudo (e.g. ETCD Operator) and require those to be installed when FV is enabled.
 
 ### Implementation Details/Notes/Constraints [optional]
 

keps/0008-operator-testing.md

@@ -105,7 +105,7 @@ As an Application Operator, I...
 * Perhaps the most important consideration when building any testing pipeline is ensuring that developer velocity is not impacted. This is especially important for KUDO, since the developer experience for Operator developers is critical to the success of the project. To mitigate this, we need to optimize the runtime of the test suites and pull request flow. Operator contributions should only run tests for the Operators that are affected by the pull request. Tests should have a fixed upper time limit to prevent any new tests from causing excessive delays. Tests fail early.
 * If the test harness is not designed well, contributions to the project become very difficult or the harness does not get adopted by developers. We provide a minimal, declarative format for authoring tests to encourage adoption and provide simple ways to execute the tests to ensure that it is easy to get started.
 * The test harness is not valuable if no test cases are written. This means Operator developers need to write test cases! We encourage test case authoring by writing good documentation, integrating the test harness into the CI/CD pipeline, and potentially enacting policies around testing for official Operators. We can also advocate for testing via blogs and interactions with Operator developers.
-* As we take a declarative approach to testing, it's important to ensure that the abstractions built are not leaky. Leaky abstractions lead to greater complexity and make the test suite hard to use. We decrease this risk by narrowing the scope to focus on the state of Kubernetes objects in the Kubernetes API, refering to prior work (see [Alternatives](#Alternatives)), and building a minimal solution. We also will write tests for existing Operators and work with authors of new Operators to ensure that the solution is generally useful.
+* As we take a declarative approach to testing, it's important to ensure that the abstractions built are not leaky. Leaky abstractions lead to greater complexity and make the test suite hard to use. We decrease this risk by narrowing the scope to focus on the state of Kubernetes objects in the Kubernetes API, referring to prior work (see [Alternatives](#Alternatives)), and building a minimal solution. We also will write tests for existing Operators and work with authors of new Operators to ensure that the solution is generally useful.
 
 ## Proposal