Remove "in order to" uses in docs

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -204,8 +204,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 using 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/runbooks/planned_failover_single_node.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 using the **primary** node).
      - Stop the virtual servers.
      - Block traffic through a firewall.
      - Revoke object storage permissions from the **primary** node.

doc/administration/monitoring/prometheus/index.md

@@ -60,9 +60,9 @@ it's not recommended to change the port Prometheus listens
 on, as this might affect or conflict with other services running on the GitLab
 server. Proceed at your own risk.
 
-In order to access Prometheus from outside the GitLab server you will need to
-set a FQDN or IP in `prometheus['listen_address']`.
-To change the address/port that Prometheus listens on:
+To access Prometheus from outside the GitLab server, set an FQDN or IP in
+`prometheus['listen_address']`. To change the address/port that Prometheus
+listens on:
 
 1. Edit `/etc/gitlab/gitlab.rb`
 1. Add or find and uncomment the following line:

doc/administration/pages/index.md

@@ -370,8 +370,8 @@ Pages access control is disabled by default. To enable it:
 1. Users can now configure it in their [projects' settings](../../user/project/pages/pages_access_control.md).
 
 NOTE: **Important:**
-For multi-node setups, in order for this setting to be effective, it has to be applied
-to all the App nodes as well as the Sidekiq nodes.
+For this setting to be effective with multi-node setups, it has to be applied to
+all the App nodes and Sidekiq nodes.
 
 #### Disabling public access to all Pages websites
 
@@ -397,8 +397,7 @@ redeployed. This issue will be resolved by
 ### Running behind a proxy
 
 Like the rest of GitLab, Pages can be used in those environments where external
-internet connectivity is gated by a proxy. In order to use a proxy for GitLab
-pages:
+internet connectivity is gated by a proxy. To use a proxy for GitLab Pages:
 
 1. Configure in `/etc/gitlab/gitlab.rb`:
 
@@ -508,7 +507,8 @@ To override the global maximum pages size for a specific group:
 
 ## Running GitLab Pages on a separate server
 
-You can run the GitLab Pages daemon on a separate server in order to decrease the load on your main application server.
+You can run the GitLab Pages daemon on a separate server to decrease the load on
+your main application server.
 
 To configure GitLab Pages on a separate server:
 

doc/administration/postgresql/replication_and_failover.md

@@ -93,9 +93,9 @@ information.
 
 #### Network information
 
-PostgreSQL does not listen on any network interface by default. It needs to know
-which IP address to listen on in order to be accessible to other services.
-Similarly, PostgreSQL access is controlled based on the network source.
+PostgreSQL doesn't listen on any network interface by default. It needs to know
+which IP address to listen on to be accessible to other services. Similarly,
+PostgreSQL access is controlled based on the network source.
 
 This is why you will need:
 

doc/administration/raketasks/doctor.md

@@ -47,9 +47,8 @@ I, [2020-06-11T17:18:15.575711 #27148]  INFO -- : Done!
 
 ### Verbose mode
 
-In order to get more detailed information about which
-rows and columns cannot be decrypted, you can pass a VERBOSE
-environment variable:
+To get more detailed information about which rows and columns can't be
+decrypted, you can pass a `VERBOSE` environment variable:
 
 **Omnibus Installation**
 

doc/administration/raketasks/github_import.md

@@ -2,9 +2,8 @@
 
 > [Introduced]( https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10308) in GitLab 9.1.
 
-In order to retrieve and import GitHub repositories, you will need a
-[GitHub personal access token](https://github.com/settings/tokens).
-A username should be passed as the second argument to the Rake task
+To retrieve and import GitHub repositories, you need a [GitHub personal access token](https://github.com/settings/tokens).
+A username should be passed as the second argument to the Rake task,
 which will become the owner of the project. You can resume an import
 with the same command.
 

doc/administration/redis/replication_and_failover.md

@@ -124,9 +124,9 @@ each other over the network.
 ### Sentinel setup overview
 
 Sentinels watch both other Sentinels and Redis nodes. Whenever a Sentinel
-detects that a Redis node is not responding, it will announce that to the
-other Sentinels. They have to reach the **quorum**, that is the minimum amount
-of Sentinels that agrees a node is down, in order to be able to start a failover.
+detects that a Redis node isn't responding, it announces the node's status to
+the other Sentinels. The Sentinels have to reach a _quorum_ (the minimum amount
+of Sentinels agreeing a node is down) to be able to start a failover.
 
 Whenever the **quorum** is met, the **majority** of all known Sentinel nodes
 need to be available and reachable, so that they can elect the Sentinel **leader**

doc/administration/snippets/index.md

@@ -20,8 +20,8 @@ abuse of the feature. The default value is **52428800 Bytes** (50 MB).
 
 The content size limit will be applied when a snippet is created or updated.
 
-In order not to break any existing snippets, the limit doesn't have any
-effect on them until a snippet is edited again and the content changes.
+This limit doesn't affect existing snippets until they're updated and their
+content changes.
 
 ### Snippets size limit configuration
 

doc/api/container_registry.md

@@ -230,7 +230,7 @@ DELETE /projects/:id/registry/repositories/:repository_id/tags/:tag_name
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/registry/repositories/2/tags/v10.0.0"
 ```
 
-This action does not delete blobs. In order to delete them and recycle disk space,
+This action doesn't delete blobs. To delete them and recycle disk space,
 [run the garbage collection](https://docs.gitlab.com/omnibus/maintenance/README.html#removing-unused-layers-not-referenced-by-manifests).
 
 ## Delete registry repository tags in bulk
@@ -256,18 +256,19 @@ DELETE /projects/:id/registry/repositories/:repository_id/tags
 
 This API call performs the following operations:
 
-1. It orders all tags by creation date. The creation date is the time of the
-   manifest creation, not the time of tag push.
-1. It removes only the tags matching the given `name_regex_delete` (or deprecated `name_regex`), keeping any that match `name_regex_keep`.
-1. It never removes the tag named `latest`.
-1. It keeps N latest matching tags (if `keep_n` is specified).
-1. It only removes tags that are older than X amount of time (if `older_than` is specified).
-1. It schedules the asynchronous job to be executed in the background.
-
-These operations are executed asynchronously and it might
-take time to get executed. You can run this at most
-once an hour for a given container repository.
-This action does not delete blobs. In order to delete them and recycle disk space,
+- It orders all tags by creation date. The creation date is the time of the
+  manifest creation, not the time of tag push.
+- It removes only the tags matching the given `name_regex_delete` (or deprecated
+  `name_regex`), keeping any that match `name_regex_keep`.
+- It never removes the tag named `latest`.
+- It keeps N latest matching tags (if `keep_n` is specified).
+- It only removes tags that are older than X amount of time (if `older_than` is
+  specified).
+- It schedules the asynchronous job to be executed in the background.
+
+These operations are executed asynchronously and can take time to get executed.
+You can run this at most once an hour for a given container repository. This
+action doesn't delete blobs. To delete them and recycle disk space,
 [run the garbage collection](https://docs.gitlab.com/omnibus/maintenance/README.html#removing-unused-layers-not-referenced-by-manifests).
 
 NOTE: **Note:**

doc/api/geo_nodes.md

 # Geo Nodes API **(PREMIUM ONLY)**
 
-In order to interact with Geo node endpoints, you need to authenticate yourself
-as an admin.
+To interact with Geo node endpoints, you need to authenticate yourself as an
+admin.
 
 ## Create a new Geo node
 

doc/api/issue_links.md

@@ -58,19 +58,20 @@ Parameters:
 
 ## Create an issue link
 
-Creates a two-way relation between two issues. User must be allowed to update both issues in order to succeed.
+Creates a two-way relation between two issues. The user must be allowed to
+update both issues to succeed.
 
 ```plaintext
 POST /projects/:id/issues/:issue_iid/links
 ```
 
-| Attribute   | Type    | Required | Description                          |
-|-------------|---------|----------|--------------------------------------|
-| `id`        | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user  |
-| `issue_iid` | integer | yes      | The internal ID of a project's issue |
+| Attribute           | Type           | Required | Description                          |
+|---------------------|----------------|----------|--------------------------------------|
+| `id`                | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `issue_iid`         | integer        | yes      | The internal ID of a project's issue |
 | `target_project_id` | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) of a target project  |
-| `target_issue_iid` | integer/string | yes      | The internal ID of a target project's issue |
-| `link_type` | string  | no | The type of the relation ("relates_to", "blocks", "is_blocked_by"), defaults to "relates_to"). |
+| `target_issue_iid`  | integer/string | yes      | The internal ID of a target project's issue |
+| `link_type`         | string         | no       | The type of the relation ("relates_to", "blocks", "is_blocked_by"), defaults to "relates_to"). |
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/4/issues/1/links?target_project_id=5&target_issue_iid=1"

doc/api/license.md

 # License **(CORE ONLY)**
 
-In order to interact with license endpoints, you need to authenticate yourself
-as an admin.
+To interact with license endpoints, you need to authenticate yourself as an
+admin.
 
 ## Retrieve information about the current license
 

doc/api/merge_request_approvals.md

@@ -60,7 +60,7 @@ POST /projects/:id/approvals
 | `disable_overriding_approvers_per_merge_request` | boolean | no       | Allow/Disallow overriding approvers per MR                                                          |
 | `merge_requests_author_approval`                 | boolean | no       | Allow/Disallow authors from self approving merge requests; `true` means authors can self approve |
 | `merge_requests_disable_committers_approval`     | boolean | no       | Allow/Disallow committers from self approving merge requests                                        |
-| `require_password_to_approve`                    | boolean | no       | Require approver to enter a password in order to authenticate before adding the approval         |
+| `require_password_to_approve`                    | boolean | no       | Require approver to enter a password to authenticate before adding the approval         |
 
 ```json
 {

doc/api/settings.md

@@ -2,8 +2,8 @@
 
 These API calls allow you to read and modify GitLab instance
 [application settings](#list-of-settings-that-can-be-accessed-via-api-calls)
-as appear in `/admin/application_settings/general`. You have to be an
-administrator in order to perform this action.
+as they appear in `/admin/application_settings/general`. You must be an
+administrator to perform this action.
 
 ## Get current application settings
 
@@ -185,12 +185,12 @@ Example responses: **(PREMIUM ONLY)**
 
 ## List of settings that can be accessed via API calls
 
-In general, all settings are optional. Certain settings though, if enabled, will
-require other settings to be set in order to function properly. These requirements
-are listed in the descriptions of the relevant settings.
+In general, all settings are optional. Certain settings though, if enabled,
+require other settings to be set to function properly. These requirements are
+listed in the descriptions of the relevant settings.
 
-| Attribute | Type | Required | Description |
-| --------- | ---- | :------: | ----------- |
+| Attribute                                | Type             | Required                             | Description |
+|------------------------------------------|------------------|:------------------------------------:|-------------|
 | `admin_notification_email`               | string           | no                                   | Deprecated: Use `abuse_notification_email` instead. If set, [abuse reports](../user/admin_area/abuse_reports.md) are sent to this address. Abuse reports are always available in the Admin Area.  |
 | `abuse_notification_email`               | string           | no                                   | If set, [abuse reports](../user/admin_area/abuse_reports.md) are sent to this address. Abuse reports are always available in the Admin Area. |
 | `after_sign_out_path`                    | string           | no                                   | Where to redirect users after logout. |