no to 'need to'

Author: kalexand-rh

_stylesheets/sass/settings/_origin.scss

@@ -46,7 +46,7 @@ $pre-padding: .8em .8em .6em .8em;
 $list-side-margin: emCalc(24px);
 $definition-list-header-margin-bottom: emCalc(5px);
 $definition-list-margin-bottom: emCalc(20px);
-// FIXME need to account for nested definition list
+// FIXME must account for nested definition list
 //$definition-list-content-margin-left: 0;
 
 // Blockquotes

applications/deployments/route-based-deployment-strategies.adoc

@@ -41,7 +41,7 @@ above strategies.
 
 The route-based deployment strategies do not scale the number of Pods in the
 services. To maintain desired performance characteristics the deployment
-configurations may need to be scaled.
+configurations might have to be scaled.
 
 include::modules/deployments-proxy-shards.adoc[leveloffset=+1]
 include::modules/deployments-n1-compatibility.adoc[leveloffset=+1]

applications/deployments/what-deployments-are.adoc

@@ -40,14 +40,14 @@ Deployments and DeploymentConfigs are enabled by the use of native Kubernetes
 API objects ReplicationControllers and ReplicaSets, respectively, as their
 building blocks.
 
-Users do not need to manipulate ReplicationControllers, ReplicaSets, or Pods
+Users do not have to manipulate ReplicationControllers, ReplicaSets, or Pods
 owned by DeploymentConfigs or Deployments. The deployment systems ensures
 changes are propagated appropriately.
 
 [TIP]
 ====
 If the existing deployment strategies are not suited for your use case and you
-have the need to run manual steps during the lifecycle of your deployment, then
+must run manual steps during the lifecycle of your deployment, then
 you should consider creating a Custom deployment strategy.
 ====
 

authentication/configuring-internal-oauth.adoc

@@ -6,7 +6,7 @@ toc::[]
 
 [IMPORTANT]
 ====
-Configuring these options will need to change because they're set in the master
+Configuring these options must change because they're set in the master
 config file now.
 ====
 

build.py

@@ -318,7 +318,7 @@ def reformat_for_drupal(info):
     distro = info['distro']
 
     # Build a mapping of files to ids
-    # Note: For all-in-one we need to collect ids from all books first
+    # Note: For all-in-one we have to collect ids from all books first
     file_to_id_map = {}
     if info['all_in_one']:
         book_ids = []
@@ -941,9 +941,9 @@ def main():
 
     # Copy the original data and reformat for drupal
     reformat_for_drupal(info)
-    
+
     if has_errors:
-        sys.exit(1)        
+        sys.exit(1)
 
     if args.push:
         # Parse the repo urls

contributing_to_docs/create_or_edit_content.adoc

@@ -28,7 +28,7 @@ with the remote repository.
 ====
 Because most changes in this repository must be committed to the `master`
 branch, the following process always uses `master` as the name of the source
-branch. If you need to use another branch as the source for your change, make
+branch. If you must use another branch as the source for your change, make
 sure that you consistently use that branch name instead of `master`
 ====
 

contributing_to_docs/doc_guidelines.adoc

@@ -278,7 +278,7 @@ even if you are linking to the same directory that you are writing in. This make
 operations to fix broken links much easier.
 
 For example, if you are writing in *_architecture/core_concepts/deployments.adoc_* and you want to
-link to *_architecture/core_concepts/routes.adoc_* then you would need to include the path back to the first
+link to *_architecture/core_concepts/routes.adoc_* then you must include the path back to the first
 level of the assembly directory:
 
 ----
@@ -385,7 +385,7 @@ If you want to link to an image:
 image::<name_of_image>[image]
 ----
 
-You only need to specify `<name_of_image>`. The build mechanism automatically specifies the file path.
+You only have to specify `<name_of_image>`. The build mechanism automatically specifies the file path.
 
 == Formatting
 
@@ -401,7 +401,7 @@ For all of the system blocks including table delimiters, use four characters. Fo
 Code blocks are used to show examples of command screen outputs, or
 configuration files. When using command blocks, always use the actual values for
 any items that a user would normally replace. Code blocks should represent
-exactly what a customer would see on their screen. If you need to expand or
+exactly what a customer would see on their screen. If you must expand or
 provide information on what some of the contents of a screen output or
 configuration file represent, then use callouts to provide that information.
 
@@ -561,7 +561,7 @@ This will render as such:
 
 . Item 3
 
-If you need to add any text, admonitions, or code blocks you need to add the continuous +, as shown in the example:
+If you must add any text, admonitions, or code blocks you have to add the continuous +, as shown in the example:
 
 ....
 . Item 1

contributing_to_docs/term_glossary.adoc

@@ -322,7 +322,7 @@ more on Operator naming.
 
 Usage: Pod(s) as appropriate
 
-Kubernetes object that groups related Docker containers that need to share
+Kubernetes object that groups related Docker containers that have to share
 network, filesystem, or memory together for placement on a node. Multiple
 instances of a Pod can run to provide scaling and redundancy.
 

contributing_to_docs/tools_and_setup.adoc

@@ -26,7 +26,7 @@ $ ssh -T git@github.com
 
 == Fork and clone the OpenShift documentation repository
 You must fork and set up the OpenShift documentation repository on your
-workstation so that you can create PRs and contribute. These steps only need to
+workstation so that you can create PRs and contribute. These steps must only
 be performed during initial setup.
 
 1. Fork the https://github.com/openshift/openshift-docs repository into your