diff --git a/sig-architecture/api-review-process.md b/sig-architecture/api-review-process.md
index a7c281c0b..989de05f6 100644
--- a/sig-architecture/api-review-process.md
+++ b/sig-architecture/api-review-process.md
@@ -20,7 +20,7 @@ Because expert reviewer bandwidth is extremely limited, the process provides a c
 
 * Maintain the high standards of the project, including positive user interactions with APIs
 
-* Provide review regardless of method of API defininition (built-in, Extension API Server, or Custom Resource Definition)
+* Provide review regardless of method of API definition (built-in, Extension API Server, or Custom Resource Definition)
 
 * Provide review over both tightly coupled external projects and in-tree API changes.  
 
diff --git a/sig-scalability/slos/network_programming_latency.md b/sig-scalability/slos/network_programming_latency.md
index 38eeebf0c..dc1dace20 100644
--- a/sig-scalability/slos/network_programming_latency.md
+++ b/sig-scalability/slos/network_programming_latency.md
@@ -60,7 +60,7 @@ this update:
   already present at storage layer, so it won't be hard to propagate that.
 1. The in-cluster load-balancing programmer will export a prometheus metric
 once done with programming. The latency of the operation is defined as
-difference betweem timestamp of then whe operation is done and timestamp
+difference between timestamp of then whe operation is done and timestamp
 recorded in the newly introduced annotation.
 
 #### Caveats
diff --git a/sig-scalability/slos/pod_startup_latency.md b/sig-scalability/slos/pod_startup_latency.md
index 04fdd63b0..7c52777ee 100644
--- a/sig-scalability/slos/pod_startup_latency.md
+++ b/sig-scalability/slos/pod_startup_latency.md
@@ -38,7 +38,7 @@ is heavily application-dependent (and does't depend on Kubernetes itself).
 not obvious. We decided for the semantic of "when all its containers are
 reported as started and observed via watch", because:
   - we require all containers to be started (not e.g. the first one) to ensure
-    that the pod is started. We need to ensure that pontential regressions like
+    that the pod is started. We need to ensure that potential regressions like
     linearization of container startups within a pod will be catch by this SLI.
   - note that we don't require all container to be running - if some of them
     finished before the last one was started that is also fine. It is just
diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md
index 5b9fb4bff..1f9a15c82 100644
--- a/sig-scalability/slos/slos.md
+++ b/sig-scalability/slos/slos.md
@@ -27,7 +27,7 @@ Our SLIs/SLOs need to have the following properties:
   arcane knowledge.
 
 We may also introduce internal(for developers only) SLIs, that may be useful
-for understanding performance characterstic of the system, but for which
+for understanding performance characteristic of the system, but for which
 we don't provide any guarantees for users (and thus don't require them to be
 that easily understandable).