More things clear of spellcheck violations.

Signed-off-by: Pete Higgins <pete@peterhiggins.org>

8 files changed, 14 insertions, 14 deletions

diff --git a/docs/dev/design_documents/action_collection.md b/docs/dev/design_documents/action_collection.md
index a0735f65fb..df7dd46a84 100644
--- a/docs/dev/design_documents/action_collection.md
+++ b/docs/dev/design_documents/action_collection.md
@@ -53,7 +53,7 @@ it is created, so registration may be accomplished easily:
 If one of the prior methods is not used to register for the Action Collection, then the Action Collection will disable itself and will not compile
 the Action Collection in order to not waste the memory overhead of tracking the actions during the run.  The Data Collector takes advantage of this
 since if the run start message from the Data Collector is refused by the server, then the Data Collector disables itself, and then does not register
-with the Action Collection, which would disable the Action Collection.  This makes use of the delayed hooking through the `action_collection_regsitration`
+with the Action Collection, which would disable the Action Collection.  This makes use of the delayed hooking through the `action_collection_registration`
 so that the Data Collector never registers itself after it is disabled.
 
 ## Searching
diff --git a/docs/dev/design_documents/bootstrap_with_train.md b/docs/dev/design_documents/bootstrap_with_train.md
index be4fdeb3ec..3a83568d21 100644
--- a/docs/dev/design_documents/bootstrap_with_train.md
+++ b/docs/dev/design_documents/bootstrap_with_train.md
@@ -8,7 +8,7 @@ Update `knife bootstrap` to use `train` as its backend via `chef-core`, and inte
     I want to be able to bootstrap a system without logging secure data on that system
     so that chef-client's keys are not exposed to anyone who can read the logs.
 
-    As a Chef User who adminsters Windows nodes,
+    As a Chef User who administers Windows nodes,
     I want to be able to bootstrap a system using the core Chef package
     so that I don't have extra things to download first.
 
@@ -51,7 +51,7 @@ remains largely unchanged.
 
 We will also remove the following obsolete or unsupported behaviors:
 
-* `--prelease` flag - Chef hasn't been pre-released in quite some time.
+* `--prerelease` flag - Chef hasn't been pre-released in quite some time.
 * `--install-as-service` - For many years we have suggested users not run chef-client as a service due to memory leaks in long running Ruby processes.
 * `--kerberos-keytab-file` - this is not implemented in the WinRM gem we use, and so was
 passed through to no effect.
@@ -126,7 +126,7 @@ Tests must ensure that options resolve correctly from the CLI, knife configurati
 
 #### Validation
 
-Existing windows bootstrap validation checks should be preserved, unless they are superceded by related
+Existing windows bootstrap validation checks should be preserved, unless they are superseded by related
 validations for ssh bootstrap.
 
 #### Context
