Inclusive language

Author: VMWare-JasonAndrew

bosh-release.html.md.erb

@@ -87,5 +87,5 @@ For an example, see [pcf-examples/tile-for-bosh-with-syslog](https://github.com/
 ## <a id="backup"></a>BOSH backup and restore
 
 The [BOSH Backup and Restore Developer's Guide](https://docs.cloudfoundry.org/bbr/bbr-devguide.html)
-describes the framework for release authors to add backup and restore functionality
+describes the framework for release authors to add backup and restore capability.
 to their release by using BOSH Backup and Restore (BBR).

concourse.html.md.erb

@@ -218,7 +218,7 @@ To specify the UAA users:
 ### <a id="test"></a> About test configuration
 
 After your tile is installed, Tile Dashboard runs any post-deploy errands your tile has defined, including tests.
-Ideally your tile includes tests that exercise all of its functionality.
+Ideally your tile includes tests that exercise all of its capability.
 We have some ideas for expanding the Tile Dashboard testing capabilities;
 if you’re interested in other ways of defining tests,
 contact us on [Partners Slack](https://pivotalpartners.slack.com/).

migrating-syslog-configuration.html.md.erb

@@ -133,7 +133,7 @@ For more information, see [opsmanager_syslog](./property-template-references.htm
     * From your deployment manifest, syslog configuration properties.
 
 1. To ensure that operators do not try to update syslog configuration properties with no outward
-functionality, mark all existing syslog configuration properties in your product as non-configurable.
+capability, mark all existing syslog configuration properties in your product as non-configurable.
 
 1. Update the description for the deprecated properties to state that they are deprecated and are no
 longer used to configure the syslog.

releases.html.md.erb

@@ -78,7 +78,7 @@ Products in Public Beta must meet the following requirements:
 
 * The product supports upgrade paths from any minor version or patch to the next minor version and any patches.
 
-* Tile version upgrades result in no data or configuration loss, and maintain service functionality and availability.
+* Tile version upgrades result in no data or configuration loss, and maintain service capability and availability.
 
 * Where appropriate, <%= vars.app_runtime_full %> integrations work properly, including:
   * Registered routes

runtime-config.html.md.erb

@@ -101,7 +101,7 @@ runtime_configs:
 
 ## <a id="config-only"></a>Create a Runtime Config Tile
 
-In Ops Manager, a runtime config tile appears as a tile with minimal configuration options. Runtime config tiles contain no stemcell, network, availability zone (AZ), or resource config information. You might create a runtime config tile if you want global deployment configurations to be applied to all VMs in deployment and do not any other functionality.
+In Ops Manager, a runtime config tile appears as a tile with minimal configuration options. Runtime config tiles contain no stemcell, network, availability zone (AZ), or resource config information. You might create a runtime config tile if you want global deployment configurations to be applied to all VMs in deployment and do not any other capability.
 
 For a runtime config tile, tile authors are not required to define the following top-level properties:
 

ssi-creds-tiledev.html.md.erb

@@ -32,7 +32,7 @@ These SSI credentials are different from credentials that the tile uses internal
 
 For more information on the CredHub credential management component, see the [CredHub documentation](https://docs.cloudfoundry.org/credhub/index.html) topic.
 
-The sections below describe an example implementation of how to add SSI credentials functionality to a service tile.
+The sections below describe an example implementation of how to add SSI credentials capability to a service tile.
 
 ## <a id="step1"></a> Step 1: Edit your BOSH release
 

testing.html.md.erb

@@ -22,15 +22,15 @@ For <%= vars.platform_name %> tiles, a typical test pyramid progresses as follow
 
 1. System tests of the tile's **BOSH release**, including:
   - **Functional tests** covering the main features of the service.
-      The main features typically interact with almost all important external integration points, so these tests confirm product functionality.
+      The main features typically interact with almost all important external integration points, so these tests confirm product capability.
   - **Smoke tests** (lifecycle tests) for service instances that create and bind a service instance, call it from a test app,
       verify the logs it generates, and delete it.
       For a typical end-to-end test sequence, see [Smoke Tests](#smoke) as follows.
 
 1. System tests of **tile** operation within Ops Manager.
   - These include:
       * **Configuration checks** that test every external configurable integration point and connection to remote servers using configured credentials
-      * **Default checks** that confirm "happy path" functionality.
+      * **Default checks** that confirm "happy path" capability.
   - Use the Ops Manager API to verify that property blueprints in the tile metadata are correct
     and that they translate correctly to the BOSH manifest that Ops Manager generates.
   - Use the [om](https://github.com/pivotal-cf/om) tool to call the Ops Manager API programmatically from Go.