In order to -> To

Author: ousleyp

.s2i/httpd-cfg/01-commercial.conf

@@ -123,7 +123,7 @@ AddType text/vtt                            vtt
     RewriteEngine On
     RewriteBase /
 
-    # Rules have NE added to the end in order to preserve either explicit or implicit # anchor tags
+    # Rules have NE added to the end to preserve either explicit or implicit # anchor tags
 
     # Redirect 4.0 to 4.1
     RewriteRule ^(container-platform)/4.0/?(.*)$ /container-platform/4\.1/$2 [NE,R=301]

.s2i/httpd-cfg/01-community.conf

@@ -123,7 +123,7 @@ AddType text/vtt                            vtt
     RewriteEngine On
     RewriteBase /
 
-    # Rules have NE added to the end in order to preserve either explicit or implicit # anchor tags
+    # Rules have NE added to the end to preserve either explicit or implicit # anchor tags
 
     # set OKD docs minishift to go to the 3.11 branch as minishift is not on 4.x (yet)
     RewriteRule ^latest/minishift/?(.*)$ /3.11/minishift/$1 [NE,R=301]

_unused_topics/monitoring-monitoring-overview.adoc

@@ -52,6 +52,6 @@ Other {product-title} framework components might be exposing metrics as well. Se
 
 [NOTE]
 ====
-In order to be able to deliver updates with guaranteed compatibility, configurability of the {product-title} Monitoring stack is limited to the explicitly available options.
+To be able to deliver updates with guaranteed compatibility, configurability of the {product-title} Monitoring stack is limited to the explicitly available options.
 ====
 

_unused_topics/monitoring-update-and-compatibility-guarantees.adoc

@@ -5,13 +5,13 @@
 [id="update-and-compatibility-guarantees_{context}"]
 = Update and compatibility guarantees
 
-In order to be able to deliver updates with guaranteed compatibility, configurability of the {product-title} Monitoring stack is limited to the explicitly available options. This document describes known pitfalls of which types of configuration and customization are unsupported, as well as misuse of resources provided by {product-title} Monitoring. All configuration options described in this topic are explicitly supported.
+To be able to deliver updates with guaranteed compatibility, configurability of the {product-title} Monitoring stack is limited to the explicitly available options. This document describes known pitfalls of which types of configuration and customization are unsupported, as well as misuse of resources provided by {product-title} Monitoring. All configuration options described in this topic are explicitly supported.
 
 *Modification of {product-title} monitoring resources*
 
 The {product-title} Monitoring stack ensures its resources are _always_ in the state it expects them to be. If they are modified, {product-title} Monitoring will ensure that this will be reset. Nonetheless it is possible to pause this behavior, by setting the `paused` field in the `AppVersion` called `openshift-monitoring`. Setting the {product-title} Monitoring stack to be paused, stops all future updates and will cause modification of the otherwise managed resources. If resources are modified in an uncontrolled manner, this will cause undefined behavior during updates.
 
-In order to ensure compatible and functioning updates, the `paused` field must be set to `false` on upgrades.
+To ensure compatible and functioning updates, the `paused` field must be set to `false` on upgrades.
 
 *Usage of resources created by {product-title} monitoring*
 

_unused_topics/nodes-pods-priority-examples.adoc

@@ -5,7 +5,7 @@
 [id="nodes-pods-priority-examples_{context}"]
 = Pod priority example scenarios
 
-Pod priority and preemption assigns a priority to pods for scheduling. The scheduler will preempt (evict) lower-priority pods in order to schedule higher-priority pods.
+Pod priority and preemption assigns a priority to pods for scheduling. The scheduler will preempt (evict) lower-priority pods to schedule higher-priority pods.
 
 Typical preemption scenario::
 *Pod P* is a pending pod. 
@@ -43,7 +43,7 @@ Pod priority and cross-node preemption::
 +
 There are no other cases of anti-affinity between *Pod P* and other pods in the zone.
 
-. In order to schedule *Pod P* on *Node N*, the scheduler must preempt *Pod Q* to remove the pod anti-affinity violation, allowing the scheduler to schedule *Pod P* on *Node N*.
+. To schedule *Pod P* on *Node N*, the scheduler must preempt *Pod Q* to remove the pod anti-affinity violation, allowing the scheduler to schedule *Pod P* on *Node N*.
 
 The scheduler can preempt *Pod Q*, but scheduler does not perform cross-node preemption. So, Pod P will be deemed unschedulable on Node N. 
 ////

backup_and_restore/disaster_recovery/about-disaster-recovery.adoc

@@ -8,7 +8,7 @@ toc::[]
 The disaster recovery documentation provides information for administrators on
 how to recover from several disaster situations that might occur with their
 {product-title} cluster. As an administrator, you might need to follow one or
-more of the following procedures in order to return your cluster to a working
+more of the following procedures to return your cluster to a working
 state.
 
 xref:../../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]::

cli_reference/developer_cli_odo/creating_and_deploying_applications_with_odo/sample-applications.adoc

@@ -29,7 +29,7 @@ For `{odo-title}` Java and Node.js are the officially supported component types.
 Run `odo catalog list components` to verify the officially supported component types.
 ====
 
-In order to access the component over the web, create a URL using `odo url create`.
+To access the component over the web, create a URL using `odo url create`.
 
 
 

contributing_to_docs/term_glossary.adoc

@@ -203,7 +203,7 @@ link:doc_guidelines.adoc[Documentation Guidelines] for markup information.
 
 Docker can build images automatically by reading the instructions from a
 Dockerfile. A Dockerfile is a text document that contains all the commands you
-would normally execute manually in order to build a docker image.
+would normally execute manually to build a docker image.
 
 Source: https://docs.docker.com/reference/builder/
 
@@ -570,7 +570,7 @@ This is commonly abbreviated as SCC.
 Usage: service(s)
 
 Kubernetes native API object that serves as an internal load balancer. It
-identifies a set of replicated pods in order to proxy the connections it
+identifies a set of replicated pods to proxy the connections it
 receives to them. Backing pods can be added to or removed from a service
 arbitrarily while the service remains consistently available, enabling anything
 that depends on the service to refer to it at a consistent address.

jaeger/jaeger_arch/rhbjaeger-architecture.adoc

@@ -5,7 +5,7 @@ include::modules/jaeger-document-attributes.adoc[]
 
 toc::[]
 
-Every time a user takes an action in an application, a request is executed by the architecture that may require dozens of different services to participate in order to produce a response.
+Every time a user takes an action in an application, a request is executed by the architecture that may require dozens of different services to participate to produce a response.
 Jaeger lets you perform distributed tracing, which records the path of a request through various microservices that make up an application.
 
 _Distributed tracing_ is a technique that is used to tie the information about different units of work together — usually executed in different processes or hosts — to understand a whole chain of events in a distributed transaction.

migration/migrating_3_4/troubleshooting-3-4.adoc

@@ -8,7 +8,7 @@ toc::[]
 
 You can view the {mtc-full} ({mtc-short}) custom resources and download logs to troubleshoot a failed migration.
 
-If the application was stopped during the failed migration, you must roll it back manually in order to prevent data corruption.
+If the application was stopped during the failed migration, you must roll it back manually to prevent data corruption.
 
 [NOTE]
 ====