[release-1.12] 📖 docs: fix typos and docs formatting improvements

CONTRIBUTING.md

@@ -75,7 +75,7 @@ Cluster API follows upstream Kubernetes semantic versioning. With the v1 release
 
 - A (*patch*) release SHOULD only include backwards compatible set of bugfixes.
 
-see [Cluster API release support](https://cluster-api.sigs.k8s.io/reference/versions.html#cluster-api-release-support)) for
+see [Cluster API release support](https://cluster-api.sigs.k8s.io/reference/versions.html#cluster-api-release-support) for
 more details about supported releases and for considerations that might apply if you are importing Cluster API go modules as a dependency.
 
 #### Backporting a patch

docs/book/src/developer/core/controllers/machine.md

@@ -17,7 +17,7 @@ Among those rules:
 - InfraMachine SHOULD report [terminal failures](../../providers/contracts/infra-machine.md#inframachine-terminal-failures)
 
 Similarly, in order to support different machine bootstrappers, The Machine resource references
-a BootstrapConfig object, e.g. KubeadmBoostrapConfig etc.
+a BootstrapConfig object, e.g. KubeadmBootstrapConfig etc.
 
 The [BootstrapConfig resource contract](../../providers/contracts/bootstrap-config.md) defines a set of rules a provider is expected to comply with in order to allow
 the expected interactions with the Machine controller.

docs/book/src/developer/core/repository-layout.md

@@ -84,7 +84,7 @@ Some of the subfolders are:
 
 * [~/config/webhook](https://github.com/kubernetes-sigs/cluster-api/tree/main/config/webhook) - Manifest for webhooks generated from the markers defined in the web hook implementations present in [api](#api) folder.
 
-Note: Additional `config` containing manifests can be found in the packages for [KubeadmControlPlane](#controlplane), [KubeadmBoostrap](#bootstrap) and [Cluster API Provider Docker](#cluster-api-provider-docker).
+Note: Additional `config` containing manifests can be found in the packages for [KubeadmControlPlane](#controlplane), [KubeadmBootstrap](#bootstrap) and [Cluster API Provider Docker](#cluster-api-provider-docker).
 
 ### Controllers
 
@@ -154,4 +154,4 @@ This directory contains the implementation of some of the Cluster API webhooks.
 
 This folder exposes the custom webhooks present in [~internal/webhooks](#webhooks) to the users of CAPI.
 
-Note: Additional webhook implementations can be found in the API packages for [KubeadmControlPlane](#controlplane), [KubeadmBoostrap](#bootstrap) and [Cluster API Provider Docker](#cluster-api-provider-docker).
+Note: Additional webhook implementations can be found in the API packages for [KubeadmControlPlane](#controlplane), [KubeadmBootstrap](#bootstrap) and [Cluster API Provider Docker](#cluster-api-provider-docker).

docs/book/src/reference/api/owner-references.md

@@ -1,7 +1,7 @@
 # Owner References
 
 Cluster API uses [Kubernetes owner references](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) to track relationships between objects. These references are used
-for Kubernetes garbage collection, which is also used for Cluster deletion in CAPI. They are also used places where 
+for Kubernetes garbage collection, which is also used for Cluster deletion in CAPI. They are also used in places where 
 the ownership hierarchy is important, for example when using `clusterctl move`.
 
 CAPI uses owner references in an opinionated way. The following guidelines should be considered:

docs/book/src/reference/providers.md

@@ -12,7 +12,7 @@ learn more about the other users of the same provider.
 We also recommend to read provider's documentation carefully, test it, and perform a proper
 due diligence before deciding to use a provider in production, like you will do for any other open source project.
 
-We are deeply thankful to all the the providers in the list, because they are a concrete proof
+We are deeply thankful to all the providers in the list, because they are a concrete proof
 of the liveness of the ecosystem, a relevant part of the history of this community, and a valuable
 source of inspiration and ideas for others.
 

docs/book/src/tasks/diagnostics.md

@@ -4,7 +4,7 @@
 
 With CAPI v1.6 we introduced new flags to allow serving metrics, the pprof endpoint and an endpoint to dynamically change log levels securely in production.
 
-This feature is enabled per default via:
+This feature is enabled by default via:
 ```yaml
           args:
             - "--diagnostics-address=${CAPI_DIAGNOSTICS_ADDRESS:=:8443}"

docs/book/src/tasks/experimental-features/cluster-class/operate-cluster.md

@@ -82,7 +82,7 @@ The `0` in the path refers to the position of the target MachineDeployment in th
 
 To change this value with a patch:
 ```bash
-kubectl  patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/replicas",  "value": 1}]'
+kubectl patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/workers/machineDeployments/0/replicas",  "value": 1}]'
 ```
 
 This patch will make the following changes on the Cluster yaml:
@@ -123,7 +123,7 @@ machinedeployment.cluster.x-k8s.io/capi-quickstart-md-0-XXXX   capi-quickstart
 
 A new MachineDeployment can be added to the Cluster by adding a new MachineDeployment spec under `/spec/topology/workers/machineDeployments/`. To do so we can patch our Cluster with:
 ```bash 
-kubectl  patch cluster capi-quickstart --type json --patch '[{"op": "add", "path": "/spec/topology/workers/machineDeployments/-",  "value": {"name": "second-deployment", "replicas": 1, "class": "default-worker"} }]'
+kubectl patch cluster capi-quickstart --type json --patch '[{"op": "add", "path": "/spec/topology/workers/machineDeployments/-",  "value": {"name": "second-deployment", "replicas": 1, "class": "default-worker"} }]'
 ```
 This patch will make the below changes on the Cluster yaml:
 ```diff
@@ -157,7 +157,7 @@ When using a managed topology scaling of ControlPlane Machines, where the Cluste
 This is done by changing the ControlPlane replicas field at `/spec/topology/controlPlane/replica` in the Cluster object. The command is:
 
 ```bash 
-kubectl  patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/controlPlane/replicas",  "value": 1}]'
+kubectl patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/controlPlane/replicas",  "value": 1}]'
 ```
 
 This patch will make the below changes on the Cluster yaml:
@@ -191,7 +191,7 @@ Which will return something like:
 
 In order to run a different version of etcd in new ControlPlane machines - the part of the spec this variable sets - change the value using the below patch:
 ```bash 
-kubectl  patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/variables/1/value",  "value": "3.5.0"}]'
+kubectl patch cluster capi-quickstart --type json --patch '[{"op": "replace", "path": "/spec/topology/variables/1/value",  "value": "3.5.0"}]'
 ```
 
 Running the patch makes the following change to the Cluster yaml:

docs/book/src/tasks/experimental-features/cluster-class/write-clusterclass.md

@@ -805,7 +805,7 @@ when those values are used in patch or when the generated templates are created
  [6135](https://github.com/kubernetes-sigs/cluster-api/issues/6135)).
 
 As a consequence we recommend avoiding this practice while we are considering alternatives to make
-it explicit for the ClusterClass authors to opt-in in this feature, thus accepting the implied risks.
+it explicit for the ClusterClass authors to opt in this feature, thus accepting the implied risks.
 
 ### Using variable values in JSON patches
 

docs/book/src/tasks/experimental-features/experimental-features.md

@@ -99,8 +99,6 @@ Following controller manager deployments have to be edited in order to enable/di
   * [CAPD](https://cluster-api.sigs.k8s.io/reference/glossary.html?highlight=Providers#capd). Other [Infrastructure Providers](https://cluster-api.sigs.k8s.io/reference/glossary.html?highlight=Providers#infrastructure-provider)
     might also require this. Please consult the docs of the concrete [Infrastructure Provider](https://cluster-api.sigs.k8s.io/reference/providers#infrastructure)
     regarding this.
-
-  * [CAPI](https://cluster-api.sigs.k8s.io/reference/glossary.html?highlight=Gloss#capi).
 * [ClusterClass](./cluster-class/index.md):
   * [CAPI](https://cluster-api.sigs.k8s.io/reference/glossary.html?highlight=Gloss#capi).
   * [KCP](https://cluster-api.sigs.k8s.io/reference/glossary.html?highlight=Gloss#kcp).

docs/book/src/tasks/experimental-features/runtime-sdk/implement-extensions.md

@@ -279,7 +279,7 @@ well with practices like unit testing and generally makes the entire system more
 
 ### Error messages
 
-RuntimeExtension authors should be aware that error messages are surfaced as a conditions in Kubernetes resources
+RuntimeExtension authors should be aware that error messages are surfaced as conditions in Kubernetes resources
 and recorded in Cluster API controller's logs. As a consequence:
 
 - Error message must not contain any sensitive information.

docs/book/src/tasks/experimental-features/runtime-sdk/implement-lifecycle-hooks.md

@@ -44,7 +44,7 @@ potentially block lifecycle transitions from happening.
 
 Following recommendations are especially relevant:
 
-* [Blocking and non Blocking](implement-extensions.md#blocking-hooks)
+* [Blocking and non-blocking](implement-extensions.md#blocking-hooks)
 * [Error messages](implement-extensions.md#error-messages)
 * [Error management](implement-extensions.md#error-management)
 * [Avoid dependencies](implement-extensions.md#avoid-dependencies)