Merge branch 'fneill-doc-fixes-3' into 'master'

Fix style and language issues in CI/CD pages

See merge request gitlab-org/gitlab!69746

doc/development/cicd/index.md

@@ -16,7 +16,7 @@ to learn how to update the [reference page](../../ci/yaml/index.md).
 
 ## CI Architecture overview
 
-The following is a simplified diagram of the CI architecture. Some details are left out in order to focus on
+The following is a simplified diagram of the CI architecture. Some details are left out to focus on
 the main components.
 
 ![CI software architecture](img/ci_architecture.png)
@@ -73,7 +73,7 @@ which picks the next job and assigns it to the runner. At this point the job tra
 For more details read [Job scheduling](#job-scheduling)).
 
 While a job is being executed, the runner sends logs back to the server as well any possible artifacts
-that need to be stored. Also, a job may depend on artifacts from previous jobs in order to run. In this
+that must be stored. Also, a job may depend on artifacts from previous jobs to run. In this
 case the runner downloads them using a dedicated API endpoint.
 
 Artifacts are stored in object storage, while metadata is kept in the database. An important example of artifacts
@@ -111,7 +111,7 @@ Once all jobs are completed for the current stage, the server "unlocks" all the
 
 ### Communication between runner and GitLab server
 
-Once the runner is [registered](https://docs.gitlab.com/runner/register/) using the registration token, the server knows what type of jobs it can execute. This depends on:
+After the runner is [registered](https://docs.gitlab.com/runner/register/) using the registration token, the server knows what type of jobs it can execute. This depends on:
 
 - The type of runner it is registered as:
   - a shared runner
@@ -119,7 +119,7 @@ Once the runner is [registered](https://docs.gitlab.com/runner/register/) using
   - a project specific runner
 - Any associated tags.
 
-The runner initiates the communication by requesting jobs to execute with `POST /api/v4/jobs/request`. Although this polling generally happens every few seconds we leverage caching via HTTP headers to reduce the server-side work load if the job queue doesn't change.
+The runner initiates the communication by requesting jobs to execute with `POST /api/v4/jobs/request`. Although polling happens every few seconds, we leverage caching through HTTP headers to reduce the server-side work load if the job queue doesn't change.
 
 This API endpoint runs [`Ci::RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/register_job_service.rb), which:
 

doc/development/cicd/templates.md

@@ -178,10 +178,10 @@ This includes:
 
 - Repository/project requirements.
 - Expected behavior.
-- Any places that need to be edited by users before using the template.
+- Any places that must be edited by users before using the template.
 - If the template should be used by copy pasting it into a configuration file, or
   by using it with the `include` keyword in an existing pipeline.
-- If any variables need to be saved in the project's CI/CD settings.
+- If any variables must be saved in the project's CI/CD settings.
 
 ```yaml
 # Use this template to publish an application that uses the ABC server.
@@ -335,7 +335,7 @@ follow the progress.
 
 ## Testing
 
-Each CI/CD template must be tested in order to make sure that it's safe to be published.
+Each CI/CD template must be tested to make sure that it's safe to be published.
 
 ### Manual QA
 
@@ -380,7 +380,7 @@ is updated in a major version GitLab release.
 
 A template could contain malicious code. For example, a template that contains the `export` shell command in a job
 might accidentally expose secret project CI/CD variables in a job log.
-If you're unsure if it's secure or not, you need to ask security experts for cross-validation.
+If you're unsure if it's secure or not, you must ask security experts for cross-validation.
 
 ## Contribute CI/CD template merge requests