Merge pull request #16 from ricardoapl/fix-typos

Fix typos, broken links, and formatting

Author: k8s-ci-robot

site-src/api-types/cluster-set.md

@@ -9,7 +9,7 @@ ClusterSet represents a specific pattern implemented by various organizations. A
     - Namespaces don't have to exist in every cluster, but behave the same across those in which they do.
 
 !!!note
-        The early definition of the ClusterSet was described in [KEP-2149](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/2149-clusterid). It is now part of the [About API](https://sigs.k8s.io/about-api).
+    The early definition of the ClusterSet was described in [KEP-2149](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/2149-clusterid). It is now part of the [About API](https://sigs.k8s.io/about-api).
 
 A cluster's ClusterSet membership is stored in the about.k8s.io/ClusterProperty `clusterset.k8s.io`.
 

site-src/concepts/multicluster-services-api.md

@@ -2,7 +2,7 @@
 
 This document provides an overview of Multicluster Services API.
 
-This is an extension of the Services concept across multiple clusters. Services are the basic way that workloads communicate with each other in Kubernetes, and the Multicluster Services builds upon the [Namespace Sameness](./namespace-sameness.md) concept to extend Services across multiclusters. In short, Services can remain available across clusters simply by using the same names. The Control Plane can be centralized or decentralized, but consumers only even rely on local data.
+This is an extension of the Services concept across multiple clusters. Services are the basic way that workloads communicate with each other in Kubernetes, and the Multicluster Services builds upon the [Namespace Sameness](./namespace-sameness.md) concept to extend Services across multiclusters. In short, Services can remain available across clusters simply by using the same names. The Control Plane can be centralized or decentralized, but consumers only rely on local data.
 
 This document solely focuses on the API and the common behaviour, leaving room for various [implementations](../guides/index.md). There is no reference implementation available.
 

site-src/concepts/work-api.md

@@ -1,6 +1,6 @@
 # Work API Overview
 
-A common [Work API](https://github.com/kubernetes-sigs/work-api) to distribute workload to multiple clusters.
+A common [Work API](https://github.com/kubernetes-sigs/work-api) to distribute workloads across multiple clusters.
 
 ![Alt](../images/work-api.png "Work API")
 
@@ -15,7 +15,7 @@ and applies resources defined in the Work to the Managed Cluster.
 
 ## Overview
 
-A Work is a custom resource that represent a list of API resources to be deployed on a cluster.
+A Work is a custom resource that represents a list of API resources to be deployed on a cluster.
 The Work is created on the Work Hub, and resides in the namespace that the Work Controller is authorized to access.
 Creation of a Work on the Work Hub indicates that resources defined in the Work will be applied on a certain Managed Cluster.
 Update of a Work will trigger the resource update on the Managed Cluster, and deletion of a Work will garbage collect the resources on the Managed Cluster.
@@ -41,7 +41,7 @@ spec:
          color=purple
 ```
 
-User creates a Work in the `cluster1 namespace on the Work Hub that the Work Controller is authorized to access. 
+User creates a Work in the `cluster1` namespace on the Work Hub that the Work Controller is authorized to access. 
 The Work Controller then accesses the Managed Cluster and applies the resources defined in the Work in its reconcile loop.
 The Work controller also tracks the status of applied resources by updating the Work status.
 

site-src/contributing/index.md

@@ -30,7 +30,7 @@ you can get help with your specific implementation.
 Major discussions and notifications will be sent on the [SIG-MC mailing
 list][sigmcg].
 
-We also have a [Slack channel (sig-multicluster)][slack] on k8s.io for day-to-day questions, discussions.
+We also have a [Slack channel (sig-multicluster)][slack] on k8s.io for day-to-day questions and discussions.
 
 [sigmcg]: https://groups.google.com/forum/#!forum/kubernetes-sig-multicluster
 [slack]: https://kubernetes.slack.com/archives/C09R1PJR3

site-src/guides/guidelines.md

@@ -22,7 +22,7 @@ resources:
 
 ## Conflicts
 
-Separation and delegation of responsibility among independent actors (e.g
+Separation and delegation of responsibility among independent actors (e.g.
 between cluster ops and application developers) can result in conflicts in the
 configuration. For example, two application teams may inadvertently submit
 configuration for the same HTTP path.
@@ -108,13 +108,15 @@ Similar to other Kubernetes APIs, Multicluster, Work and About APIs use "Kind" i
 in object references throughout the API. This pattern should be familiar to
 most Kubernetes users.
 
-Per the [Kubernetes API conventions][1], this means that all implementations of
+Per the [Kubernetes API Conventions][1], this means that all implementations of
 this API should have a predefined mapping between kinds and resources. Relying
 on dynamic resource mapping is not safe.
 
 ## API Conventions
 
-The Multicluster, About and Work APIs follow Kubernetes API [conventions][1]. These conventions
+The Multicluster, About and Work APIs follow [Kubernetes API Conventions][1]. These conventions
 are intended to ease client development and ensure that configuration
 mechanisms can consistently be implemented across a diverse set of use
 cases. 
+
+[1]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md

site-src/index.md

@@ -4,13 +4,13 @@ Since its inception in 2015, Kubernetes has been pretty successful at popularizi
 
 SIG-Multicluster is a [Special Interest Group][sig-multicluster-github] focused on solving common challenges related to the management of multiple Kubernetes clusters, and applications that exist therein. 
 
-Specifically, the SIG aims to fine Kubernetes-native ways to:
+Specifically, the SIG aims to find Kubernetes-native ways to:
 
 * Expose workloads from multiple clusters to each other
 * Share cluster metadata and its place relative to others
 * Generally break down the walls between clusters
 
-The SIG is responsible for designing, discussing, implementing and maintaining API’s, tools and documentation related to multi-cluster administration and application management. This includes not only active automated approaches such as Cluster Federation, but also those that employ batch workflow-style continuous deployment systems like Spinnaker and others. Standalone building blocks for these and other similar systems (for example a cluster registry), and proposed changes to kubernetes core where appropriate will also be in scope.
+The SIG is responsible for designing, discussing, implementing and maintaining APIs, tools and documentation related to multi-cluster administration and application management. This includes not only active automated approaches such as Cluster Federation, but also those that employ batch workflow-style continuous deployment systems like Spinnaker and others. Standalone building blocks for these and other similar systems (for example a cluster registry), and proposed changes to kubernetes core where appropriate will also be in scope.
 
 ## Problem statement: why multicluster?
 
@@ -37,7 +37,7 @@ There are many reasons to want to run multiple clusters, including but not limit
 ## Project charter
 The following charter defines the scope and governance of the [Multicluster Special Interest Group][sig-multicluster-github]:
 
-* Support an out-of-tree ecosystem by defining API standards that leave plenty of rool for flexibility in their ultimately third party implementation.
+* Support an out-of-tree ecosystem by defining API standards that leave plenty of room for flexibility in their ultimately third party implementation.
 
 * Protect the known multicluster experience from incompatible changes upstream to single clusters by working with other [SIGs][sigs-github].