Address feedback

Author: fabriziopandini

docs/book/src/developer/providers/best-practices.md

@@ -12,7 +12,7 @@ However, some best practice are worth to notice:
       to grouping resources
 
 - Naming convention above should not be used and advertised as a contract to build on top. Instead more robust mechanism
-  MUST always be provided and used for identifying objects, like tagging on labeling.
+  MUST always be provided and used for identifying objects, like tagging or labeling.
   Please note that this is necessary not only to prevent issues in case Cluster API changes default naming strategies
   for the Kubernetes objects generated by core controllers, but also to handle use cases where users intentionally influence Cluster API naming strategies. 
 

docs/book/src/developer/providers/contracts/infra-cluster.md

@@ -2,7 +2,7 @@
 
 Infrastructure providers SHOULD implement an InfraCluster resource.
 
-The goal of an InfraCluster resource is to supplie whatever prerequisites (in term of infrastructure) are necessary for running machines.
+The goal of an InfraCluster resource is to supply whatever prerequisites (in term of infrastructure) are necessary for running machines.
 Examples might include networking, load balancers, firewall rules, and so on.
 
 The InfraCluster resource will be referenced by one of the Cluster API core resources, Cluster.
@@ -28,7 +28,7 @@ are explicitly called out in dedicated pages.
 When developing a provider, you MUST consider any Cluster API behaviour that is not defined by a contract rule
 as a Cluster API internal implementation detail, subject to change without any advice.
 
-When implementing an Infra Cluster, you MUST NOT rely on any Cluster API internal behaviour, otherwise you are exposing users
+When implementing an InfraCluster, you MUST NOT rely on any Cluster API internal behaviour, otherwise you are exposing users
 to the risk that such internal behaviour will change.
 
 Instead, whenever you need something more from the Cluster API contract, you MUST engage the community.
@@ -188,7 +188,7 @@ The list resource MUST be named as `<InfraCluster>List`.
 //+kubebuilder:object:root=true
 
 // FooClusterList contains a list of fooclusters.
-type FooaClusterList struct {
+type FooClusterList struct {
     metav1.TypeMeta `json:",inline"`
     metav1.ListMeta `json:"metadata,omitempty"`
     Items           []FooCluster `json:"items"`
@@ -380,14 +380,14 @@ The template resource MUST be named as `<InfraCluster>Template`.
 // +kubebuilder:storageversion
 
 // FooClusterTemplate is the Schema for the fooclustertemplates API.
-type InfraClusterTemplate struct {
+type FooClusterTemplate struct {
     metav1.TypeMeta   `json:",inline"`
     metav1.ObjectMeta `json:"metadata,omitempty"`
 
     Spec FooClusterTemplateSpec `json:"spec,omitempty"`
 }
 
-type FooaClusterTemplateSpec struct {
+type FooClusterTemplateSpec struct {
     Template FooClusterTemplateResource `json:"template"`
 }
 
@@ -409,11 +409,11 @@ The list resource MUST be named as `<InfraClusterTemplate>List`.
 ```go
 //+kubebuilder:object:root=true
 
-// InfraClusterTemplateList contains a list of InfraClusterTemplates.
-type InfraClusterTemplateList struct {
+// FooClusterTemplateList contains a list of FooClusterTemplates.
+type FooClusterTemplateList struct {
     metav1.TypeMeta `json:",inline"`
     metav1.ListMeta `json:"metadata,omitempty"`
-    Items           []InfraClusterTemplate `json:"items"`
+    Items           []FooClusterTemplate `json:"items"`
 }
 ```