Inclusive Lang

Author: VMWare-JasonAndrew

README.md

@@ -35,21 +35,20 @@ List of terms that we want to use consistently in the doc:
 Because **master** is the latest and greatest documentation, the process would be to cut a **x.x** branch
 for the version that **master** was targeting during that time.
 
-After this point, **master** will then be the target for the next version of this product.
+After this point, **master** will be the target for the next version of this product.
 
 ## Partials
 
 Cross-product partials for these docs are single sourced from the [Docs Partials](https://github.com/pivotal-cf/docs-partials) repository.
 
 ## Contributing to Documentation
 
-If there is some documentation to add for an unreleased patch version of these docs, then create a branch off of the live branch
+If there is some documentation to add for an unreleased patch version of these docs, create a branch off of the live branch
 you intend to edit and create a pull request against that branch.
 After the version that change is targeting is released, the pull request can be merged and will be live
 the next time a documentation deployment occurs.
 
-If the documentation is meant to be target several released versions,
-then you must:
+If the documentation is meant to be target several released versions, you must:
 
 - create a pull request for each individual minor version
 - or ask the technical writer to cherry-pick to particular branches/versions.

concourse.html.md.erb

@@ -262,7 +262,7 @@ A typical CI pipeline for a tile consists of the following jobs:
 - Run a set of deployment tests to verify that it deployed and works correctly
 - Remove it from <%= vars.platform_name %>
 
-You describe this pipeline in a `pipeline.yml` file that is then uploaded to the
+You describe this pipeline in a `pipeline.yml` file that is uploaded to the
 Concourse server. [Tile Generator](tile-generator.html) contains a sample
 pipeline that you can clone for your own tile. We are working on automating
 the process of generating a pipeline template for you.

migrating-syslog-configuration.html.md.erb

@@ -86,7 +86,7 @@ By enabling the Ops Manager syslog feature, Ops Manager:
     <td>text</td>
     <td>No</td>
     <td>Additional configuration for rsyslog written in the rainerscript syntax.
-        For example, <code>if ($app-name startswith "exampleComponent") then stop</code>
+        For example, <code> ($app-name startswith "exampleComponent") and stop</code>
         This code drops all traffic from a particular component.
         The entered configuration is applied before the forwarding rule.</td>
   </tr>

on-demand.html.md.erb

@@ -23,7 +23,7 @@ The on-demand services SDK provides a generic on-demand service broker (ODB) tha
 
 The on-demand service author does not write a service broker. Instead, they write a service adapter component that takes requests from the ODB and interfaces with their service software to fulfill requests from the ODB.
 
-To create their tile, the tile author then feeds their service adapter and the BOSH release of the ODB to [Tile Generator](./tile-generator.html).
+To create their tile, the tile author feeds their service adapter and the BOSH release of the ODB to [Tile Generator](./tile-generator.html).
 
 * [On-demand services SDK](https://docs.pivotal.io/svc-sdk/odb/) documentation explains how to write a service adapter for an on-demand service that uses the ODB.
 

releases.html.md.erb

@@ -53,7 +53,7 @@ To create a new Closed Beta release for your product:
 
 1. Clearly state in the release description that the product cannot be upgraded, and that your users may experience data loss.
 
-1. Email your <%= vars.company_name %> contact to request product validation and Closed Beta release. Provide basic instructions on how to validate the new feature set. <%= vars.company_name %> will verify that the release meets all requirements, then make it accessible to invited customers.
+1. Email your <%= vars.company_name %> contact to request product validation and Closed Beta release. Provide basic instructions on how to validate the new feature set. <%= vars.company_name %> will verify that the release meets all requirements, make it accessible to invited customers.
 
 ## <a id='public-beta'></a>Phase 3: Public Beta
 

ssi-creds-tiledev.html.md.erb

@@ -150,7 +150,7 @@ job_types:
 
 ## <a id="step4"></a> Step 4: Store binding credentials in runtime CredHub
 
-When the CC receives a request to bind a service instance to an app, it forwards the request to the service broker. The service broker then returns the binding credentials that allow access to the service.
+When the CC receives a request to bind a service instance to an app, it forwards the request to the service broker. The service broker returns the binding credentials that allow access to the service.
 
 To activate your service broker to store binding credentials in runtime CredHub and make them SSI credentials, do the following:
 

stages.html.md.erb

@@ -37,7 +37,7 @@ A brokered service runs external to <%= vars.app_runtime_abbr %>, but has a tile
 VMware Tanzu Network designates brokered services by including "Service Broker for VMware Tanzu" in the name.
 
 Operators install, configure, and upgrade the tile through the Ops Manager
-Installation Dashboard. Developers can then see your service plans and create
+Installation Dashboard. Developers can see your service plans and create
 service instances in Apps Manager, or by running `cf marketplace` and
 `cf create-service` from the command-line.
 

tile-basics.html.md.erb

@@ -13,7 +13,7 @@ The service broker works by providing an API which the Cloud Controller calls to
 
 In addition to providing an API, a service broker publishes a service catalog that may include multiple service plans, such as a free tier and a metered tier. Brokers register their service plans with the Cloud Controller to populate the Marketplace, which developers access with `cf marketplace` or through Apps Manager.
 
-Cloud operators make software services available to developers by finding them on [VMware Tanzu Network](https://network.pivotal.io/) and then installing and configuring them through a tile interface in the Ops Manager **Installation Dashboard**. Installing a service tile creates a service broker, registers it with the Cloud Controller, and publishes the service plans that the broker offers. Developers can then create service instances in their spaces and bind them to their apps.
+Cloud operators make software services available to developers by finding them on [VMware Tanzu Network](https://network.pivotal.io/) and installing and configuring them through a tile interface in the Ops Manager **Installation Dashboard**. Installing a service tile creates a service broker, registers it with the Cloud Controller, and publishes the service plans that the broker offers. Developers can create service instances in their spaces and bind them to their apps.
 
 See the following:
 

tile-documentation.html.md.erb

@@ -81,7 +81,7 @@ Here's how to install and configure the tile. Typically this includes procedures
 - Upload the product file to your Ops Manager installation.
 - Click Add next to the uploaded product description in the Ops Manager Available Products view to add this product to your staging area.
 - Click the newly added tile to review any configurable options.
-- Click **Review Pending Changes**, then **Apply Changes** to install the service.
+- Click **Review Pending Changes**, and **Apply Changes** to install the service.
 
 #### <a id='upgrading'></a> Upgrading to the uatest version
 

tile-errands.html.md.erb

@@ -155,7 +155,7 @@ broker de-registration. For example, VMware Tanzu SQL [MySQL] has a **Broker Der
 * Deletes the service broker from the Cloud Controller
 
 When an operator chooses to delete the VMware Tanzu SQL [MySQL] product, Ops Manager first
-runs the **Broker Deregistrar** pre-delete errand, then deletes the product.
+runs the **Broker Deregistrar** pre-delete errand, and next deletes the product.
 
 Pre-delete errands run by default. An operator can prevent a pre-delete errand from running by setting
 its [run rule](#run-rules) to **Off** under **Pending Changes** in the Ops Manager Installation

tile-generator.html.md.erb

@@ -17,7 +17,7 @@ you to have intimate knowledge of all the tools involved.
 
 Tile Generator takes your software components and a simple configuration file
 that provides the minimal amount of information to describe and customize your
-tile. It then creates everything that's required to deploy your software into
+tile. It creates everything that's required to deploy your software into
 <%= vars.platform_name %>:
 
 - **BOSH errands** to deploy and delete your software, including blue/green
@@ -62,7 +62,7 @@ For a 7-minute introduction into what Tile Generator is and does, see
 
     - Download the Tile Generator binary for your platform from
     [GitHub](https://github.com/cf-platform-eng/tile-generator/releases/latest),
-      and then make it an executable file and available by running the following commands:
+      and make it an executable file and available by running the following commands:
 
         ```
         chmod +x TILE-BINARY
@@ -122,7 +122,7 @@ initialize the directory as a tile repository by running the following commands:
     ```
 
 The generator first creates a BOSH release in the `release` subdirectory,
-then wraps that release into a tile, in the `product` subdirectory.
+and wraps that release into a tile, in the `product` subdirectory.
 If required for the installation, it automatically pulls down the latest
 release version of the Cloud Foundry CLI.
 
@@ -243,7 +243,7 @@ Apps (including service brokers) that are being `cf push`ed into the
 ```
 
 For apps that are normally pushed as multiple files (node.js for example)
-zip up the project files plus all dependencies into a single ZIP file, then
+zip up the project files plus all dependencies into a single ZIP file, admin
 edit <code>tile.yml</code> to point to the zipped file:
 
 ```bash
@@ -252,7 +252,7 @@ zip -r resources/<your project name>.zip <list of file and dirs to include in th
 ```
 
 If your app is a service broker, use `app-broker` as the type instead of
-`app`. The app is then automatically registered as a broker on install,
+`app`. The app is automatically registered as a broker on install,
 and deleted on uninstall.
 
 `health_check` lets you configure the value of the cf cli `--health_check_type`
@@ -439,7 +439,7 @@ bosh-release package's deployment manifest, you can include the
 Apps packaged as Docker images can be deployed inside or outside <%= vars.app_runtime_abbr %>.
 To push a Docker image as a CF app, use the *Pushed Application*
 format specified above, but use the `docker-app` or `docker-app-broker` type instead
-of `app` or `app-broker`. The Docker image to be used is then specified using
+of `app` or `app-broker`. The Docker image to be used is a specified using
 the `image` property:
 
 ```
@@ -650,7 +650,7 @@ feature:
 
 You can specify any number of service names, optionally specifying a specific
 plan. During deployment, the generated tile creates an instance of each
-service if one does not already exist and then bind that instance to your
+service if one does not already exist and bind that instance to your
 package.
 
 Service instances provisioned this way survive updates, but are deleted
@@ -786,7 +786,7 @@ tile build <old-version>
 tile build <new-version>
 ```
 
-The new tile then supports upgrades from `old-version`.
+The new tile supports upgrades from `old-version`.
 
 
 ## <a id="upgrades"></a> Upgrades

tile-reference/property-blueprints/_disk-type-dropdown.html.erb

@@ -44,7 +44,7 @@ This holds a single string value selected from allowed disk types.
       megabytes, for example, “1024”.  If the operator specifies no value or “Automatic”,
       then this returns the smallest disk that is greater than the <code>default</code>
       value specified in <code>resource_definitions</code>.
-      If no default was specified, then this returns the smallest disk in the catalog.
+      If no default was specified, this returns the smallest disk in the catalog.
     </td>
   </tr>
   <tr>