Merge branch 'doc-remove-in-order-to-one' into 'master'

Doc: Remove instances of "in order to" in docs

See merge request gitlab-org/gitlab!43918

doc/administration/geo/disaster_recovery/index.md

@@ -84,8 +84,8 @@ must disable the **primary** node.
    single recommendation. You may need to:
 
    - Reconfigure the load balancers.
-   - Change DNS records (for example, point the primary DNS record to the **secondary**
-     node in order to stop usage of the **primary** node).
+   - Change DNS records (for example, point the primary DNS record to the
+     **secondary** node to stop usage of the **primary** node).
    - Stop the virtual servers.
    - Block traffic through a firewall.
    - Revoke object storage permissions from the **primary** node.

doc/administration/geo/disaster_recovery/promotion_runbook.md

@@ -192,8 +192,8 @@ follow these steps to avoid unnecessary data loss:
      this, we will avoid a single recommendation. You may need to:
 
      - Reconfigure the load balancers.
-     - Change DNS records (for example, point the **primary** DNS record to the **secondary**
-       node in order to stop usage of the **primary** node).
+     - Change DNS records (for example, point the **primary** DNS record to the
+       **secondary** node to stop usage of the **primary** node).
      - Stop the virtual servers.
      - Block traffic through a firewall.
      - Revoke object storage permissions from the **primary** node.

doc/administration/geo/replication/disable_geo.md