diff --git a/docs/dev/design_documents/data_collector.md b/docs/dev/design_documents/data_collector.md
index cb2b0cb406..889306e026 100644
--- a/docs/dev/design_documents/data_collector.md
+++ b/docs/dev/design_documents/data_collector.md
@@ -190,7 +190,7 @@ The Run Start Schema will be used by Chef to notify the data collection server a
   "description": "Data Collector - Runs run_start schema",
   "properties": {
     "chef_server_fqdn": {
-      "description": "It is the FQDN of the chef_server against whch current reporting instance runs",
+      "description": "It is the FQDN of the chef_server against which current reporting instance runs",
       "type": "string"
     },
     "entity_uuid": {
@@ -266,7 +266,7 @@ The Run End Schema will be used by Chef Client to notify the data collection ser
     "description": "Data Collector - Runs run_converge schema",
     "properties": {
         "chef_server_fqdn": {
-            "description": "It is the FQDN of the chef_server against whch current reporting instance runs",
+            "description": "It is the FQDN of the chef_server against which current reporting instance runs",
             "type": "string"
         },
         "end_time": {
diff --git a/docs/dev/design_documents/resource_file_content_verification.md b/docs/dev/design_documents/resource_file_content_verification.md
index 0ddcfeb439..f813e57c72 100644
--- a/docs/dev/design_documents/resource_file_content_verification.md
+++ b/docs/dev/design_documents/resource_file_content_verification.md
@@ -20,7 +20,7 @@ disk as appropriate. If the command's return code indicates failure,
 the provider will raise an error.
 
 The path to the temporary file with the proposed content will be
-available by using Ruby's sprinf formatting:
+available by using Ruby's sprintf formatting:
 
    "%{path}"
 
diff --git a/docs/dev/design_documents/resource_guard_interpreters.md b/docs/dev/design_documents/resource_guard_interpreters.md
index 7f4c2fb9b6..37db4e761a 100755
--- a/docs/dev/design_documents/resource_guard_interpreters.md
+++ b/docs/dev/design_documents/resource_guard_interpreters.md
@@ -208,7 +208,7 @@ do
 # architecture attribute for the parent resource which powershell_script
 # guard interpreter resources will inherit from the enclosing resource
 powershell_script "set i386 execution policy" do
-  guard_interpteter :powershell_script
+  guard_interpreter :powershell_script
   architecture :i386
   code "set-executionpolicy remotesigned"
   not_if "(get-executionpolicy -scope localmachine) -eq 'remotesigned'"
@@ -439,7 +439,7 @@ CP/M heritage even in 2014, and as Windows admins turned to PowerShell or were
 nudged toward it (often by Microsoft itself), it was asking a lot for Chef users to know
 how to use legacy `cmd.exe` to accomplish tasks. Most likely, users of `powershell_script`
 would choose to run powershell.exe in the `not_if` and `only_if` blocks. Since
-that was the common case for `powersell_script` users, the guards should have
+that was the common case for `powershell_script` users, the guards should have
 had some way to allow that, or to
 provide guard execution via PowerShell in a more natural fashion.
 
diff --git a/docs/dev/how_to/branching_and_backporting.md b/docs/dev/how_to/branching_and_backporting.md
index b2b90edb50..8929c926e9 100644
--- a/docs/dev/how_to/branching_and_backporting.md
+++ b/docs/dev/how_to/branching_and_backporting.md
@@ -2,7 +2,7 @@
 
 ## 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 shippable 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
 
@@ -12,10 +12,10 @@ If there is a critical fix that you believe should be backported from master to
 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`
-    2. Create a branch for your backport: `git checkout -b my_great_bug_packport`
+    2. Create a branch for your backport: `git checkout -b my_great_bug_backport`
     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
+    2. The description should link to the original PR and include a description of why it needs to be backported
diff --git a/docs/dev/how_to/bumping_the_major_version.md b/docs/dev/how_to/bumping_the_major_version.md
index f9db9e525e..17332bf765 100644
--- a/docs/dev/how_to/bumping_the_major_version.md
+++ b/docs/dev/how_to/bumping_the_major_version.md
@@ -31,7 +31,7 @@ On your local machine fork the current master branch to a new stable branch. For
 
 Once you’ve forked to a new stable branch such as `chef-15` you’ll want to create a new branch so you can build a PR, which will get this branch ready for release:
 
-- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constrant for master to match the new major version, and remove all the update_dep.sh subscriptions which don’t work against stable branches.
+- In ./expeditor/config.yml add the version_constraint for the new branch, update the version_constraint for master to match the new major version, and remove all the update_dep.sh subscriptions which don’t work against stable branches.
 - In readme.md update the buildkite badge to point to the new stable branch image and link instead of pointing to master.
 - In kitchen-tests/Gemfile update the Ohai branch to point to the new Ohai stable
 - In kitchen-tests/kitchen.yml update chef_version to be your new stable version and not current. Ex: 15
diff --git a/docs/dev/policy/release_and_support_schedule.md b/docs/dev/policy/release_and_support_schedule.md
index 9feb9c0f1d..2f2c378448 100644
--- a/docs/dev/policy/release_and_support_schedule.md
+++ b/docs/dev/policy/release_and_support_schedule.md
@@ -22,7 +22,7 @@ When incrementing a version, the following conditions will apply:
 
 ### Auto-bumping PATCH versions
 
-Chef projects are managed by our Expeditor release tooling application. This application is executed each time a GitHubb Pull Request is merged and incrementwss the patch version of the software before running the change through our internal CI/CD pipeline. As not all builds will make it successfully through the CI/CD pipeline, the versions available for public consumption might have gaps (e.g. 1.2.1, 1.2.10, 1.2.11, 1.2.12, 1.2.20), but all verisons have been built and tested.
+Chef projects are managed by our Expeditor release tooling application. This application is executed each time a GitHub Pull Request is merged and increments the patch version of the software before running the change through our internal CI/CD pipeline. As not all builds will make it successfully through the CI/CD pipeline, the versions available for public consumption might have gaps (e.g. 1.2.1, 1.2.10, 1.2.11, 1.2.12, 1.2.20), but all versions have been built and tested.
 
 ## Support Schedule