docs: spelling, formatting, etc updates (#23306)

Signed-off-by: Kim Brose <2803622+HarHarLinks@users.noreply.github.com>
Co-authored-by: Michael Crenshaw <350466+crenshaw-dev@users.noreply.github.com>

docs/operator-manual/config-management-plugins.md

@@ -2,11 +2,11 @@
 # Config Management Plugins
 
 Argo CD's "native" config management tools are Helm, Jsonnet, and Kustomize. If you want to use a different config
-management tools, or if Argo CD's native tool support does not include a feature you need, you might need to turn to
+management tool, or if Argo CD's native tool support does not include a feature you need, you might need to turn to
 a Config Management Plugin (CMP).
 
 The Argo CD "repo server" component is in charge of building Kubernetes manifests based on some source files from a
-Helm, OCI, or git repository. When a config management plugin is correctly configured, the repo server may delegate the
+Helm, OCI, or Git repository. When a config management plugin is correctly configured, the repo server may delegate the
 task of building manifests to the plugin.
 
 The following sections will describe how to create, install, and use plugins. Check out the

docs/operator-manual/declarative-setup.md

@@ -1259,7 +1259,7 @@ An optional comma-separated list of `metadata.annotations` keys can be configure
 
 ## Auto respect RBAC for controller
 
-Argocd controller can be restricted from discovering/syncing specific resources using just controller rbac, without having to manually configure resource exclusions.
+Argo CD controller can be restricted from discovering/syncing specific resources using just controller RBAC, without having to manually configure resource exclusions.
 This feature can be enabled by setting `resource.respectRBAC` key in argocd cm, once it is set the controller will automatically stop watching for resources 
 that it does not have the permission to list/access. Possible values for `resource.respectRBAC` are:
     - `strict` : This setting checks whether the list call made by controller is forbidden/unauthorized and if it is, it will cross-check the permission by making a `SelfSubjectAccessReview` call for the resource.
@@ -1270,7 +1270,7 @@ Users who are comfortable with an increase in kube api-server calls can opt for
 
 Notes:
 
-* When set to use `strict` mode controller must have rbac permission to `create` a `SelfSubjectAccessReview` resource 
+* When set to use `strict` mode controller must have RBAC permission to `create` a `SelfSubjectAccessReview` resource 
 * The `SelfSubjectAccessReview` request will be only made for the `list` verb, it is assumed that if `list` is allowed for a resource then all other permissions are also available to the controller.
 
 Example argocd cm with `resource.respectRBAC` set to `strict`:

docs/operator-manual/notifications/index.md

@@ -14,7 +14,7 @@ So you can just use them instead of reinventing new ones.
     kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/notifications_catalog/install.yaml
     ```
 
-* Add Email username and password token to `argocd-notifications-secret` secret
+* Add email username and password token to the `argocd-notifications-secret` secret
 
     ```bash
     EMAIL_USER=<your-username>
@@ -32,7 +32,7 @@ So you can just use them instead of reinventing new ones.
     EOF
     ```
 
-* Register Email notification service
+* Register email notification service
 
     ```bash
     kubectl patch cm argocd-notifications-cm -n argocd --type merge -p '{"data": {"service.email.gmail": "{ username: $email-username, password: $email-password, host: smtp.gmail.com, port: 465, from: $email-username }" }}'

docs/operator-manual/upgrading/overview.md

@@ -13,9 +13,9 @@ Argo CD uses semver-like versioning that ensures the following rules:
   please make sure to check upgrading details in both [v1.3 to v1.4](./1.3-1.4.md)  and  [v1.4 to v1.5](./1.4-1.5.md)
   upgrading instructions.
 * The major release introduces backward incompatible behavior changes. It is recommended to take a backup of
-  Argo CD settings using disaster recovery [guide](../disaster_recovery.md).
+  Argo CD settings using the [disaster recovery guide](../disaster_recovery.md).
 
-After reading the relevant notes about possible breaking changes introduced in Argo CD version use the following
+After reading the relevant notes about possible breaking changes introduced in a new Argo CD version, use the following
 command to upgrade Argo CD. Make sure to replace `<version>` with the required version number:
 
 **Non-HA**:

docs/user-guide/compare-options.md

@@ -2,9 +2,7 @@
 
 ## Ignoring Resources That Are Extraneous
 
->v1.1
-
-You may wish to exclude resources from the app's overall sync status under certain circumstances. E.g. if they are generated by a tool. This can be done by adding this annotation on the resource you wish to exclude:
+You may wish to exclude resources from the app's overall sync status under certain circumstances, e.g. if they are generated by a tool. This can be done by adding this annotation on the resource you wish to exclude:
 
 ```yaml
 metadata:

docs/user-guide/selective_sync.md

@@ -11,7 +11,5 @@ When doing so, bear in mind that:
 
 ## Selective Sync Option
 
->v1.8
-
 Turning on selective sync option which will sync only out-of-sync resources.
 See [sync options](sync-options.md#selective-sync) documentation for more details.

docs/user-guide/sync-kubectl.md

@@ -1,6 +1,6 @@
 # Sync Applications with Kubectl
 
-You can use "kubectl" to ask Argo CD to synchronize applications the same way you can use the CLI or UI. Many configurations like "force", "prune", "apply" and even synchronize a specific list of resources are equally supported. This is done by applying or patching the Argo CD application with a document that defines an "operation".
+You can use "kubectl" to ask Argo CD to synchronize applications the same way you can use the CLI or UI. Many configurations like "force", "prune", "apply" and even synchronizing a specific list of resources are equally supported. This is done by applying or patching the Argo CD application with a document that defines an "operation".
 
 This "operation" defines how a synchronization should be done and for what resources these synchronization is to be done.
 

docs/user-guide/sync-options.md

@@ -6,8 +6,6 @@ Below you can find details about each available Sync Option:
 
 ## No Prune Resources
 
->v1.1
-
 You may wish to prevent an object from being pruned:
 
 ```yaml
@@ -38,8 +36,7 @@ annotation to the application.
 
 ## Disable Kubectl Validation
 
-For a certain class of objects, it is necessary to `kubectl apply` them using the `--validate=false` flag. Examples of this are Kubernetes types which uses `RawExtension`, such as [ServiceCatalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/apis/servicecatalog/v1beta1/types.go#L497). You can do using this annotation:
-
+For a certain class of objects, it is necessary to `kubectl apply` them using the `--validate=false` flag. Examples of this are Kubernetes types which uses `RawExtension`, such as [ServiceCatalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/apis/servicecatalog/v1beta1/types.go#L497). You can do that using this annotation:
 
 ```yaml
 metadata:
@@ -81,10 +78,9 @@ spec:
 
 ## No Resource Deletion
 
-For certain resources you might want to retain them even after your application is deleted, for eg. Persistent Volume Claims.
+For certain resources you might want to retain them even after your application is deleted, e.g. for Persistent Volume Claims.
 In such situations you can stop those resources from being cleaned up during app deletion by using the following annotation:
 
-
 ```yaml
 metadata:
   annotations:
@@ -109,9 +105,9 @@ annotation to the application.
 
 Currently, when syncing using auto sync Argo CD applies every object in the application.
 For applications containing thousands of objects this takes quite a long time and puts undue pressure on the api server.
-Turning on selective sync option which will sync only out-of-sync resources.
+Turning on the selective sync option will sync only out-of-sync resources.
 
-You can add this option by following ways
+You can add this option in the following ways:
 
 1) Add `ApplyOutOfSyncOnly=true` in manifest
 
@@ -136,9 +132,9 @@ $ argocd app set guestbook --sync-option ApplyOutOfSyncOnly=true
 
 ## Resources Prune Deletion Propagation Policy
 
-By default, extraneous resources get pruned using foreground deletion policy. The propagation policy can be controlled
-using `PrunePropagationPolicy` sync option. Supported policies are background, foreground and orphan.
-More information about those policies could be found [here](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents).
+By default, extraneous resources get pruned using the foreground deletion policy. The propagation policy can be controlled
+using the `PrunePropagationPolicy` sync option. Supported policies are background, foreground, and orphan.
+More information about those policies can be found [here](https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/#controlling-how-the-garbage-collector-deletes-dependents).
 
 ```yaml
 apiVersion: argoproj.io/v1alpha1
@@ -172,8 +168,8 @@ metadata:
 
 ## Replace Resource Instead Of Applying Changes
 
-By default, Argo CD executes `kubectl apply` operation to apply the configuration stored in Git. In some cases
-`kubectl apply` is not suitable. For example, resource spec might be too big and won't fit into
+By default, Argo CD executes the `kubectl apply` operation to apply the configuration stored in Git. In some cases
+`kubectl apply` is not suitable. For example, a resource spec might be too large and won't fit into the
 `kubectl.kubernetes.io/last-applied-configuration` annotation that is added by `kubectl apply`. In such cases you
 might use `Replace=true` sync option:
 
@@ -187,7 +183,7 @@ spec:
     - Replace=true
 ```
 
-If the `Replace=true` sync option is set the Argo CD will use `kubectl replace` or `kubectl create` command to apply changes.
+If the `Replace=true` sync option is set, Argo CD will use `kubectl replace` or `kubectl create` command to apply changes.
 
 !!! warning
       During the sync process, the resources will be synchronized using the 'kubectl replace/create' command.
@@ -202,7 +198,7 @@ metadata:
 
 ## Force Sync
 
-For certain resources you might want to delete and recreate. e.g. job resources that should run every time when syncing.
+For certain resources you might want to delete and recreate, e.g. job resources that should run every time when syncing.
 
 !!! warning
       During the sync process, the resources will be synchronized using the 'kubectl delete/create' command.
@@ -220,8 +216,8 @@ metadata:
 This option enables Kubernetes
 [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/).
 
-By default, Argo CD executes `kubectl apply` operation to apply the configuration stored in Git.
-This is a client side operation that relies on `kubectl.kubernetes.io/last-applied-configuration`
+By default, Argo CD executes the `kubectl apply` operation to apply the configuration stored in Git.
+This is a client side operation that relies on the `kubectl.kubernetes.io/last-applied-configuration`
 annotation to store the previous resource state.
 
 However, there are some cases where you want to use `kubectl apply --server-side` over `kubectl apply`:
@@ -232,7 +228,7 @@ However, there are some cases where you want to use `kubectl apply --server-side
 - Use a more declarative approach, which tracks a user's field management, rather than a user's last
   applied state.
 
-If `ServerSideApply=true` sync option is set, Argo CD will use `kubectl apply --server-side`
+If the `ServerSideApply=true` sync option is set, Argo CD will use the `kubectl apply --server-side`
 command to apply changes.
 
 It can be enabled at the application level like in the example below:
@@ -292,7 +288,7 @@ spec:
     - Validate=false
 ```
 
-In this case, Argo CD will use `kubectl apply --server-side --validate=false` command
+In this case, Argo CD will use the `kubectl apply --server-side --validate=false` command
 to apply changes.
 
 Note: [`Replace=true`](#replace-resource-instead-of-applying-changes) takes precedence over `ServerSideApply=true`.
@@ -310,7 +306,7 @@ spec:
     - FailOnSharedResource=true
 ```
 
-## Respect ignore difference configs
+## Respect ignore differences configs
 
 This sync option is used to enable Argo CD to consider the configurations made in the `spec.ignoreDifferences` attribute also during the sync stage. By default, Argo CD uses the `ignoreDifferences` config just for computing the diff between the live and desired state which defines if the application is synced or not. However during the sync stage, the desired state is applied as-is. The patch is calculated using a 3-way-merge between the live state the desired state and the `last-applied-configuration` annotation. This sometimes leads to an undesired results. This behavior can be changed by setting the `RespectIgnoreDifferences=true` sync option like in the example below:
 

docs/user-guide/tracking_strategies.md

@@ -43,7 +43,7 @@ For Git, all versions are Git references but tags [Semantic Versions](https://se
 
 ### HEAD / Branch Tracking
 
-If a branch name, or a symbolic reference (like HEAD) is specified, Argo CD will continually compare
+If a branch name or a symbolic reference (like HEAD) is specified, Argo CD will continually compare
 live state against the resource manifests defined at the tip of the specified branch or the
 resolved commit of the symbolic reference.