Fix anchor and spelling issues in docs/scope-and-objectives.md

Signed-off-by: chymy <[email protected]>

Author: chymy

docs/scope-and-objectives.md

@@ -38,16 +38,20 @@ This is a living document that is refined over time. It serves as guard rails fo
 
 ## Table of Contents
 
-* [Statement and Objectives](#cluster-api-statement-and-objectives)
-  * [Metadata](#metadata)
+* [Cluster API Scope and Objectives](#cluster-api-scope-and-objectives)
   * [Table of Contents](#table-of-contents)
   * [Summary](#summary)
+    * [What is Cluster API?](#what-is-cluster-api)
   * [Glossary](#glossary)
   * [Motivation](#motivation)
     * [Goals](#goals)
-    * [Non\-goals](#non-goals)
+    * [Non-goals](#non-goals)
   * [Requirements](#requirements)
-  * [Workstreams](#workstreams)
+    * [Foundation](#foundation)
+    * [User Experience](#user-experience)
+    * [Organization](#organization)
+    * [Validation](#validation)
+    * [Extension](#extension)
 
 ## Summary
 
@@ -61,18 +65,18 @@ We are building a set of Kubernetes cluster management APIs to enable common clu
 
 ## Glossary
 
-[See ./book/GLOSSARY.md](./book/GLOSSARY.md)
+[See ./book/GLOSSARY.md](./book/src/reference/glossary.md)
 
 - __Cluster API__: Unless otherwise specified, this refers to the project as a whole.
 - __Infrastructure provider__: Refers to the source of computational resources (e.g. machines, networking, etc.). Examples for cloud include AWS, Azure, Google, etc.; for bare metal include VMware, MAAS, etc. When there is more than one way to obtain resources from the same infrastructure provider (e.g. EC2 vs. EKS) each way is referred to as a variant.
 - __Provider implementation__: Existing Cluster API implementations consist of generic and infrastructure provider-specific logic. The infrastructure provider-specific logic is currently maintained in infrastructure provider repositories.
-- __Kubernetes-conformant__: A cluster that passes the Kubernetes conformance tests.
+- __Kubernetes-conformance__: A cluster that passes the Kubernetes conformance tests.
 - __Scaling__: Unless otherwise specified, this refers to horizontal scaling.
 - __Control plane__:
    - __Self-provisioned__: A Kubernetes control plane consisting of pods or machines wholly managed by a single Cluster API deployment.
    - __External__: A control plane offered and controlled by some system other than Cluster API (e.g., GKE, AKS, EKS, IKS).
-- __Core Add-ons__: Addons that are required to deploy a Kubernetes-conformant cluster: DNS, kube-proxy, CNI.
-- __Additional Add-ons__: Addons that are not required for a Kubernetes-conformant cluster (e.g. metrics/Heapster, Dashboard).
+- __Core Add-ons__: Addons that are required to deploy a Kubernetes-conformance cluster: DNS, kube-proxy, CNI.
+- __Additional Add-ons__: Addons that are not required for a Kubernetes-conformance cluster (e.g. metrics/Heapster, Dashboard).
 - __Management cluster__: The cluster where one or more Cluster API providers run, and where resources (e.g. Machines) are stored.
 - __Workload cluster__: A cluster whose lifecycle is managed by the Management cluster.
 - __Operating system__: A generically understood combination of a kernel and system-level userspace interface, such as Linux or Windows, as opposed to a particular distribution.
@@ -89,7 +93,7 @@ As a result, existing popular deployment mechanisms that manage Kubernetes clust
 
 ### Goals
 
-- To manage the lifecycle (create, scale, upgrade, destroy) of Kubernetes-conformant clusters using a declarative API.
+- To manage the lifecycle (create, scale, upgrade, destroy) of Kubernetes-conformance clusters using a declarative API.
 - To work in different environments, both on-premises and in the cloud.
 - To define common operations, provide a default implementation, and provide the ability to swap out implementations for alternative ones.
 - To reuse and integrate existing ecosystem components rather than duplicating their functionality (e.g. node-problem-detector, cluster autoscaler, SIG-Multi-cluster).
@@ -99,9 +103,9 @@ As a result, existing popular deployment mechanisms that manage Kubernetes clust
 
 - To add these APIs to Kubernetes core (kubernetes/kubernetes).
    -  This API should live in a namespace outside the core and follow the best practices defined by api-reviewers, but is not subject to core-api constraints.
-- To manage the lifecycle of infrastructure unrelated to the running of Kubernetes-conformant clusters.
+- To manage the lifecycle of infrastructure unrelated to the running of Kubernetes-conformance clusters.
 - To force all Kubernetes lifecycle products (kops, kubespray, GKE, AKS, EKS, IKS etc.) to support or use these APIs.
-- To manage non-Cluster API provisioned Kubernetes-conformant clusters.
+- To manage non-Cluster API provisioned Kubernetes-conformance clusters.
 - To manage a single cluster spanning multiple infrastructure providers.
 - To configure a machine at any time other than create or upgrade.
 - To duplicate functionality that exists or is coming to other tooling, e.g., updating kubelet configuration (c.f. dynamic kubelet configuration), or updating apiserver, controller-manager, scheduler configuration (c.f. component-config effort) after the cluster is deployed.