Copyedits, part 1

Signed-off-by: Mary Jinglewski <mjinglewski@chef.io>

14 files changed, 81 insertions, 83 deletions

diff --git a/docs/dev/README.md b/docs/dev/README.md
index fba17e7b9f..903f1253cb 100644
--- a/docs/dev/README.md
+++ b/docs/dev/README.md
@@ -1,8 +1,8 @@
 # Chef Infra Development Documentation
 
-This directory contains a collection of useful how-to guides for both new and seasoned Chef contributors. There are many guides explaining how to build, test, and contribute to Chef Infra as well as documents describing how the many subsystems function.
+This directory contains a collection of useful how-to guides for both new and seasoned Chef contributors. There are many guides explaining how to build, test, and contribute to Chef Infra, as well as documents describing how the many subsystems function.
 
-A good first start is our [How Chef Infra Is Built](how_chef_is_built.md) and [Chef Infra Release and Support Schedule](release_and_support_schedule.md)
+A good first start is our [How Chef Infra Is Built](how_chef_is_built.md) and [Chef Infra Release and Support Schedule](./policy/release_and_support_schedule.md.md)
 
 ## How-To Guides
 
@@ -13,7 +13,7 @@ A good first start is our [How Chef Infra Is Built](how_chef_is_built.md) and [C
 
 ## Design Documents
 
-- [Client Release Cadence](./design_documents/client_release_cadence.mdÂ)
+- [Client Release Cadence](./design_documents/client_release_cadence.md)
 - [Data Collection](./design_documents/data_collector.md)
 - [Action Collection](./design_documents/action_collection.md)
 - [Deprecations Within Resources](./design_documents/deprecations_in_resources.md)
diff --git a/docs/dev/design_documents/client_exit_codes.md b/docs/dev/design_documents/client_exit_codes.md
index 1fdbea2952..762ad73b3e 100644
--- a/docs/dev/design_documents/client_exit_codes.md
+++ b/docs/dev/design_documents/client_exit_codes.md
@@ -6,7 +6,7 @@ Signal outside tools of specific Chef-Client run status. Ability to determine re
 
     As a Chef user,
     I want to be able to determine when a chef-client run is rebooting the node,
-    so that Test-Kitchen/Vagrant/any outside tool can wait for node to reboot, and continue converging.
+    so that Test-Kitchen/Vagrant/any outside tool can wait for the node to reboot, and continue converging.
 
 ## Specification
 
@@ -20,7 +20,7 @@ Signal outside tools of specific Chef-Client run status. Ability to determine re
 
 ### Remaining Available Exit Codes
 
-All exit codes defined should be usable on all supported Chef Platforms.  Also the exit codes used should be identical across platforms.  That limits the total range from 1-255.  Exit codes not explicitly used by Linux/Windows are listed below.  There are 59 exit codes that are available on both platforms.
+All exit codes defined should be usable on all supported Chef Platforms. Also, the exit codes used should be identical across all platforms. That limits the total range from 1-255. Exit codes not explicitly used by Linux/Windows are listed below. There are 59 exit codes that are available on both platforms.
  * Any numbers below that have a strike-through are used below in the **Exit Codes in Use** section
  * Exit Codes Available for Chef use :
      * ~~35,37,40,41,42~~,43,44,45,46,47,48,49,79,81,90,91,92,93,94,95,96,97
@@ -31,7 +31,7 @@ All exit codes defined should be usable on all supported Chef Platforms.  Also t
 
 * Reboot exit codes should take precedence over Chef Execution State
 * Precedence within a table should be evaluated from the top down.
-    *  Example - Audit Mode Failure would only apply on a successful execution.  But if the chef-run failed for any other reason, no reason to exit with audit mode.
+    *  Example - Audit Mode Failure would only apply on a successful execution, but if the chef-run failed for any other reason, there is no reason to exit with audit mode.
 
 ## Exit Codes in Use
 
@@ -60,4 +60,4 @@ Exit Code        | Reason             | Details
 
 ## Extend
 
-If there is a need for additional exit codes pleae open a Design Proposal PR to discuss the change and then a PR to update this document.
\ No newline at end of file
+If there is a need for additional exit codes, please open a Design Proposal PR to discuss the change, and then a PR to update this document.
\ No newline at end of file
diff --git a/docs/dev/design_documents/client_release_cadence.md b/docs/dev/design_documents/client_release_cadence.md
index 40892ddf33..2954d5d21d 100644
--- a/docs/dev/design_documents/client_release_cadence.md
+++ b/docs/dev/design_documents/client_release_cadence.md
@@ -1,8 +1,8 @@
 # Chef Release Cadence
 
 Chef follows [Semantic Versioning](https://semver.org/) for releases. Major
-versions (eg. 11.x -> 12.x) will include backwards-incompatible changes, minor
-versions (eg 12.1 -> 12.2) will include new features and bug fixes but will be
+versions (eg. 11.x -> 12.x) will include backwards-incompatible changes. Minor
+versions (eg 12.1 -> 12.2) will include new features and bug fixes, but will be
 backwards-compatible to the best of our ability. Patch versions are governed
 by [RFC 47](rfc047-release-process.md).
 
@@ -26,8 +26,8 @@ Discourse and Slack in March that will summarize the changes slated for the rele
 Monthly releases help ensure we get new features and minor bug fixes out to Chef
 users in a timely fashion while not overloading the maintainer teams.
 Similarly, offsetting the Chef and ChefDK releases allows the full attention of
-the Chef development team on each of those releases and leaves time for any
+the Chef development team on each of those releases, and leaves time for any
 potential hot fixes or follow-up.
 
 Major releases in April avoids releasing during winter holidays, summer
-vacations, ChefConf and Chef Summits.
\ No newline at end of file
+vacations, ChefConf, and Chef Summits.
\ No newline at end of file
diff --git a/docs/dev/design_documents/cookbook_root_aliases.md b/docs/dev/design_documents/cookbook_root_aliases.md
index dbf0b2641d..c7be543188 100644
--- a/docs/dev/design_documents/cookbook_root_aliases.md
+++ b/docs/dev/design_documents/cookbook_root_aliases.md
@@ -2,7 +2,7 @@
 
 There are several common cases when writing Chef cookbooks that result in a
 folder containing a single file, usually called `default.rb`. Root aliases
-allow using a single file instead of a folder.
+allow for using a single file instead of a folder.
 
 ## Motivation
 
@@ -17,32 +17,33 @@ There are two common cases where a single-file-in-folder comes up:
 1. `attributes/default.rb`
 2. `recipes/default.rb`
 
-With `attributes` this is common to the point of almost complete irrelevance of
-other layouts given that all attribute files are always loaded. Recipes aren't
-exclusively singletons, but it is common enough to warrant a special case.
+With `attributes`, this single-file-in-folder case is common to the point of almost 
+complete irrelevance of other layouts, given that all attribute files are always 
+loaded. `recipes` are not exclusively a single-file-in-folder case, but it is common 
+enough to warrant a special case.
 
 With this in mind, aliases are available for each:
 
 1. `attributes.rb`
 2. `recipe.rb`
 
-It is an error for a cookbook to contain both an alias and its target or two
+It is an error for a cookbook to contain both an alias and its target, or two
 aliases for the same target.
 
 No aliases are provided for other types as they are generally a more advanced
 use case where the worry about learning curve is reduced.
 
 Aliases are equivalent to their target file for purposes of loading either via
-standard cookbook loading or methods like `include_recipe`.
+standard cookbook loading, or methods like `include_recipe`.
 
 ## Rationale
 
 This meshes well with RFC017 towards a goal of reducing the file layout
 complexity of simple cookbooks. There can be compatibility issues with tools
 that parse the cookbook manifest data and presume that all files from a given
-segment reside under the previously required folder, however the author knows
-of no such tools and given that the manifest format is mostly an internal
-representation this is not considered a blocker. Overall the goal of these RFCs
+segment reside under the previously required folder. The author knows
+of no such tools, and given that the manifest format is mostly an internal
+representation, this is not considered a blocker. Overall, the goal of these RFCs
 is to remove the frequent use of single-child folders.
 
 The choice of which aliases to provide and what to name them is mostly driven
diff --git a/docs/dev/design_documents/data_collector.md b/docs/dev/design_documents/data_collector.md
index dd0ac487db..f99dc13241 100644
--- a/docs/dev/design_documents/data_collector.md
+++ b/docs/dev/design_documents/data_collector.md
@@ -33,21 +33,21 @@ The implementation must work with Chef running in any mode:
 
 All payloads will be sent to the Data Collector server via HTTP POST to the URL specified in the `data_collector_server_url` configuration parameter. Users should be encouraged to use a TLS-protected endpoint.
 
-Optionally, payloads may also be written out to multiple HTTP endpoints or JSON files on the local filesystem (of the node running chef-client) by specifying the `data_collector_output_locations` configuration parameter.
+Optionally, payloads may also be written out to multiple HTTP endpoints or JSON files on the local filesystem (of the node running `chef-client`) by specifying the `data_collector_output_locations` configuration parameter.
 
 For the initial implementation, transmissions to the Data Collector server can optionally be authenticated with the use of a pre-shared token which will be sent in a HTTP header. Given that the receiver is not the Chef Server, existing methods of using a Chef `client` key to authenticate the request are unavailable.
 
 #### Configuration
 
-The configuration required for this new functionality can be placed in the client.rb or any other `Chef::Config`-supported location (such as a client.d or solo.d directory).
+The configuration required for this new functionality can be placed in the `client.rb` or any other `Chef::Config`-supported location (such as a client.d or solo.d directory).
 
 ##### Parameters
 
  * **data\_collector\_server\_url**: required*. The full URL to the data collector server API. All messages will be POST'd to this URL. The Data Collector class will be registered and enabled if this config parameter is specified. * If the `data_collector_output_locations` configuration parameter is specified, this setting may be omitted.
  * **data\_collector\_token**: optional. A pre-shared token that, if present, will be passed as an HTTP header named `x-data-collector-token` to the Data Collector server. The server can choose to accept or reject the data posted based on the token or lack thereof.
  * **data\_collector\_mode**: The Chef mode in which the Data Collector will be enabled. For example, you may wish to only enable the Data Collector when running in Chef Solo Mode. Must be one of: `:solo`, `:client`, or `:both`. The `:solo` value is used for Chef operating in Chef Solo Mode or Chef Solo Legacy Mode. Default: `:both`.
- * **data\_collector\_raise\_on\_failure**: If true, the Chef run will fatally exit if it is unable to successfully POST to the Data Collector server. Default: `false`
- * **data\_collector\_output\_locations**: optional. An array of URLs and/or file paths to which data collection payloads will also be written. This may be used without specifying the `data_collector_server_url` configuration parameter
+ * **data\_collector\_raise\_on\_failure**: If true, the Chef run will fatally exit if it is unable to successfully POST to the Data Collector server. Default: `false`.
+ * **data\_collector\_output\_locations**: optional. An array of URLs and/or file paths to which data collection payloads will also be written. This may be used without specifying the `data_collector_server_url` configuration parameter.
 
 ### Schemas
 
@@ -258,7 +258,7 @@ The Run Start Schema will be used by Chef to notify the data collection server a
 
 ##### Run End Schema
 
-The Run End Schema will be used by Chef Client to notify the data collection server at the completion of the Chef Client's converge phase and report data on the Chef Client run, including resources changed and any errors encountered.
+The Run End Schema will be used by Chef Client to notify the data collection server at the completion of the Chef Client's converge phase, and to report data on the Chef Client run, including resources changed and any errors encountered.
 
 ```json
 {
@@ -462,12 +462,13 @@ The Run End Schema will be used by Chef Client to notify the data collection ser
 
 ## Technical Implementation
 
-The remainder of document will focus entirely on the nuts and bolts of the Data Collector
+The remainder of document will focus entirely on the nuts and bolts of the Data Collector.
 
 ### Action Collection Integration
 
-Most of the work is done by a separate Action Collection to track the actions of Chef resources.  If the Data Collector is not enabled, it never registers with the
-Action Collection and no work will be done by the Action Collection to track resources.
+Most of the work is done by a separate Action Collection to track the actions of Chef resources.
+If the Data Collector is not enabled, it never registers with the Action Collection and 
+no work will be done by the Action Collection to track resources.
 
 ### Additional Collected Information
 
@@ -478,15 +479,13 @@ The Data Collector also collects:
 - the node
 - formatted error output for exceptions
 
-Most of this is done through hooking events directly in the Data Collector itself.  The ErrorHandlers module is broken out into a module which is directly mixed into
-the Data Collector to separate that concern out into a different file (it is straightforward with fairly little state, but is just a lot of hooked methods).
+Most of this is done through hooking events directly in the Data Collector itself. The ErrorHandlers module is broken out into a module, which is directly mixed into the Data Collector to separate that concern out into a different file. This ErrorHandlers module is straightforward with fairly little state, but involves just a lot of hooked methods.
 
 ### Basic Configuration Modes
 
 #### Configured for Automate
 
-Do nothing.  The URL is constructed from the base `Chef::Config[:chef_server_url]`, auth is just Chef Server API authentication, and the default behavior is that it
-is configured.
+Do nothing. The URL is constructed from the base `Chef::Config[:chef_server_url]`, `auth` is just Chef Server API authentication, and the default behavior is that it is configured.
 
 #### Configured to Log to a File
 
@@ -507,10 +506,10 @@ Chef::Config[:data_collector][:server_url] = "https://chef.acme.local/myendpoint
 Chef::Config[:data_collector][:token] = "mytoken"
 ```
 
-This works for chef-clients which are configured to hit a chef server, but use a custom non-Chef-Automate endpoint for reporting, or for chef-solo/zero users.
+This works for chef-clients, which are configured to hit a Chef server, but use a custom non-Chef-Automate endpoint for reporting, or for chef-solo/zero users.
 
-XXX: There is also the `Chef::Config[:data_collector][:output_locations] = { uri: [ "https://chef.acme.local/myendpoint.html" ] }` method -- which is going to behave
-differently, particularly on non-chef-solo use cases.  In that case the Data Collector `server_url` will still be automatically derived from the `chef_server_url` and
+XXX: There is also the `Chef::Config[:data_collector][:output_locations] = { uri: [ "https://chef.acme.local/myendpoint.html" ] }` method -- which will behave
+differently, particularly on non-chef-solo use cases.  In that case, the Data Collector `server_url` will still be automatically derived from the `chef_server_url` and
 the Data Collector will attempt to contact that endpoint, but with the token being supplied it will use that and will not use Chef Server authentication, and the
 server should 403 back, and if `raise_on_failure` is left to the default of false then it will simply drop that failure and continue without raising, which will
 appear to work, and output will be send to the configured `output_locations`.  Note that the presence of a token flips all external URIs to using the token so that
@@ -520,8 +519,8 @@ using any `url` options in the `output_locations` since that feature is fairly p
 
 ### Resiliency to Failures
 
-The Data Collector in Chef >= 15.0 is resilient to failures that occur anywhere in the main loop of the `Chef::Client#run` method.  In order to do this there is a lot
-of defensive coding around internal data structures that may be nil (e.g. failures before the node is loaded will result in the node being nil).  The spec tests for
+The Data Collector in Chef >= 15.0 is resilient to failures that occur anywhere in the main loop of the `Chef::Client#run` method. In order to do this there is a lot
+of defensive coding around internal data structures that may be `nil`. (e.g. failures before the node is loaded will result in the node being nil). The spec tests for
 the Data Collector now run through a large sequence of events (which must, unfortunately, be manually kept in sync with the events in the Chef::Client if those events
 are ever 'moved' around) which should catch any issues in the Data Collector with early failures.  The specs should also serve as documentation for what the messages
 will look like under different failure conditions.  The goal was to keep the format of the messages to look as near as possible to the same schema as possible even
@@ -532,7 +531,7 @@ have sent a start message.
 
 ### Decision to Be Enabled
 
-This is complicated due to over-design and is encapsulated in the `#should_be_enabled?` method and the ConfigValidation module.  The `#should_be_enabled?` message and
+This is complicated due to over-design and is encapsulated in the `#should_be_enabled?` method and the ConfigValidation module. The `#should_be_enabled?` message and
 ConfigValidation should probably be merged into one renamed Config module to isolate the concern of processing the Chef::Config options and doing the correct thing.
 
 ### Run Start and Run End Message modules
diff --git a/docs/dev/design_documents/deprecations_in_resources.md b/docs/dev/design_documents/deprecations_in_resources.md
index 0ae145712f..f9cdabb2e2 100644
--- a/docs/dev/design_documents/deprecations_in_resources.md
+++ b/docs/dev/design_documents/deprecations_in_resources.md
@@ -1,8 +1,8 @@
 # Deprecation Warnings Within Custom Resources
 
-In Chef 12, we introduced deprecation warnings within the chef-client. This allowed us to communicate future breaking changes to users. The warnings and integration within Test Kitchen have become a powerful tool allowing users to future proof their cookbooks and ease chef-client migration projects.
+In Chef 12, we introduced deprecation warnings within the chef-client. This allowed us to communicate future breaking changes to users. The warnings and integration within Test Kitchen have become a powerful tool, allowing users to future-proof their cookbooks and ease chef-client migration projects.
 
-This design extends the deprecation functionality to custom resources allowing authors to warn consumers of future breaking changes to their resources.
+This design extends the deprecation functionality to custom resources, allowing authors to warn consumers of future breaking changes to their resources.
 
 ## Motivation
 
@@ -26,7 +26,7 @@ This design extends the deprecation functionality to custom resources allowing a
 
 ### deprecated method for resources
 
-This new method will let authors communicate to consumers that a resource is going away in the future. Right now we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string which becomes the warning message.
+This new method will let authors communicate to consumers that a resource is going away in the future. Right now, we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string, which becomes the warning message.
 
 #### Example
 
@@ -38,7 +38,7 @@ deprecated 'This resource will be removed in the 3.0 release of the example cook
 
 ### deprecated method for properties
 
-This new option for properties will let authors communicate to consumers that an individual property is going away in the future. Right now we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string which becomes the warning message.
+This new option for properties will let authors communicate to consumers that an individual property is going away in the future. Right now, we rely on readme or changelog entries, which are not a very effective way to communicate to consumers. This method will accept a string, which becomes the warning message.
 
 #### Example
 
@@ -53,11 +53,11 @@ property :destroy_everything,
 
 ### deprecated_property_alias
 
-Currently if a resource author decides to change the name of a property they have two options:
-	- Use alias_method which silently routes old properties to the new names
-	- Define both properties in the resource and include functionality to set the new value using the old value while warning the user.
+Currently if a resource author decides to change the name of a property, they have two options:
+    - Use `alias_method`, which silently routes old properties to the new names, or
+    - Define both properties in the resource, and include functionality to set the new value while using the old value and warning the user.
 
-`alias_method` doesn't alert cookbook consumers to the change and writing your own code to perform deprecation warnings is cumbersome and rarely done. A new deprecated_property_alias would behave similar to a `alias_method`, but throw deprecation warnings while providing backwards compatibility. It would accept and optional String value that would be used in place of a generic deprecation message.
+`alias_method` doesn't alert cookbook consumers to the change, and writing your own code to perform deprecation warnings is cumbersome and rarely done. A new `deprecated_property_alias` would behave similar to a `alias_method`, but throw deprecation warnings while providing backwards compatibility. It would accept and optional `String` value that would be used in place of a generic deprecation message.
 
 #### Example
 
diff --git a/docs/dev/design_documents/event_handler_recipe_dsl.md b/docs/dev/design_documents/event_handler_recipe_dsl.md
index c8d0d94c1b..ec6adbc165 100644
--- a/docs/dev/design_documents/event_handler_recipe_dsl.md
+++ b/docs/dev/design_documents/event_handler_recipe_dsl.md
@@ -4,28 +4,28 @@ Allow cookbook authors to easily add custom logic on Chef events.
 
 ## Motivation
 
-Chef has an extensive event [dispatch mechanism](https://github.com/chef/chef/blob/master/lib/chef/event_dispatch/base.rb).
-But incorporating some custom logic against any of the events is an onerous process which involves
+Chef has an extensive [event dispatch mechanism](https://github.com/chef/chef/blob/master/lib/chef/event_dispatch/base.rb).
+But incorporating some custom logic against any of the events is an onerous process, which involves
 subclassing the based event handler and adding it via the config. This RFC
-proposes a recipe DSL method to ease this. For new chef users this will reduce
+proposes a recipe DSL method to ease this. For new Chef users, this will reduce
 the entry barrier.
 
 ## Specification
 
-Currently chef client sets up couple of default handlers (doc, base) during
-initialization. An additional empty event handler (a subclass
-of the base handler without any custom logic) can be added alongside the
-existing handlers which will used as a placeholder for user specific hooks.
+Currently, `chef-client` sets up couple of default handlers -- e.g. doc, base -- during
+initialization. An additional empty event handler -- a subclass
+of the base handler without any custom logic -- can be added alongside the
+existing handlers, which will used as a placeholder for user-specific hooks.
 
 A top level (::Chef) method will be introduced (`event_handler`) to wrap the
 main event handler DSL (`on`). Users can tap into one of the event types
-(as specified in base dispatcher) using this DSL to execute their custom logic.
+-- as specified in base dispatcher -- using this DSL to execute their custom logic.
 
 The additional top level method(`Chef.event_handler`) will allow the handler
-DSL usage in and outside of recipes and also ease writing backward compatible
+DSL usage in and outside of recipes, and also ease writing backward-compatible
 changes for the `on` method if need be.
 
-Following is an example of sending hipchat notification on chef run failure.
+The following is an example of sending hipchat notification on chef run failure.
 
 ```ruby
 Chef.event_handler do
@@ -35,8 +35,8 @@ Chef.event_handler do
 end
 ```
 
-Following is another example of taking a distributed lock via etcd, to 
-prevent concurrent chef runs in different nodes
+The following is another example of taking a distributed lock via `etcd`, to 
+prevent concurrent chef runs in different nodes.
 
 ```ruby
 lock_key = "#{node.chef_environment}/#{node.name}"
@@ -54,7 +54,7 @@ Chef.event_handler do
 end
 ```
 
-Following is another example of sending a hipchat alert on a key config change
+The following is another example of sending a hipchat alert on a key config change.
 
 ```ruby
 Chef.event_handler do
diff --git a/docs/dev/design_documents/gem_installation_via_metadata.md b/docs/dev/design_documents/gem_installation_via_metadata.md
index 6263ab903d..4409bb4c69 100644
--- a/docs/dev/design_documents/gem_installation_via_metadata.md
+++ b/docs/dev/design_documents/gem_installation_via_metadata.md
@@ -1,14 +1,14 @@
 # Enable gem dependencies in cookbook metadata
 
 Support a 'gem' DSL method for cookbook metadata to create a dependency on a rubygem.  The
-gem will be installed via `chef_gem` after all the cookbooks are synchronized but before any
+gem will be installed via `chef_gem` after all the cookbooks are synchronized, but before any
 other cookbook loading is done.
 
 ## Motivation
 
     As a Chef User,
     I want to be able to use additional gems in libraries, attributes and resources,
-    to avoid complex workarounds and double-run converges.
+    and to avoid complex workarounds and double-run converges.
 
 ## Specification
 
@@ -20,12 +20,11 @@ gem "chef-sugar"
 gem "chef-provisioning"
 ```
 
-In the `Chef::RunContext::CookbookCompiler#compile` method a phase will be added before `compile_libraries` which will install all of the gem declarations from all of the synchronized cookbooks before any other cookbook code is compiled.
+In the `Chef::RunContext::CookbookCompiler#compile` method, a phase will be added before `compile_libraries`. This phase will install all of the gem declarations from all of the synchronized cookbooks before any other cookbook code is compiled.
 
 The implementation will use an in-memory bundler Gemfile which is constructed against all gem statements in all cookbooks which are in the `run_list`, solved
-at the same time.  The syntax of the 'gem' statement will support the bundler gem syntax, with the qualification that since it is compiled into metadata.json
-that arbitrary ruby code will be expanded at cookbook upload time.
+at the same time.  The syntax of the 'gem' statement will support the bundler gem syntax, with the qualification of since the syntax is compiled into metadata.json, that arbitrary ruby code will be expanded at cookbook upload time.
 
-The resulting gemset bundle will be installed into the LIBPATH of the running chef-client.  This may either be directly into the base ruby libraries (per current `chef_gem` behavior) or into a custom location with the LIBPATH of the chef-client extended to use that location--as an open implementation question.
+The resulting gemset bundle will be installed into the LIBPATH of the running chef-client.  This may either be directly into the base ruby libraries (per current `chef_gem` behavior), or into a custom location with the LIBPATH of the chef-client extended to use that location--as an open implementation question.
 
 The normal Gemfile `requires` tag may be used by users to autoload files out of gems.
diff --git a/docs/dev/design_documents/resource-property-validation-messaging.md b/docs/dev/design_documents/resource_property_validation_messaging.md
index 36a1ac92cb..36a1ac92cb 100644
--- a/docs/dev/design_documents/resource-property-validation-messaging.md
+++ b/docs/dev/design_documents/resource_property_validation_messaging.md
diff --git a/docs/dev/how_to/branching_and_backporting.md b/docs/dev/how_to/branching_and_backporting.md
index 02024c9bf8..b2b90edb50 100644
--- a/docs/dev/how_to/branching_and_backporting.md
+++ b/docs/dev/how_to/branching_and_backporting.md
@@ -2,20 +2,20 @@
 
 ## Branch Structure
 
-We develop and ship the current release of Chef off the master branch of this repository. Our goal is that master should always be in a shipable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-14 or chef-13). We do not perform direct development on these stable branches except to resolve build failures. Instead we backport fixes from our master branch to these stable branches. Stable branches receive critical bugfixes and security releases and stable Chef releases are made as necessary for security purposes.
+We develop and ship the current release of Chef off the master branch of this repository. Our goal is that `master` should always be in a shipable state. Previous stable releases of Chef are developed on their own branches named by the major version (ex: chef-14 or chef-13). We do not perform direct development on these stable branches, except to resolve build failures. Instead, we backport fixes from our master branch to these stable branches. Stable branches receive critical bugfixes and security releases, and stable Chef releases are made as necessary for security purposes.
 
 ## Backporting Fixes to Stable Releases
 
-If there is a critical fix you believe should be backported from master to a stable branch please follow these steps to backport your change:
+If there is a critical fix that you believe should be backported from master to a stable branch, please follow these steps to backport your change:
 
 1. Ask in the #chef-dev channel on [Chef Community Slack](https://community-slack.chef.io/) if this is an appropriate change to backport.
 3. Inspect the Git history and find the `SHA`(s) associated with the fix.
 4. Backport the fix to a branch via cherry-pick:
-  1. Check out the stable release branch: `git checkout chef-14`
-  1. Create a branch for your backport: `git checkout -b my_great_bug_packport`
-  2. Cherry Pick the SHA with the fix: `git cherry-pick SHA`
-  3. Address any conflicts (if necessary)
-  5. Push the new branch to your origin: `git push origin`
+    1. Check out the stable release branch: `git checkout chef-14`
+    2. Create a branch for your backport: `git checkout -b my_great_bug_packport`
+    3. Cherry Pick the SHA with the fix: `git cherry-pick SHA`
+    4. Address any conflicts (if necessary)
+    5. Push the new branch to your origin: `git push origin`
 5. Open a PR for your backport
-  1. The PR title should be `Backport: ORIGINAL_PR_TEXT`
-  2. The description should link to the original PR and include a description of why it needs to be backported
\ No newline at end of file
+    1. The PR title should be `Backport: ORIGINAL_PR_TEXT`
+    2. The description should link to the original PR and include a description of why it needs to be backported
\ No newline at end of file
diff --git a/docs/dev/how_to/building_and_installing.md b/docs/dev/how_to/building_and_installing.md
index 70510fddea..e613de459a 100644
--- a/docs/dev/how_to/building_and_installing.md
+++ b/docs/dev/how_to/building_and_installing.md
@@ -4,9 +4,9 @@ Chef Infra can be built and installed in two distinct ways:
 	- A gem built from this repository and installed into your own Ruby installation
 	- A system native package containing its own Ruby built using our Omnibus packaging system
 
-**NOTE:** As an end user, please download the [Chef Infra package](https://downloads.chef.io/chef) for managing systems or [Chef Workstation package](https://downloads.chef.io/chef-workstation) for authoring Chef cookbooks and administering your Chef infrastructure.
+**NOTE:** As an end user, please download the [Chef Infra package](https://downloads.chef.io/chef) for managing systems, or the [Chef Workstation package](https://downloads.chef.io/chef-workstation) for authoring Chef cookbooks and administering your Chef infrastructure.
 
-We do not recommend end users install Chef from gems or build from source. The following instructions apply only to those developing the Chef Infra client.
+We do not recommend for end users to install Chef from gems or build from source. The following instructions apply only to those developing the Chef Infra client.
 
 ## Building the Gem
 
@@ -21,7 +21,7 @@ We do not recommend end users install Chef from gems or build from source. The f
 
 ### Building / Installing
 
-Once you have your development environment configured you can clone the Chef repository and install Chef:
+Once you have your development environment configured, you can clone the Chef repository and install Chef:
 
 ```bash
 git clone https://github.com/chef/chef.git
diff --git a/docs/dev/how_to/bumping_minor_or_major_versions.md b/docs/dev/how_to/bumping_minor_or_major_versions.md
index 36b475aa58..ebcf4e4695 100644
--- a/docs/dev/how_to/bumping_minor_or_major_versions.md
+++ b/docs/dev/how_to/bumping_minor_or_major_versions.md
@@ -3,13 +3,13 @@
 ## When to Bump Versions
 
 
-After performing the monthly minor release of Chef we should wait several days, and then bumpp the version for the next month's release. Why wait? Well we don't want to bump the version until we're sure we don't need to perform an emergency release for a regression. Once we're fairly confident we won't be performing a regression release we want all new builds for the current channel to have the next month's version. This makes it very clear what version of Chef users are testing within the current channel.
+After performing the monthly minor release of Chef, we should wait several days, and then bump the version for the next month's release. Why wait? We don't want to bump the version until we are sure we do not need to perform an emergency release for a regression. Once we're fairly confident we won't be performing a regression release, we want all new builds for the current channel to have the next month's version. This makes it very clear what version of Chef users are testing within the current channel.
 
-Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs all development on master will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
+Bumping for the yearly major release is a bit different. We can bump for the new major release once we create a stable branch for the current major version number. Once this branch and version bump occurs, all development on master will be for the upcoming major release, and anything going into the stable release will need to be backported. See [Branching and Backporting](branching_and_backporting.md) for more information on how we branch and backport to stable.
 
 ### How to Bump
 
-Chef's Expeditor tool includes functionality to bump the minor or major version of the product. By using Expeditor to bump versions we can perform a bump without directly editing the version files. A version bump is performed when a PR is merged with either of these two labels applied:
+Chef's Expeditor tool includes functionality to bump the minor or major version of the product. By using Expeditor to bump versions, we can perform a bump without directly editing the version files. A version bump is performed when a PR is merged with either of these two labels applied:
  - Expeditor: Bump Version Minor
  - Expeditor: Bump Version Major
 
diff --git a/docs/dev/how_to/updating_dependencies.md b/docs/dev/how_to/updating_dependencies.md
index f57cc76708..035f43bbc0 100644
--- a/docs/dev/how_to/updating_dependencies.md
+++ b/docs/dev/how_to/updating_dependencies.md
@@ -6,12 +6,11 @@ If you want to change our constraints (change which packages and versions we acc
 * [omnibus_overrides.rb](omnibus_overrides_rb):  Pinned versions of omnibus packages.
 * [omnibus/Gemfile](omnibus/Gemfile) and [omnibus/Gemfile.lock](omnibus/Gemfile.lock):  Gems for the omnibus build system itself.
 
-In addition there are several places versions are pinned for CI tasks:
+In addition, there are several places where versions are pinned for CI tasks:
 
 * [kitchen-tests/Gemfile](kitchen-tests/Gemfile) and [kitchen-tests/Gemfile.lock](kitchen-tests/Gemfile.lock): Gems for test-kitchen tests (travis)
 
-In order to update everything run `rake dependencies`.  Note that the [Gemfile.lock](Gemfile.lock) pins windows platforms and to fully regenerate the lockfile
-you must use the following commands or run `rake dependencies:update_gemfile_lock`:
+In order to update everything, run `rake dependencies`.  Note that the [Gemfile.lock](Gemfile.lock) pins windows platforms, and to fully regenerate the lockfile, you must use the following commands, or run `rake dependencies:update_gemfile_lock`:
 
 ```bash
 bundle lock --update --add-platform ruby
diff --git a/docs/dev/policy/release_and_support_schedule.md.md b/docs/dev/policy/release_and_support_schedule.md
index 9feb9c0f1d..9feb9c0f1d 100644
--- a/docs/dev/policy/release_and_support_schedule.md.md
+++ b/docs/dev/policy/release_and_support_schedule.md