diff --git a/contributors/design-proposals/storage/grow-volume-size.md b/contributors/design-proposals/storage/grow-volume-size.md
index 4ef2ab2c6..e43680bdd 100644
--- a/contributors/design-proposals/storage/grow-volume-size.md
+++ b/contributors/design-proposals/storage/grow-volume-size.md
@@ -78,7 +78,7 @@ new controller will be:
   for same volume then resize request will be pending and retried once previous resize request has completed.
 * Controller resize in effect will be level based rather than edge based. If there are more than one pending resize request for same PVC then
   new resize requests for same PVC will replace older pending request.
-* Resize will be performed via volume plugin interface, executed inside a goroutine spawned by `operation_exectutor`.
+* Resize will be performed via volume plugin interface, executed inside a goroutine spawned by `operation_executor`.
 * A new plugin interface called `volume.Expander` will be added to volume plugin interface. The `Expander` interface
   will also define if volume requires a file system resize:
 
diff --git a/contributors/design-proposals/storage/local-storage-overview.md b/contributors/design-proposals/storage/local-storage-overview.md
index de1298a07..708f66008 100644
--- a/contributors/design-proposals/storage/local-storage-overview.md
+++ b/contributors/design-proposals/storage/local-storage-overview.md
@@ -213,7 +213,7 @@ The term `Partitions` are used here to describe the main use cases for local sto
     apiVersion: storage.k8s.io/v1
     metadata:
       name: local-fast
-    toplogyKey: kubernetes.io/hostname
+    topologyKey: kubernetes.io/hostname
     ```
     ```yaml
     kind: PersistentVolume
@@ -388,7 +388,7 @@ The term `Partitions` are used here to describe the main use cases for local sto
        - name: myEphemeralPersistentVolume
          mountPath: /mnt/tmpdata
      volumes:
-     - name: myEphemeralPeristentVolume
+     - name: myEphemeralPersistentVolume
        inline:
          spec:
            accessModes: [ "ReadWriteOnce" ]
diff --git a/contributors/design-proposals/storage/local-storage-pv.md b/contributors/design-proposals/storage/local-storage-pv.md
index d397c681c..524c04441 100644
--- a/contributors/design-proposals/storage/local-storage-pv.md
+++ b/contributors/design-proposals/storage/local-storage-pv.md
@@ -506,7 +506,7 @@ The boostrapper requires the following permissions:
 * Create ClusterRoleBindings
 * Create DaemonSet
 
-Since the boostrapper generates the DaemonSet spec, the ConfigMap can be simplifed to just specify the
+Since the boostrapper generates the DaemonSet spec, the ConfigMap can be simplified to just specify the
 host directories:
 
 ```
diff --git a/contributors/design-proposals/storage/mount-options.md b/contributors/design-proposals/storage/mount-options.md
index 099e86024..f0ab51b14 100644
--- a/contributors/design-proposals/storage/mount-options.md
+++ b/contributors/design-proposals/storage/mount-options.md
@@ -9,7 +9,7 @@ such as  - `nfs`, `glusterfs` or `aws-ebs` etc.
 
 We currently support network filesystems: NFS, Glusterfs, Ceph FS, SMB (Azure file), Quobytes, and local filesystems such as ext[3|4] and XFS.
 
-Mount time options that are operationally important and have no security implications should be suppported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more.
+Mount time options that are operationally important and have no security implications should be supported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more.
 
 ## Design
 
diff --git a/contributors/design-proposals/storage/pod-safety.md b/contributors/design-proposals/storage/pod-safety.md
index cca092929..3976e47b6 100644
--- a/contributors/design-proposals/storage/pod-safety.md
+++ b/contributors/design-proposals/storage/pod-safety.md
@@ -1,4 +1,4 @@
-# Pod Safety, Consistency Guarantees, and Storage Implicitions
+# Pod Safety, Consistency Guarantees, and Storage Implications
 
 @smarterclayton @bprashanth
 
diff --git a/contributors/design-proposals/testing/flakiness-sla.md b/contributors/design-proposals/testing/flakiness-sla.md
index b76be2f03..efed5e966 100644
--- a/contributors/design-proposals/testing/flakiness-sla.md
+++ b/contributors/design-proposals/testing/flakiness-sla.md
@@ -6,12 +6,12 @@ Agreement) for flakiness in our tests, as well as actions that we will
 take when we are out of SLA.
 
 ## Definition of "We"
+
 Throughout the document the term _we_ is used. This is intended to refer
 to the Kubernetes project as a whole, and any governance structures the
 project puts in place. It is not intended to refer to any specific group
 of individuals.
 
-
 ## Definition of a "Flake"
 
 We'll start by the definition of a _flake_. _Flakiness_ is defined for a