Edit AWX docs

1 files changed, 19 insertions, 19 deletions

diff --git a/docs/tower_configuration.md b/docs/tower_configuration.md
index a5044c8df0..91beca5085 100644
--- a/docs/tower_configuration.md
+++ b/docs/tower_configuration.md
@@ -1,11 +1,11 @@
-Tower configuration gives tower users the ability to adjust multiple runtime parameters of Tower, thus take fine-grained control over Tower run.
+Tower configuration gives Tower users the ability to adjust multiple runtime parameters of Tower, which enables much more fine-grained control over Tower runs.
 
 ## Usage manual
 
-#### To use
-The REST endpoint for CRUD operations against Tower configurations is `/api/<version #>/settings/`. GETing to that endpoint will return a list of available Tower configuration categories and their urls, such as `"system": "/api/<version #>/settings/system/"`. The URL given to each category is the endpoint for CRUD operations against individual settings under that category.
+#### To Use:
+The REST endpoint for CRUD operations against Tower configurations can be found at `/api/<version #>/settings/`. GETing to that endpoint will return a list of available Tower configuration categories and their URLs, such as `"system": "/api/<version #>/settings/system/"`. The URL given to each category is the endpoint for CRUD operations against individual settings under that category.
 
-Here is a typical Tower configuration category GET response.
+Here is a typical Tower configuration category GET response:
 ```
 GET /api/v2/settings/github-team/
 HTTP 200 OK
@@ -27,10 +27,10 @@ X-API-Time: 0.026s
 }
 ```
 
-The returned body is a JSON of key-value pairs, where the key is the name of Tower configuration setting, and the value is the value of that setting. To update the settings, simply update setting values and PUT/PATCH to the same endpoint.
+The returned body is a JSON of key-value pairs, where the key is the name of the Tower configuration setting, and the value is the value of that setting. To update the settings, simply update setting values and PUT/PATCH to the same endpoint.
 
-#### To develop
-Each Django app in tower should have a `conf.py` file where related settings get registered. Below is the general format for `conf.py`:
+#### To Develop:
+Each Django app in Tower should have a `conf.py` file where related settings get registered. Below is the general format for `conf.py`:
 
 ```python
 # Other dependencies
@@ -52,7 +52,7 @@ register(
 # Other setting registries
 ```
 
-`register` is the endpoint API for registering individual tower configurations:
+`register` is the endpoint API for registering individual Tower configurations:
 ```
 register(
     setting,
@@ -66,34 +66,34 @@ register(
     defined_in_file=False,
 )
 ```
-Here is the details of each argument:
+Here are the details for each argument:
 
 | Argument Name               | Argument Value Type                                                  | Description                                                                                                                                                                   |
 |--------------------------|-------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `setting`                | `str`                                                             | Name of the setting. Usually all-capital connected by underscores like `'FOO_BAR'`                                                                                            |
 | `field_class`            | a subclass of DRF serializer field available in `awx.conf.fields` | The class wrapping around value of the configuration, responsible for retrieving, setting, validating and storing configuration values.                                       |
-| `**field_related_kwargs` | **kwargs                                                          | Key-worded arguments needed to initialize an instance of `field_class`.                                                                                                       |
+| `**field_related_kwargs` | `**kwargs`                                                          | Key-worded arguments needed to initialize an instance of `field_class`.                                                                                                       |
 | `category_slug`          | `str`                                                             | The actual identifier used for finding individual setting categories.                                                                                                         |
 | `category`               | transformable string, like `_('foobar')`                          | The human-readable form of `category_slug`, mainly for display.                                                                                                               |
-| `depends_on`             | `list` of `str`s                                                  | A list of setting names this setting depends on. A setting this setting depends on is another tower configuration setting whose changes may affect the value of this setting. |
-| `placeholder`            | transformable string, like `_('foobar')`                          | A human-readable string displaying a typical value for the setting, mainly used by UI                                                                                         |
-| `encrypted`              | `boolean`                                                         | Flag determining whether the setting value should be encrypted                                                                                                                |
-| `defined_in_file`        | `boolean`                                                         | Flag determining whether a value has been manually set in settings file.                                                                                                      |
+| `depends_on`             | `list` of `str`s                                                  | A list of setting names this setting depends on. A setting this setting depends on is another Tower configuration setting whose changes may affect the value of this setting. |
+| `placeholder`            | transformable string, like `_('foobar')`                          | A human-readable string displaying a typical value for the setting, mainly used by the UI.                                                                                         |
+| `encrypted`              | `boolean`                                                         | A flag which determines whether the setting value should be encrypted.                                                                                                                |
+| `defined_in_file`        | `boolean`                                                         | A flag which determines whether a value has been manually set in the settings file.                                                                                                      |
 
-During Tower bootstrapping, All settings registered in `conf.py` modules of Tower Django apps will be loaded (registered). The set of Tower configuration settings will form a new top-level of `django.conf.settings` object. Later all Tower configuration settings will be available as attributes of it, just like normal Django settings. Note Tower configuration settings take higher priority over normal settings, meaning if a setting `FOOBAR` is both defined in a settings file and registered in a `conf.py`, the registered attribute will be used over the defined attribute every time.
+During Tower bootstrapping, **all** settings registered in `conf.py` modules of Tower Django apps will be loaded (registered). This set of Tower configuration settings will form a new top-level of the `django.conf.settings` object. Later, all Tower configuration settings will be available as attributes of it, just like the normal Django settings. Note that Tower configuration settings take higher priority over normal settings, meaning if a setting `FOOBAR` is both defined in a settings file *and* registered in `conf.py`, the registered attribute will be used over the defined attribute every time.
 
-Note when registering new configurations, it is desired to provide a default value if it is possible to do so, as Tower configuration UI has a 'revert all' functionality that revert all settings to it's default value.
+Please note that when registering new configurations, it is recommended to provide a default value if it is possible to do so, as the Tower configuration UI has a 'revert all' functionality that reverts all settings to its default value.
 
-Starting from 3.2, Tower configuration supports category-specific validation functions. They should also be defined under `conf.py` in the form
+Starting with version 3.2, Tower configuration supports category-specific validation functions. They should also be defined under `conf.py` in the form
 ```python
 def custom_validate(serializer, attrs):
     '''
     Method details
     '''
 ```
-Where argument `serializer` refers to the underlying `SettingSingletonSerializer` object, and `attrs` refers to a dictionary of input items.
+...where the argument `serializer` refers to the underlying `SettingSingletonSerializer` object, and `attrs` refers to a dictionary of input items.
 
-Then at the end of `conf.py`, register defined custom validation methods to different configuration categories (`category_slug`) using `awx.conf.register_validate`:
+At the end of `conf.py`, register defined custom validation methods to different configuration categories (`category_slug`) using `awx.conf.register_validate`:
 ```python
 # conf.py
 ...