Typo fixes and style edits

doc/administration/dedicated/configure_instance.md

@@ -62,19 +62,19 @@ You will only receive email notifications for changes made by a Switchboard tena
 
 You can use the configuration change log to track the changes made to your GitLab Dedicated instance, including:
 
-- **Configuration change:** Name of the configuration setting that changed.
-- **User:** Email address of the user that made the configuration change. For changes made by a GitLab Operator, this value will appear as `GitLab Operator`.
-- **IP:** IP address of the user that made the configuration change. For changes made by a GitLab Operator, this value will appear as `Unavailable`.
-- **Status:** Whether the configuration change is initiated, in progress, completed, or deferred.
-- **Start time:** Start date and time when the configuration change is initiated, in UTC.
-- **End time:** End date and time when the configuration change is deployed, in UTC.
+- Configuration change: Name of the configuration setting that changed.
+- User: Email address of the user that made the configuration change. For changes made by a GitLab Operator, this value will appear as `GitLab Operator`.
+- IP: IP address of the user that made the configuration change. For changes made by a GitLab Operator, this value will appear as `Unavailable`.
+- Status: Whether the configuration change is initiated, in progress, completed, or deferred.
+- Start time: Start date and time when the configuration change is initiated, in UTC.
+- End time: End date and time when the configuration change is deployed, in UTC.
 
 Each configuration change has a status:
 
-- **Initiated:** Configuration change is made in Switchboard, but not yet deployed to the instance.
-- **In progress:** Configuration change is currently being deployed to the instance.
-- **Complete:** Configuration change has been deployed to the instance.
-- **Delayed** Initial job to deploy a change has failed and the change has not yet been assigned to a new job.
+- Initiated: Configuration change is made in Switchboard, but not yet deployed to the instance.
+- In progress: Configuration change is currently being deployed to the instance.
+- Complete: Configuration change has been deployed to the instance.
+- Delayed: Initial job to deploy a change has failed and the change has not yet been assigned to a new job.
 
 To view the configuration change log:
 

doc/administration/dedicated/create_instance.md

@@ -230,7 +230,7 @@ Consider the following notes:
 
 #### GitLab release rollout schedule
 
-GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/index.md#upgrades) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the scheduled described below.
+GitLab Dedicated tenant instances are [upgraded](../../subscriptions/gitlab_dedicated/index.md#upgrades) to the minor GitLab release within [the pre-selected window](#maintenance-window) using the schedule described below.
 
 Where **T** is the date of a [minor GitLab release](../../policy/maintenance.md) `N`. GitLab Dedicated instances are upgraded to the `N-1` release as follows:
 

doc/administration/dedicated/index.md

@@ -39,14 +39,14 @@ The cloud provider account is where a highly resilient GitLab installation resid
 
 GitLab team members with edit access can update the [source](https://lucid.app/lucidchart/e69207d3-7428-4ed1-b8a7-902c608cf8a2/edit?invitationId=inv_5922f7f4-4a0b-4024-b152-a00a9d0daa22&page=0_0#) files for the diagram in Lucidchart.
 
-#### Gitaly Setup
+#### Gitaly setup
 
 GitLab Dedicated deploys Gitaly [in a sharded setup](../../administration/gitaly/index.md#before-deploying-gitaly-cluster), not a Gitaly Cluster. In this setup:
 
 - Customer repositories are spread across multiple virtual machines.
 - GitLab manages [storage weights](../../administration/repository_storage_paths.md#configure-where-new-repositories-are-stored) on behalf of the customer.
 
-#### Geo Setup
+#### Geo setup
 
 GitLab Dedicated leverages GitLab Geo for [disaster recovery](../../subscriptions/gitlab_dedicated/index.md#disaster-recovery).
 

doc/ci/runners/runners_scope.md

@@ -169,7 +169,7 @@ To disable instance runners for a project:
 1. Expand **Runners**.
 1. In the **Instance runners** area, turn off the **Enable instance runners for this project** toggle.
 
-instance runners are automatically disabled for a project:
+Instance runners are automatically disabled for a project:
 
 - If the instance runners setting for the parent group is disabled, and
 - If overriding this setting is not permitted at the project level.

doc/ci/triggers/index.md

@@ -109,7 +109,7 @@ In this example:
 - `1234` is the project ID for `project-B`. The project ID is displayed on the
   [project overview page](../../user/project/working_with_projects.md#access-a-project-by-using-the-project-id).
 - The [`rules`](../yaml/index.md#rules) cause the job to run every time a tag is added to `project-A`.
-- `MY_TRIGGER_TOKEN` is a [masked CI/CD variables](../variables/index.md#mask-a-cicd-variable)
+- `MY_TRIGGER_TOKEN` is a [masked CI/CD variable](../variables/index.md#mask-a-cicd-variable)
   that contains the trigger token.
 
 ### Use a webhook

doc/development/cicd/cicd_reference_documentation_guide.md

@@ -54,7 +54,7 @@ is used, like `artifacts:reports:dast`. Afterwards, you can use just the subkey
 ## Keyword type
 
 The keyword can be either a job or global keyword. If it can be used in a `default`
-section, make not of that as well, for example:
+section, make note of that as well. For example:
 
 - `**Keyword type**: Global keyword.`
 - `**Keyword type**: Job keyword. You can use it only as part of a job.`