address comments

Author: fabriziopandini

docs/book/src/clusterctl/commands/config-cluster.md

@@ -1,7 +1,6 @@
 # clusterctl config cluster
 
 The `clusterctl create config` command returns a YAML template for creating a workload cluster.
-Store it locally, eventually customize it, and the apply it to start provisioning the workload cluster.
 
 For example
 
@@ -13,7 +12,7 @@ Creates a YAML file named `my-cluster.yaml` with a predefined list of Cluster AP
 Machine Deployments, etc. to be deployed in the current namespace (in case, use the `--target-namespace` flag to 
 specify a different target namespace).
 
-Then, the file can be eventually modified using your editor of choice; when ready, run the following command
+Then, the file can be modified using your editor of choice; when ready, run the following command
 to apply the cluster manifest.
 
 ```
@@ -26,7 +25,7 @@ The `clusterctl config cluster` command uses smart defaults in order to simplify
 it detects that there is only an `aws` infrastructure provider in the current management cluster and so it automatically 
 selects a cluster template from the `aws` provider's repository. 
 
-In case there is more than one infrastructure provider, following syntax can be used to select which infrastructure
+In case there is more than one infrastructure provider, the following syntax can be used to select which infrastructure
 provider to use for the workload cluster:
 
 ```
@@ -44,7 +43,7 @@ clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
 ### Flavors
 
 The infrastructure provider authors can provide different type of cluster templates, or flavors; use the `--flavor` flag
-to specify the which flavor to use; e.g.
+to specify which flavor to use; e.g.
 
 ```
 clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
@@ -55,12 +54,12 @@ Please refer to the providers documentation for more info about available flavor
 
 ### Alternative source for cluster templates
 
-clusterctl uses the provider's repository as a primary source for cluster templates; following alternative sources 
+clusterctl uses the provider's repository as a primary source for cluster templates; the following alternative sources 
 for cluster templates can be used as well:
 
 #### ConfigMaps
 
-Use the `--from-config-map` flag to read cluster templates stored in Kubernetes ConfigMap; e.g.
+Use the `--from-config-map` flag to read cluster templates stored in a Kubernetes ConfigMap; e.g.
 
 ```
 clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
@@ -69,7 +68,7 @@ clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
 
 #### GitHub or local file system folder
 
-Use the `--from` flag to read cluster templates stored into a GitHub repository or in a local file system folder; e.g.
+Use the `--from` flag to read cluster templates stored in a GitHub repository or in a local file system folder; e.g.
 
 ```
 clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
@@ -85,12 +84,12 @@ clusterctl config cluster my-cluster --kubernetes-version v1.16.3 \
 
 ### Variables
 
-If the select cluster template expects some environment variables, user should ensure those variables are set in advance.
+If the selected cluster template expects some environment variables, user should ensure those variables are set in advance.
 
-e.g. if the `AWS_CREDENTIALS` variable is expected for a cluster template targeting the `aws` infrastructure, user
+e.g. if the `AWS_CREDENTIALS` variable is expected for a cluster template targeting the `aws` infrastructure, you
 should ensure the corresponding environment variable to be set before executing `clusterctl config cluster`.
 
 Please refer to the providers documentation for more info about the required variables or use the 
 `clusterctl config cluster --list-variables` flag to get a list of variables names required by a cluster template.
 
-In case, the [clusterctl configuration](configuration.md) file can be used as alternative to environment variables.
+The [clusterctl configuration](configuration.md) file can be used as alternative to environment variables.

docs/book/src/clusterctl/commands/move.md

@@ -38,7 +38,7 @@ process completes.
 
 ## Pivot
 
-Pivot is a process for moving the provider components and declared cluster-api resources from a source management
+Pivoting is a process for moving the provider components and declared Cluster API resources from a source management
 cluster to a target management cluster.
 
 This can now achieved with the following procedure:
@@ -48,16 +48,16 @@ This can now achieved with the following procedure:
 
 ## Bootstrap & Pivot
 
-In former versions of clusterctl the pivot process was bounded with the creation of a temporary bootstrap cluster
- used to provision a target Management cluster.
+The pivot process can be bounded with the creation of a temporary bootstrap cluster
+used to provision a target Management cluster.
 
 This can now achieved with the following procedure:
 
-1. Create a  temporary bootstrap cluster, e.g. using Kind or Minikube
+1. Create a temporary bootstrap cluster, e.g. using Kind or Minikube
 2. Use `clusterctl init` to install the provider components
 3. Use `clusterctl config cluster ... | kubectl apply -f -` to provision a target management cluster
 4. Wait for the target management cluster to be up and running
 5. Get the kubeconfig for the new target management cluster
 6. Use `clusterctl init` with the new cluster's kubeconfig to install the provider components 
-7. Use `clusterctl move` to move the cluster-api resources from the bootstrap cluster to the target management cluster
+7. Use `clusterctl move` to move the Cluster API resources from the bootstrap cluster to the target management cluster
 8. Delete the bootstrap cluster

docs/book/src/clusterctl/commands/upgrade.md

@@ -58,8 +58,8 @@ The upgrade process is composed by two steps:
   are hosted and the provider's CRDs.
 * Install the new version of the provider components.
 
-Please note that clusterctl does not upgrades Cluster API objects (Clusters, MachineDeployments, Machine etc.); upgrading 
-such objects is responsibility of the provider's controllers.
+Please note that clusterctl does not upgrade Cluster API objects (Clusters, MachineDeployments, Machine etc.); upgrading 
+such objects are the responsibility of the provider's controllers.
 
 
 <aside class="note warning">

docs/book/src/clusterctl/overview.md

@@ -229,7 +229,7 @@ for cluster templates.
 If the cluster template defined by the infrastructure provider expects some environment variables, user 
 should ensure those variables are set in advance.
 
-See [`clusterctl config cluster`](commands/config-cluster.md) for details about how discover the list of
+See [`clusterctl config cluster`](commands/config-cluster.md) for details about how to discover the list of
 variables required by a cluster templates.
 
 </aside>

docs/book/src/clusterctl/provider-contract.md

@@ -48,12 +48,12 @@ about how to create a release.
 
 #### Creating a local provider repository
 
-clusterctl supports reading from repository defined in the local file system.
+clusterctl supports reading from a repository defined on the local file system.
 
-Local repository can be defined by crating a `<provider-name>` folder with a `<version>` sub-folder for each hosted release;
+A local repository can be defined by creating a `<provider-name>` folder with a `<version>` sub-folder for each hosted release;
 the sub-folder name MUST be a valid semantic version number.
 
-Each version sub-folder MUST contains the corresponding components YAML, the metadata YAML and eventually the workload cluster templates.
+Each version sub-folder MUST contain the corresponding components YAML, the metadata YAML and eventually the workload cluster templates.
 
 ### Metadata YAML