Add latest changes from gitlab-org/gitlab@master

2 files changed, 13 insertions, 13 deletions

diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md
index 78705815c24..c08fdf297b4 100644
--- a/doc/ci/migration/circleci.md
+++ b/doc/ci/migration/circleci.md
@@ -276,17 +276,17 @@ There are two GitLab issues open addressing CircleCI Orbs and how GitLab can ach
 
 ## Build environments
 
-CircleCI offers `executors` as the underlying technology to run a specific job. In GitLab, this is done by [Runners](https://docs.gitlab.com/runner/).
+CircleCI offers `executors` as the underlying technology to run a specific job. In GitLab, this is done by [runners](https://docs.gitlab.com/runner/).
 
 The following environments are supported:
 
-Self-Managed Runners:
+Self-managed runners:
 
 - Linux
 - Windows
 - macOS
 
-GitLab.com Shared Runners:
+GitLab.com shared runners:
 
 - Linux
 - Windows
@@ -294,7 +294,7 @@ GitLab.com Shared Runners:
 
 ### Machine and specific build environments
 
-[Tags](../yaml/README.md#tags) can be used to run jobs on different platforms, by telling GitLab which Runners should run the jobs.
+[Tags](../yaml/README.md#tags) can be used to run jobs on different platforms, by telling GitLab which runners should run the jobs.
 
 CircleCI example of a job running on a specific environment:
 
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 1d029dcdd14..6857e736580 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -17,7 +17,7 @@ that were able to quickly complete this migration:
 
 1. Start by reading the GitLab CI/CD [Quick Start Guide](../quick_start/README.md) and [important product differences](#important-product-differences).
 1. Learn the importance of [managing the organizational transition](#managing-the-organizational-transition).
-1. [Add Runners](../runners/README.md) to your GitLab instance.
+1. [Add runners](../runners/README.md) to your GitLab instance.
 1. Educate and enable your developers to independently perform the following steps in their projects:
    1. Review the [Quick Start Guide](../quick_start/README.md) and [Pipeline Configuration Reference](../yaml/README.md).
    1. Use the [Jenkins Wrapper](#jenkinsfile-wrapper) to temporarily maintain fragile Jenkins jobs.
@@ -117,26 +117,26 @@ There are some high level differences between the products worth mentioning:
   or other manual jobs that function like utilities. Jenkins installations tend to
   have a few of these.
 
-## Agents vs. Runners
+## Agents vs. runners
 
-Both Jenkins agents and GitLab Runners are the hosts that run jobs. To convert the
+Both Jenkins agents and GitLab runners are the hosts that run jobs. To convert the
 Jenkins agent, simply uninstall it and then [install and register the runner](../runners/README.md).
 Runners do not require much overhead, so you can size them similarly to the Jenkins
 agents you were using.
 
-There are some important differences in the way Runners work in comparison to agents:
+There are some important differences in the way runners work in comparison to agents:
 
 - Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/README.md#types-of-runners).
   They will self-select jobs from the scopes you've defined automatically.
 - You can also [use tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
   associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
-- GitLab has [autoscaling for Runners](https://docs.gitlab.com/runner/configuration/autoscale.html)
+- GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html)
   which will let you configure them to be provisioned as needed, and scaled down when not.
   This is similar to ephemeral agents in Jenkins.
 
-If you are using `gitlab.com`, you can take advantage of our [shared Runner fleet](../../user/gitlab_com/index.md#shared-runners)
-to run jobs without provisioning your own Runners. We are investigating making them
+If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../../user/gitlab_com/index.md#shared-runners)
+to run jobs without provisioning your own runners. We are investigating making them
 [available for self-managed instances](https://gitlab.com/groups/gitlab-org/-/epics/835)
 as well.
 
@@ -225,11 +225,11 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 
 #### `agent`
 
-The agent section is used to define how a pipeline will be executed. For GitLab, we use the [GitLab Runner](../runners/README.md)
+The agent section is used to define how a pipeline will be executed. For GitLab, we use [runners](../runners/README.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
 of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users.) The link above will bring you to the documentation which will describe how to get
 up and running quickly. We also support using [tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
-to different Runners (execution agents).
+to different runners (execution agents).
 
 The `agent` section also allows you to define which Docker images should be used for execution, for which we use
 the [`image`](../yaml/README.md#image) keyword. The `image` can be set on a single job or at the top level, in which