Docs: Update files to remove "in order to"

doc/ci/docker/using_kaniko.md

@@ -17,13 +17,13 @@ kaniko solves two problems with using the
 build](using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor) method:
 
 - Docker-in-Docker requires [privileged mode](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
-  in order to function, which is a significant security concern.
+  to function, which is a significant security concern.
 - Docker-in-Docker generally incurs a performance penalty and can be quite slow.
 
 ## Requirements
 
-In order to utilize kaniko with GitLab, [a runner](https://docs.gitlab.com/runner/)
-with one of the following executors is required:
+To use kaniko with GitLab, [a runner](https://docs.gitlab.com/runner/) with one
+of the following executors is required:
 
 - [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html).
 - [Docker](https://docs.gitlab.com/runner/executors/docker.html).

doc/ci/examples/artifactory_and_gitlab/index.md

@@ -23,10 +23,10 @@ We also assume that an Artifactory instance is available and reachable from the
 
 ## Create the simple Maven dependency
 
-First of all, you need an application to work with: in this specific case we will
-use a simple one, but it could be any Maven application. This will be the
-dependency you want to package and deploy to Artifactory, in order to be
-available to other projects.
+First, you need an application to work with: in this specific case we'll use a
+simple one, but it could be any Maven application. This will be the dependency
+you want to package and deploy to Artifactory, to be available to other
+projects.
 
 ### Prepare the dependency application
 
@@ -58,7 +58,7 @@ The application is ready to use, but you need some additional steps to deploy it
 1. Log in to Artifactory with your user's credentials.
 1. From the main screen, click on the `libs-release-local` item in the **Set Me Up** panel.
 1. Copy to clipboard the configuration snippet under the **Deploy** paragraph.
-1. Change the `url` value in order to have it configurable via variables.
+1. Change the `url` value to have it configurable by using variables.
 1. Copy the snippet in the `pom.xml` file for your project, just after the
    `dependencies` section. The snippet should look like this:
 
@@ -146,8 +146,9 @@ deploy:
     - master
 ```
 
-The runner will use the latest [Maven Docker image](https://hub.docker.com/_/maven/), which already contains all the tools and the dependencies you need to manage the project,
-in order to run the jobs.
+The runner uses the latest [Maven Docker image](https://hub.docker.com/_/maven/),
+which contains all of the tools and dependencies needed to manage the project
+and to run the jobs.
 
 Environment variables are set to instruct Maven to use the `homedir` of the repository instead of the user's home when searching for configuration and dependencies.
 

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -95,9 +95,10 @@ dependency upgrade did not break anything without even having to look at your we
 
 ## Running locally
 
-We'll get to running the above test in CI/CD in a moment. When writing tests, however, it helps if
-you do not have to wait for your pipelines to succeed in order to check whether they do what you
-expect them to do. In other words, let's get it to run locally.
+We'll get to running the above test in CI/CD in a moment. When writing tests,
+however, it helps if you don't have to wait for your pipelines to succeed to
+determine whether they do what you expect them to do. In other words, let's get
+it to run locally.
 
 Make sure that your app is running locally. If you use Webpack,
 you can use [the Webpack Dev Server WebdriverIO plugin](https://www.npmjs.com/package/wdio-webpack-dev-server-service)

doc/ci/examples/php.md

@@ -141,12 +141,11 @@ Of course, `my_php.ini` must be present in the root directory of your repository
 
 ## Test PHP projects using the Shell executor
 
-The shell executor runs your job in a terminal session on your server.
-Thus, in order to test your projects you first need to make sure that all
-dependencies are installed.
+The shell executor runs your job in a terminal session on your server. To test
+your projects, you must first ensure that all dependencies are installed.
 
-For example, in a VM running Debian 8 we first update the cache, then we
-install `phpunit` and `php5-mysql`:
+For example, in a VM running Debian 8, first update the cache, and then install
+`phpunit` and `php5-mysql`:
 
 ```shell
 sudo apt-get update -y
@@ -219,8 +218,8 @@ test:atoum:
 ### Using Composer
 
 The majority of the PHP projects use Composer for managing their PHP packages.
-In order to execute Composer before running your tests, simply add the
-following in your `.gitlab-ci.yml`:
+To execute Composer before running your tests, add the following to your
+`.gitlab-ci.yml`:
 
 ```yaml
 # Composer stores all downloaded packages in the vendor/ directory.
@@ -243,14 +242,14 @@ before_script:
 ## Access private packages or dependencies
 
 If your test suite needs to access a private repository, you need to configure
-[the SSH keys](../ssh_keys/README.md) in order to be able to clone it.
+the [SSH keys](../ssh_keys/README.md) to be able to clone it.
 
 ## Use databases or other services
 
-Most of the time you will need a running database in order for your tests to
-run. If you are using the Docker executor you can leverage Docker's ability to
-link to other containers. With GitLab Runner, this can be achieved by
-defining a `service`.
+Most of the time, you need a running database for your tests to be able to
+run. If you're using the Docker executor, you can leverage Docker's ability to
+link to other containers. With GitLab Runner, this can be achieved by defining
+a `service`.
 
 This functionality is covered in [the CI services](../services/README.md)
 documentation.

doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md

@@ -68,7 +68,7 @@ First install [Docker Engine](https://docs.docker.com/installation/).
 
 To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/).
 You can use public runners available on `gitlab.com` or register your own. Start by
-creating a template configuration file in order to pass complex configuration:
+creating a template configuration file to pass complex configuration:
 
 ```shell
 cat > /tmp/test-config.template.toml << EOF

doc/ci/merge_request_pipelines/index.md

@@ -125,8 +125,9 @@ Therefore:
 - Since `C` specifies that it should only run for merge requests, it will not run for any pipeline
   except a merge request pipeline.
 
-This helps you avoid having to add the `only:` rule to all of your jobs
-in order to make them always run. You can use this format to set up a Review App, helping to save resources.
+This helps you avoid having to add the `only:` rule to all of your jobs to make
+them always run. You can use this format to set up a Review App, helping to
+save resources.
 
 #### Excluding certain branches
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -80,8 +80,8 @@ For more information, read the [documentation on Merge Trains](merge_trains/inde
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12996) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
 
-GitLab CI/CD can detect the presence of redundant pipelines,
-and will cancel them automatically in order to conserve CI resources.
+GitLab CI/CD can detect the presence of redundant pipelines, and cancels them
+to conserve CI resources.
 
 When a user merges a merge request immediately within an ongoing merge
 train, the train will be reconstructed, as it will recreate the expected

doc/ci/pipelines/job_artifacts.md

@@ -37,8 +37,8 @@ pdf:
     expire_in: 1 week
 ```
 
-A job named `pdf` calls the `xelatex` command in order to build a PDF file from
-the latex source file `mycv.tex`. We then define the `artifacts` paths which in
+A job named `pdf` calls the `xelatex` command to build a PDF file from the
+latex source file `mycv.tex`. We then define the `artifacts` paths which in
 turn are defined with the `paths` keyword. All paths to files and directories
 are relative to the repository that was cloned during the build.
 
@@ -429,7 +429,9 @@ To erase a job:
 
 ## Retrieve artifacts of private projects when using GitLab CI
 
-In order to retrieve a job artifact of a different project, you might need to use a private token in order to [authenticate and download](../../api/job_artifacts.md#get-job-artifacts) the artifacts.
+To retrieve a job artifact from a different project, you might need to use a
+private token to [authenticate and download](../../api/job_artifacts.md#get-job-artifacts)
+the artifact.
 
 ## Troubleshooting
 

doc/ci/ssh_keys/README.md

@@ -134,7 +134,8 @@ on, and use that key for all projects that are run on this machine.
    If you are accessing a private GitLab repository you need to add it as a
    [deploy key](../../ssh/README.md#deploy-keys).
 
-Once done, try to log in to the remote server in order to accept the fingerprint:
+After generating the key, try to sign in to the remote server to accept the
+fingerprint:
 
 ```shell
 ssh example.com

doc/ci/triggers/README.md

@@ -183,9 +183,9 @@ webhook URL for Push and Tag events (change the project ID, ref and token):
 https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN
 ```
 
-`ref` should be passed as part of the URL in order to take precedence over
-`ref` from the webhook body that designates the branch ref that fired the
-trigger in the source repository. `ref` should be URL-encoded if it contains slashes.
+You should pass `ref` as part of the URL, to take precedence over `ref` from
+the webhook body that designates the branch ref that fired the trigger in the
+source repository. Be sure to URL-encode `ref` if it contains slashes.
 
 ## Making use of trigger variables
 

doc/ci/yaml/README.md

@@ -2562,9 +2562,9 @@ deploy to production:
 >   defined, GitLab automatically triggers a stop action when the associated
 >   branch is deleted.
 
-Closing (stopping) environments can be achieved with the `on_stop` keyword defined under
-`environment`. It declares a different job that runs in order to close
-the environment.
+Closing (stopping) environments can be achieved with the `on_stop` keyword
+defined under `environment`. It declares a different job that runs to close the
+environment.
 
 Read the `environment:action` section for an example.