Merge pull request #810 from jbw976/fix-all-vales

Fix all Vale errors

Author: jbw976

.github/workflows/vale.yml

@@ -23,7 +23,7 @@ jobs:
 
       - name: Install Vale
         env:
-          VALE_VERSION: "2.28.2"
+          VALE_VERSION: "3.7.1"
         run: wget https://github.com/errata-ai/vale/releases/download/v${{env.VALE_VERSION}}/vale_${{env.VALE_VERSION}}_Linux_64-bit.tar.gz && tar -xvzf vale_${{env.VALE_VERSION}}_Linux_64-bit.tar.gz
 
       - name: Run Vale

content/contribute/_index.md

@@ -55,10 +55,9 @@ here.
   generator, CSS layouts and JavaScript.
 
 ## Licensing
-The Crossplane documentation is under the [Creative Commons
-Attribution](https://creativecommons.org/licenses/by/4.0/) license. CC-BY allows
-reuse, remixing and republishing of Crossplane documentation with attribution to
-the Crossplane organization.
+The Crossplane documentation is under the [Creative Commons Attribution](https://creativecommons.org/licenses/by/4.0/)
+license. CC-BY allows reuse, remixing and republishing of Crossplane
+documentation with attribution to the Crossplane organization.
 
 ## Issues and feature requests
 Open an [issue](https://github.com/crossplane/crossplane/issues)

content/contribute/vale.md

@@ -22,7 +22,7 @@ content. The community approves PRs with Vale errors in unmodified document sect
 Follow the directions on the Vale website to 
 [install the Vale binary](https://vale.sh/docs/vale-cli/installation/).
 <!-- vale off -->
-Crossplane CI uses [Vale v2.22.0](https://github.com/errata-ai/vale/releases/tag/v2.22.0) or later.
+Crossplane CI uses [Vale v3.7.1](https://github.com/errata-ai/vale/releases/tag/v3.7.1) or later.
 <!-- vale on -->
 ## Run Vale
 

content/contribute/writing-style-guide.md

@@ -23,7 +23,7 @@ The most important points of the style guide include:
 users. When in doubt, spell it out first.
   * Avoid assuming the reader already knows the background.
 * Don't use [cliches](https://www.topcreativewritingcourses.com/blog/common-cliches-in-writing-and-how-to-avoid-them).
-  * Cliches make writing sound unprofessional and are not internationally inclusive. 
+  * Cliches make writing sound unprofessional and aren't internationally inclusive. 
 * Use contractions for phrases like "do not," "cannot," "is not" and related terms.
   * It's easy to miss "not" in "do not." It's hard to misunderstand "don't."
 * Don't use Latin terms (i.e., e.g., etc.).
@@ -48,8 +48,7 @@ users. When in doubt, spell it out first.
 Crossplane relies on [Vale](https://github.com/errata-ai/vale) to enforce the
 complete style guide. 
 
-Read more about [using Vale with the Crossplane
-documentation]({{<ref "Vale" >}}).
+Read more about [using Vale with the Crossplane documentation]({{<ref "Vale" >}}).
 
 ## Italics
 

content/master/concepts/composition-revisions.md

@@ -93,7 +93,7 @@ metadata:
 spec:
   parameters:
     storageGB: 20
-  # The Manual policy specifies that you do not want this XR to update to the
+  # The Manual policy specifies that you don't want this XR to update to the
   # latest CompositionRevision automatically.
   compositionUpdatePolicy: Manual
   compositionRef:
@@ -348,8 +348,8 @@ myvpcs.aws.example.upbound.io-727b3c8   2          staging
 myvpcs.aws.example.upbound.io-ad265bc   1          dev
 ``` 
 
-Verify that Crossplane assigns the Composite Resources `vpc-auto` and `vpc-staging` to Composite revision:2.  
-XRs `vpc-man` and `vpc-dev` are still assigned to the original revision:1:
+Verify that Crossplane assigns the Composite Resources `vpc-auto` and `vpc-staging` to Composite `revision:2`.  
+XRs `vpc-man` and `vpc-dev` are still assigned to the original `revision:1`:
 
 ```shell
 kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@@ -365,7 +365,7 @@ vpc-staging   True     myvpcs.aws.example.upbound.io-727b3c8   Automatic   map[c
 
 {{< hint "note" >}}
 `vpc-auto` always use the latest Revision.  
-`vpc-staging` now matches the label applied to Revision revision:2.
+`vpc-staging` now matches the label applied to Revision `revision:2`.
 {{< /hint >}}
 
 #### Update Composition Spec and Label
@@ -427,8 +427,8 @@ myvpcs.aws.example.upbound.io-f81c553   3          dev
 Changing the label and the spec values simultaneously is critical for deploying new changes to the `dev` channel.
 {{< /hint >}}
 
-Verify Crossplane assigns the Composite Resources `vpc-auto` and `vpc-dev` to Composite revision:3.  
-`vpc-staging` is assigned to revision:2, and `vpc-man` is still assigned to the original revision:1:
+Verify Crossplane assigns the Composite Resources `vpc-auto` and `vpc-dev` to Composite `revision:3`.  
+`vpc-staging` is assigned to `revision:2`, and `vpc-man` is still assigned to the original `revision:1`:
 
 ```shell
 kubectl get composite -o="custom-columns=NAME:.metadata.name,SYNCED:.status.conditions[0].status,REVISION:.spec.compositionRevisionRef.name,POLICY:.spec.compositionUpdatePolicy,MATCHLABEL:.spec.compositionRevisionSelector.matchLabels"
@@ -444,8 +444,8 @@ vpc-staging   True     myvpcs.aws.example.upbound.io-727b3c8   Automatic   map[c
 
 
 {{< hint "note" >}}
-`vpc-dev` matches the updated label applied to Revision revision:3.
-`vpc-staging` matches the label applied to Revision revision:2.
+`vpc-dev` matches the updated label applied to Revision `revision:3`.
+`vpc-staging` matches the label applied to Revision `revision:2`.
 {{< /hint >}}
 
 

content/master/concepts/packages.md

@@ -339,7 +339,7 @@ Status:
 Events:
   Type     Reason       Age                From                                              Message
   ----     ------       ----               ----                                              -------
-  Warning  LintPackage  29s (x2 over 29s)  packages/configurationrevision.pkg.crossplane.io  incompatible Crossplane version: package is not compatible with Crossplane version (v1.12.0)
+  Warning  LintPackage  29s (x2 over 29s)  packages/configurationrevision.pkg.crossplane.io  incompatible Crossplane version: package isn't compatible with Crossplane version (v1.12.0)
 ```
 
 The {{<hover label="depend" line="18">}}Events{{</hover>}} show a 

content/master/concepts/providers.md

@@ -351,7 +351,7 @@ Status:
 Events:
   Type     Reason             Age                From                                         Message
   ----     ------             ----               ----                                         -------
-  Warning  LintPackage        41s (x3 over 47s)  packages/providerrevision.pkg.crossplane.io  incompatible Crossplane version: package is not compatible with Crossplane version (v1.10.0)
+  Warning  LintPackage        41s (x3 over 47s)  packages/providerrevision.pkg.crossplane.io  incompatible Crossplane version: package isn't compatible with Crossplane version (v1.10.0)
 ```
 
 The {{<hover label="depend" line="17">}}Events{{</hover>}} show a 

content/master/guides/crossplane-with-argo-cd.md

@@ -5,14 +5,14 @@ weight: 270
 
 [Argo CD](https://argoproj.github.io/cd/) and [Crossplane](https://crossplane.io)
 are a great combination. Argo CD provides GitOps while Crossplane turns any Kubernetes
-cluster into a Universal Control Plane for all of your resources. There are
-configuration details required in order for the two to work together properly.
+cluster into a Universal Control Plane for all of your resources. Configuration details are 
+required in order for the two to work together properly.
 This doc will help you understand these requirements. It is recommended to use
 Argo CD version 2.4.8 or later with Crossplane.
 
 Argo CD synchronizes Kubernetes resource manifests stored in a Git repository
-with those running in a Kubernetes cluster (GitOps). There are different ways to configure 
-how Argo CD tracks resources. With Crossplane, you need to configure Argo CD 
+with those running in a Kubernetes cluster (GitOps). Argo CD has different ways to configure 
+how it tracks resources. With Crossplane, you need to configure Argo CD 
 to use Annotation based resource tracking. See the [Argo CD docs](https://argo-cd.readthedocs.io/en/latest/user-guide/resource_tracking/) for additional detail.
 
 ### Configuring Argo CD with Crossplane
@@ -185,12 +185,12 @@ data:
 
 Crossplane providers generates a `ProviderConfigUsage` for each of the managed resource (MR) it handles. This resource
 enable representing the relationship between MR and a ProviderConfig so that the controller can use it as finalizer when a
-ProviderConfig is deleted. End-users of Crossplane are not expected to interact with this resource.
+ProviderConfig is deleted. End users of Crossplane aren't expected to interact with this resource.
 
 Argo CD UI reactivity can be impacted as the number of resource and types grow. To help keep this number low we
 recommend hiding all `ProviderConfigUsage` resources from Argo CD UI.
 
-To configure resource exclusion  edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
+To configure resource exclusion edit the `argocd-cm` `ConfigMap` in the `argocd` `Namespace` as such:
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -204,7 +204,7 @@ data:
 
 The use of `"*"` as apiGroups will enable the mechanism for all Crossplane Providers.
 
-#### Increase K8s Client QPS
+#### Increase Kubernetes Client QPS
 
 As the number of CRDs grow on a control plane it will increase the amount of queries Argo CD Application Controller
 needs to send to the Kubernetes API. If this is the case you can increase the rate limits of the Argo CD Kubernetes client.

content/master/guides/multi-tenant.md

@@ -5,9 +5,9 @@ weight: 240
 
 This guide describes how to use Crossplane effectively in multi-tenant
 environments by utilizing Kubernetes primitives and compatible policy
-enforcement projects in the cloud-native ecosystem.
+enforcement projects in the cloud native ecosystem.
 
-## TL;DR
+## Summary
 
 Infrastructure operators in multi-tenant Crossplane environments typically
 utilize composition and Kubernetes RBAC to define lightweight, standardized
@@ -21,7 +21,7 @@ those with more complex environments, may choose to incorporate third-party
 policy engines, or scale to multiple Crossplane clusters. The following sections
 describe each of these scenarios in greater detail.
 
-- [TL;DR](#tldr)
+- [Summary](#summary)
 - [Background](#background)
   - [Cluster-Scoped Managed Resources](#cluster-scoped-managed-resources)
   - [Namespace Scoped Claims](#namespace-scoped-claims)
@@ -109,7 +109,7 @@ in response to the creation of an instance of the XRD. More information about
 this architecture can be found in the [Composition] documentation.
 
 Every XRD is exposed at the cluster scope, but only those with `spec.claimNames`
-defined will have a namespace-scoped variant.
+defined will have a namespace scoped variant.
 
 ```yaml
 apiVersion: apiextensions.crossplane.io/v1
@@ -131,7 +131,7 @@ When the example above is created, Crossplane will produce two
 [CustomResourceDefinitions]:
 1. A cluster-scoped type with `kind: XMySQLInstance`. This is referred to as a
    **Composite Resource (XR)**.
-2. A namespace-scoped type with `kind: MySQLInstance`. This is referred to as a
+2. A namespace scoped type with `kind: MySQLInstance`. This is referred to as a
    **Claim (XRC)**.
 
 Platform builders may choose to define an arbitrary number of Compositions that
@@ -160,13 +160,13 @@ This feature serves as a lightweight policy mechanism by only giving the
 consumer the ability to customize the underlying resources to the extent the
 platform builder desires. For instance, in the examples above, a platform
 builder may choose to define a `spec.location` field in the schema of the
-`XMySQLInstance` that is an enum with options `east` and `west`. In the
+`XMySQLInstance` that's an enum with options `east` and `west`. In the
 Composition, those fields could map to the `RDSInstance` `spec.region` field,
 making the value either `us-east-1` or `us-west-1`. If no other patches were
 defined for the `RDSInstance`, giving a user the ability (using RBAC) to create
 a `XMySQLInstance` / `MySQLInstance` would be akin to giving the ability to
-create a very specifically configured `RDSInstance`, where they can only decide
-the region where it lives and they are restricted to two options.
+create a specifically configured `RDSInstance`, where they can only decide
+the region where it lives and they're restricted to two options.
 
 This model is in contrast to many infrastructure as code tools where the end
 user must have provider credentials to create the underlying resources that are
@@ -182,11 +182,11 @@ standardizing on Kubernetes RBAC.
 While the ability to define abstract schemas and patches to concrete resource
 types using composition is powerful, the ability to define Claim types at the
 namespace scope enhances the functionality further by enabling RBAC to be
-applied with namespace restrictions. Most users in a cluster do not have access
-to cluster-scoped resources as they are considered only relevant to
+applied with namespace restrictions. Most users in a cluster don't have access
+to cluster-scoped resources as they're considered only relevant to
 infrastructure admins by both Kubernetes and Crossplane.
 
-Building on our simple `XMySQLInstance` / `MySQLInstance` example, a platform
+Building on our `XMySQLInstance` / `MySQLInstance` example, a platform
 builder may choose to define permissions on `MySQLInstance` at the namespace
 scope using a `Role`. This allows for giving users the ability to create and
 manage `MySQLInstances` in their given namespace, but not the ability to see
@@ -249,15 +249,15 @@ namespace the corresponding `MySQLInstance` was created in.
 ### Policy Enforcement with Open Policy Agent
 
 In some Crossplane deployment models, only using composition and RBAC to define
-policy will not be flexible enough. However, because Crossplane brings
-management of external infrastructure to the Kubernetes API, it is well suited
-to integrate with other projects in the cloud-native ecosystem. Organizations
+policy won't be flexible enough. However, because Crossplane brings
+management of external infrastructure to the Kubernetes API, it's well suited
+to integrate with other projects in the cloud native ecosystem. Organizations
 and individuals that need a more robust policy engine, or just prefer a more
 general language for defining policy, often turn to [Open Policy Agent] (OPA).
-OPA allows platform builders to write custom logic in [Rego], a domain-specific
+OPA allows platform builders to write custom logic in [Rego], a domain specific
 language. Writing policy in this manner allows for not only incorporating the
 information available in the specific resource being evaluated, but also using
-other state represented in the cluster. Crossplane users typically install OPA's
+other state represented in the cluster. Crossplane users typically install OPA
 [Gatekeeper] to make policy management as streamlined as possible.
 
 > A live demo of using OPA with Crossplane can be viewed [here].
@@ -271,14 +271,16 @@ simpler.
 ### Reproducible Platforms with Configuration Packages
 
 [Configuration packages] allow platform builders to package their XRDs and
-Compositions into [OCI images] that can be distributed via any OCI-compliant
+Compositions into [OCI images] that can be distributed via any OCI compliant
 image registry. These packages can also declare dependencies on providers,
 meaning that a single package can declare all of the granular managed resources,
 the controllers that must be deployed to reconcile them, and the abstract types
 that expose the underlying resources using composition.
 
 Organizations with many Crossplane deployments utilize Configuration packages to
+<!-- vale alex.Condescending = NO -->
 reproduce their platform in each cluster. This can be as simple as installing
+<!-- vale alex.Condescending = YES -->
 Crossplane with the flag to automatically install a Configuration package
 alongside it.
 

content/master/guides/self-signed-ca-certs.md

@@ -3,7 +3,7 @@ title: Self-Signed CA Certs
 weight: 270   
 ---  
 
->  Using self-signed certificates is not advised in production, it is 
+>  Using self-signed certificates isn't advised in production, it's 
 recommended to only use self-signed certificates for testing.
 
 When Crossplane loads Configuration and Provider Packages from private 
@@ -39,7 +39,7 @@ kubectl -n [Crossplane system namespace] create cm ca-bundle-config \
 `ca-bundle-config` and the `registryCaBundleConfig.key` parameter to 
 `ca-bundle`.
 
-> Providing Helm with parameter values is convered in the Helm docs, 
+> Providing Helm with parameter values is covered in the Helm docs, 
 [Helm install](https://helm.sh/docs/helm/helm_install/). An example block  
 in an `override.yaml` file would look like this:
 ```