Merge pull request #3590 from embik/docs-typos

Fix some minor documentation typos

Author: kcp-ci-bot

docs/content/concepts/quickstart-tenancy-and-apis.md

@@ -407,7 +407,7 @@ Within a multi-sharded kcp, each shard will offer its own service endpoint URL f
 
 If an `APIExportEndpointSlice` does not reference a `Partition` all the available endpoints are populated in its `status`. More on `Partitions` [here](./sharding/partitions.md).
 
-By default, kcp creates a non-partioned `APIExportEndpointSlice` for every `APIExport`.
+By default, kcp creates a non-partitioned `APIExportEndpointSlice` for every `APIExport`.
 
 ```sh
 kubectl get apiexportendpointslice/wildwest.dev -o yaml

docs/content/contributing/governance/security-self-assessment.md

@@ -55,7 +55,7 @@ The kcp architecture is composed of several key primitives that work together to
 
 * **Logical Clusters**: The underlying implementation construct for a Workspace. A logical cluster is a logical partition within the kcp data store (etcd), ensuring that objects from different workspaces are stored in disjoint key prefixes, which is the primary mechanism for enforcing isolation. The goal is to make creating a logical cluster as cheap and fast as creating a Kubernetes namespace.
 
-* **Virtual Workspaces**: Endpoints that provide a Kubernetes-like API interface, but are not backed by a logical cluster for storage. They provide a computed "view" of certain resources across logical clusters. The exact semantics depend on the virtual workspace implementation, diferent virtual workspace endpoints provide different views according to their role. Access to virtual workspace endpoint is guarded by RBAC.
+* **Virtual Workspaces**: Endpoints that provide a Kubernetes-like API interface, but are not backed by a logical cluster for storage. They provide a computed "view" of certain resources across logical clusters. The exact semantics depend on the virtual workspace implementation, different virtual workspace endpoints provide different views according to their role. Access to virtual workspace endpoint is guarded by RBAC.
 
 * **Shards**: A running instance of the kcp server process. Each shard hosts a set of logical clusters, and a full kcp installation can be composed of many shards to achieve horizontal scalability.
 

docs/content/contributing/guides/rebasing-kubernetes.md

@@ -150,7 +150,7 @@ can move on to the next commit because there were no changes to the
 files that commit touched between the two kube versions.
 
 Additionally `view_changed_files` only shows the changes of the
-currently cherry-picked commit to files that were changed betwene the
+currently cherry-picked commit to files that were changed between the
 two kube versions.
 
 7. Cherry-pick each commit one by one.
@@ -182,7 +182,7 @@ two kube versions.
     hack/pin-dependency.sh github.com/kcp-dev/client-go kcp-1.33.3
     ```
 
-13. Commmit the dependency updates:
+13. Commit the dependency updates:
     ```
     git add .
     git commit -m 'CARRY: <drop>: Add KCP dependencies'