@@ -29,7 +29,7 @@ anymore on these nodes. You can follow our docs to [remove your secondary Geo no
 
 If the current node that you want to keep using is a secondary node, you need to first promote it to primary.
 You can use our steps on [how to promote a secondary node](../disaster_recovery/#step-3-promoting-a-secondary-node)
-in order to do that.
+to do that.
 
 ## Remove the primary node from the UI
 

doc/administration/geo/replication/troubleshooting.md

@@ -492,8 +492,8 @@ to start again from scratch, there are a few steps that can help you:
    gitlab-ctl start geo-postgresql
    ```
 
-   Reconfigure in order to recreate the folders and make sure permissions and ownership
-   are correctly
+   Reconfigure to recreate the folders and make sure permissions and ownership
+   are correct:
 
    ```shell
    gitlab-ctl reconfigure

doc/administration/geo/replication/version_specific_updates.md

@@ -447,8 +447,8 @@ Omnibus is the following:
 
 > **IMPORTANT**:
 With GitLab 9.0, the PostgreSQL version is updated to 9.6 and manual steps are
-required in order to update the **secondary** nodes and keep the Streaming
-Replication working. Downtime is required, so plan ahead.
+required to update the **secondary** nodes and keep the Streaming Replication
+working. Downtime is required, so plan ahead.
 
 The following steps apply only if you update from a 8.17 GitLab version to
 9.0+. For previous versions, update to GitLab 8.17 first before attempting to

doc/administration/geo/setup/database.md

@@ -17,9 +17,10 @@ NOTE: **Note:**
 The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
 
-This document describes the minimal steps you have to take in order to
-replicate your **primary** GitLab database to a **secondary** node's database. You may
-have to change some values according to your database setup, how big it is, etc.
+This document describes the minimal steps you have to take to replicate your
+**primary** GitLab database to a **secondary** node's database. You may have to
+change some values, based on attributes including your database's setup and
+size.
 
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.

doc/administration/gitaly/index.md

@@ -90,7 +90,7 @@ When running Gitaly on its own server, note the following regarding GitLab versi
   leveraged for redundancy on block-level Git data, but only has to be mounted on the Gitaly
   servers.
 - From GitLab 11.8 to 12.2, it is possible to use Elasticsearch in a Gitaly setup that doesn't use
-  NFS. In order to use Elasticsearch in these versions, the
+  NFS. To use Elasticsearch in these versions, the
   [repository indexer](../../integration/elasticsearch.md#elasticsearch-repository-indexer)
   must be enabled in your GitLab configuration.
 - [Since GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/6481), the new indexer is

doc/administration/gitaly/reference.md

@@ -138,8 +138,8 @@ Most of the time we use `git cat-file --batch` processes for that. For
 better performance, Gitaly can re-use these `git cat-file` processes
 across RPC calls. Previously used processes are kept around in a
 ["Git cat-file cache"](https://about.gitlab.com/blog/2019/07/08/git-performance-on-nfs/#enter-cat-file-cache).
-In order to control how much system resources this uses, we have a maximum number
-of cat-file processes that can go into the cache.
+To control how much system resources this uses, we have a maximum number of
+cat-file processes that can go into the cache.
 
 The default limit is 100 `cat-file`s, which constitute a pair of
 `git cat-file --batch` and `git cat-file --batch-check` processes. If

doc/administration/incoming_email.md

@@ -90,7 +90,7 @@ Be careful when choosing the domain used for receiving incoming email.
 For the sake of example, suppose your top-level company domain is `hooli.com`.
 All employees in your company have an email address at that domain via Google
 Apps, and your company's private Slack instance requires a valid `@hooli.com`
-email address in order to sign up.
+email address to sign up.
 
 If you also host a public-facing GitLab instance at `hooli.com` and set your
 incoming email domain to `hooli.com`, an attacker could abuse the "Create new

doc/administration/index.md

@@ -52,7 +52,9 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [GitLab Pages configuration](pages/index.md): Enable and configure GitLab Pages.
 - [GitLab Pages configuration for GitLab source installations](pages/source.md): Enable and configure GitLab Pages on [source installations](../install/installation.md#installation-from-source).
 - [Uploads administration](uploads.md): Configure GitLab uploads storage.
-- [Environment variables](environment_variables.md): Supported environment variables that can be used to override their defaults values in order to configure GitLab.
+- [Environment variables](environment_variables.md): Supported environment
+  variables that can be used to override their default values to configure
+  GitLab.
 - [Plugins](plugins.md): With custom plugins, GitLab administrators can introduce custom integrations without modifying GitLab's source code.
 - [Enforcing Terms of Service](../user/admin_area/settings/terms.md)
 - [Third party offers](../user/admin_area/settings/third_party_offers.md)

doc/administration/job_artifacts.md

@@ -321,7 +321,7 @@ _The uploads are stored by default in
 
 **In Omnibus installations:**
 
-In order to migrate back to local storage:
+To migrate back to local storage:
 
 1. Set both `direct_upload` and `background_upload` to `false` in `gitlab.rb`, under the artifacts object storage settings.
 1. [Reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure).
@@ -424,10 +424,10 @@ generated by [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse).
 that are located in the artifacts archive itself.
 The metadata file is in a binary format, with additional Gzip compression.
 
-GitLab does not extract the artifacts archive in order to save space, memory
-and disk I/O. It instead inspects the metadata file which contains all the
-relevant information. This is especially important when there is a lot of
-artifacts, or an archive is a very large file.
+GitLab doesn't extract the artifacts archive to save space, memory, and disk
+I/O. It instead inspects the metadata file which contains all the relevant
+information. This is especially important when there is a lot of artifacts, or
+an archive is a very large file.
 
 When clicking on a specific file, [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) extracts it
 from the archive and the download begins. This implementation saves space,

doc/administration/libravatar.md

@@ -72,10 +72,9 @@ Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
 missing images for user email addresses that are not found on the Libravatar
 service.
 
-In order to use a set other than `identicon`, replace the `&d=identicon`
-portion of the URL with another supported set.
-For example, you can use the `retro` set, in which case the URL would look like:
-`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
+To use a set other than `identicon`, replace the `&d=identicon` portion of the
+URL with another supported set. For example, you can use the `retro` set, in
+which case the URL would look like: `plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
 
 ## Usage examples for Microsoft Office 365
 

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -9,17 +9,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32351) in GitLab 12.7, behind a disabled feature flag (`self_monitoring_project`).
 > - The feature flag was removed and the Self Monitoring Project was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/198511) in GitLab 12.8.
 
-GitLab has been adding the ability for administrators to see insights into the health of
-their GitLab instance. In order to surface this experience in a native way, similar to how
-you would interact with an application deployed via GitLab, a base project called
-"GitLab self monitoring" with
-[internal visibility](../../../public_access/public_access.md#internal-projects) will be
-added under a group called "GitLab Instance Administrators" specifically created for
-visualizing and configuring the monitoring of your GitLab instance.
-
-All administrators at the time of creation of the project and group will be added
-as maintainers of the group and project, and as an admin, you'll be able to add new
-members to the group in order to give them maintainer access to the project.
+GitLab has been adding the ability for administrators to see insights into the
+health of their GitLab instance. To surface this experience in a native way
+(similar to how you would interact with an application deployed using GitLab),
+a base project called "GitLab self monitoring" with
+[internal visibility](../../../public_access/public_access.md#internal-projects)
+will be added under a group called "GitLab Instance Administrators"
+specifically created for visualizing and configuring the monitoring of your
+GitLab instance.
+
+All administrators at the time of creation of the project and group will be
+added as maintainers of the group and project, and as an admin, you'll be able
+to add new members to the group to give them maintainer access to the project.
 
 This project is used to self monitor your GitLab instance. The metrics dashboard
 of the project shows some basic resource usage charts, such as CPU and memory usage
@@ -74,7 +75,8 @@ you should
 ## Taking action on Prometheus alerts **(ULTIMATE)**
 
 You can [add a webhook](../../../operations/metrics/alerts.md#external-prometheus-instances)
-to the Prometheus configuration in order for GitLab to receive notifications of any alerts.
+to the Prometheus configuration for GitLab to receive notifications of any
+alerts.
 
 Once the webhook is setup, you can
 [take action on incoming alerts](../../../operations/metrics/alerts.md#trigger-actions-from-alerts).

doc/administration/monitoring/performance/index.md

@@ -11,7 +11,7 @@ GitLab comes with its own application performance measuring system as of GitLab
 Community and Enterprise editions.
 
 Apart from this introduction, you are advised to read through the following
-documents in order to understand and properly configure GitLab Performance Monitoring:
+documents to understand and properly configure GitLab Performance Monitoring:
 
 - [GitLab Configuration](gitlab_configuration.md)
 - [Prometheus documentation](../prometheus/index.md)

doc/administration/smime_signing_email.md

@@ -75,8 +75,8 @@ extensions), which contain the following in a single encrypted file:
 - Intermediate certificates (if any)
 - Private key
 
-In order to export the required files in PEM encoding from the PKCS#12 file,
-the `openssl` command can be used:
+To export the required files in PEM encoding from the PKCS#12 file, the
+`openssl` command can be used:
 
 ```shell
 #-- Extract private key in PEM encoding (no password, unencrypted)