Merge pull request #10054 from chef/misc_15

Pull in misc docs / comment updates from master

34 files changed, 186 insertions, 108 deletions

diff --git a/.gitignore b/.gitignore
index 89b8af9757..52705a76ef 100644
--- a/.gitignore
+++ b/.gitignore
@@ -84,3 +84,6 @@ distro/powershell/chef/chef.psm1
 
 # tool logs
 ext/win32-eventlog/mkmf.log
+
+# ignore byebug command history file.
+.byebug_history
diff --git a/CHEF_MVPS.md b/CHEF_MVPS.md
index cc0fcb710a..e623e4a948 100644
--- a/CHEF_MVPS.md
+++ b/CHEF_MVPS.md
@@ -1,23 +1,78 @@
-### Chef is proud of our community!
+# Chef is proud of our community
 
 Every release of Chef we pick someone from the community to name as the Most Valuable Player for that release. It could be someone who provided a big feature, reported a security vulnerability, or someone doing great things in the community that we want to highlight.
 
 In addition to the Hall of Fame and MVP recipients, a number of individuals are awarded the distinction
 of "Awesome Community Chef" each year at ChefConf.
 
-#### Hall of Fame
+## Lifetime Community Chef Award
+
+The Lifetime Community Chef Award is a recognition of years of investment by a member of the community, and is awarded only occasionally.
+
+- [2020](https://blog.chef.io/congratulations-awesome-community-chefs-2020/)
+  - [Mandi Walls](https://github.com/lnxchk)
+- [2019](https://blog.chef.io/congratulations-to-our-2019-awesome-community-chefs/)
+  - [Nathen Harvey](https://github.com/NathenHarvey)
+
+## Awesome Community Chefs
+
+Each year at ChefConf, a number of individuals are awarded the Awesome Community Chef award. The Awesome Community Chef awards are a way for the community to recognize a few of the individuals who have made a dramatic impact and have helped further the cause.
+
+- [2020](https://blog.chef.io/congratulations-awesome-community-chefs-2020/)
+  - [Bastien Jove](https://github.com/tensibai)
+  - [Lance Albertson](https://github.com/ramereth)
+  - [Marc Chamberland](https://github.com/bobchaos)
+- [2019][USA](https://blog.chef.io/congratulations-to-our-2019-awesome-community-chefs/), [Europe](https://blog.chef.io/congratulations-to-our-chefconf-london-2019-award-winners/)
+  - [Graham Weldon](https://github.com/predominant)
+  - [Jason Field](https://github.com/xorima)
+  - [Joshua Basch](https://github.com/HT154)
+  - [Karl Fischer](https://github.com/kmf)
+  - [Nathen Harvey](https://github.com/NathenHarvey)
+  - [Robb Kidd](https://github.com/RobbKidd)
+  - [Tomas Heinen](https://github.com/tecracer-theinen)
+- [2018](https://blog.chef.io/2018/05/24/2018-awesome-community-chefs/)
+  - [Dan Webb](https://github.com/damacus)
+  - [Romain Sertelon](https://github.com/rsertelon)
+  - [Edmund Haselwanter](https://github.com/ehaselwanter)
+  - [Tim Smith](https://github.com/tas50)
+  - [Joshua Timberman](https://github.com/jtimberman)
+- [2017](https://blog.chef.io/2017/06/08/awesome-community-chefs-2017-award-winners/)
+  - [Ben Dang](https://github.com/bdangit)
+  - [Annie Hedgpeth](https://github.com/anniehedgpeth)
+  - [Sean O'Meara](https://github.com/someara)
+  - [Nell Shamrell-Harrington](https://github.com/nellshamrell)
+- [2016](https://blog.chef.io/2016/08/31/awesome-community-chefs-2016/)
+  - [Mike Fiedler](https://github.com/miketheman)
+  - [Doug Ireton](https://github.com/dougireton)
+  - [Stuart Preston](https://github.com/stuartpreston)
+  - [Seth Thomas](https://github.com/cheeseplus)
+- 2015
+  - [Jon Cowie](https://github.com/jonlives)
+  - [Noah Kantrowitz](https://github.com/coderanger)
+  - [Matt Wrock](https://github.com/mwrock)
+- 2014
+  - [Ranjib Dey](https://github.com/ranjib)
+  - [Miah Johnson](https://github.com/miah)
+  - [Seth Vargo](https://github.com/sethvargo)
+  - [Eric Wolfe](https://github.com/atomic-penguin)
+- 2013
+  - [Bryan Berry](https://github.com/bryanwb)
+  - [Fletcher Nichol](https://github.com/fnichol)
+  - [Jamie Winsor](https://github.com/reset)
+
+## Hall of Fame
 
 After receiving three MVP awards, we add someone to the hall of fame. We want to express our gratitude to their continuing participation and give newer community members the opportunity to be recognized.
 
-* Matthew Kent
-* Doug MacEachern
-* Tollef Fog Heen
-* Thom May
-* Bryan Berry
-* Bryan McLellan
-* Jeff Blaine
+- Matthew Kent
+- Doug MacEachern
+- Tollef Fog Heen
+- Thom May
+- Bryan Berry
+- Bryan McLellan
+- Jeff Blaine
 
-#### The MVP recipients
+## The MVP recipients
 
 | Release | Date | MVP |
 |---------|------|-----|
@@ -90,36 +145,3 @@ After receiving three MVP awards, we add someone to the hall of fame. We want to
 | [Chef 0.5.4](https://www.chef.io/blog/2009/02/13/chef-0-5-4/) | 2009-02-13 | Arjuna Christensen |
 | [Chef 0.5.2](https://www.chef.io/blog/2009/02/01/chef-0-5-2-and-ohai-0-1-4/) | 2009-02-01 | Bryan McLellan |
 
-#### Awesome Community Chefs
-
-Each year at ChefConf, a number of individuals are awarded the Awesome Community Chef award. The Awesome Community Chef awards are a way for the community to recognize a few of the individuals who have made a dramatic impact and have helped further the cause.
-
-* 2013
-  * [Bryan Berry](https://github.com/bryanwb)
-  * [Fletcher Nichol](https://github.com/fnichol)
-  * [Jamie Winsor](https://github.com/reset)
-* 2014
-  * [Ranjib Dey](https://github.com/ranjib)
-  * [Miah Johnson](https://github.com/miah)
-  * [Seth Vargo](https://github.com/sethvargo)
-  * [Eric Wolfe](https://github.com/atomic-penguin)
-* 2015
-  * [Jon Cowie](https://github.com/jonlives)
-  * [Noah Kantrowitz](https://github.com/coderanger)
-  * [Matt Wrock](https://github.com/mwrock)
-* [2016](https://blog.chef.io/2016/08/31/awesome-community-chefs-2016/)
-  * [Mike Fiedler](https://github.com/miketheman)
-  * [Doug Ireton](https://github.com/dougireton)
-  * [Stuart Preston](https://github.com/stuartpreston)
-  * [Seth Thomas](https://github.com/cheeseplus)
-* [2017](https://blog.chef.io/2017/06/08/awesome-community-chefs-2017-award-winners/)
-  * [Ben Dang](https://github.com/bdangit)
-  * [Annie Hedgpeth](https://github.com/anniehedgpeth)
-  * [Sean O'Meara](https://github.com/someara)
-  * [Nell Shamrell-Harrington](https://github.com/nellshamrell)
-* [2018](https://blog.chef.io/2018/05/24/2018-awesome-community-chefs/)
-  * [Dan Webb](https://github.com/damacus)
-  * [Romain Sertelon](https://github.com/rsertelon)
-  * [Edmund Haselwanter](https://github.com/ehaselwanter)
-  * [Tim Smith](https://github.com/tas50)
-  * [Joshua Timberman](https://github.com/jtimberman)
\ No newline at end of file
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0b08f7e46f..2ccfb550ba 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -33,9 +33,9 @@ Code review takes place in GitHub pull requests. See [this article](https://help
 
 Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
 
-1. Two thumbs-up (:+1:) are required from project maintainers. See the master maintainers document for Chef projects at <https://github.com/chef/chef-oss-practices/blob/master/projects/chef-infra.md>.
+1. Two or more members of the owners, approvers, or reviewers groups must approve your PR. See the [Chef Infra OSS Project](https://github.com/chef/chef-oss-practices/blob/master/projects/chef-infra.md) for a list of all members.
 2. Your change will be merged into the project's `master` branch
-3. Our Expeditor bot will automatically update the project's changelog with your contribution. For projects such as Chef and Chef-DK the version will be automatically incremented and a build kicked off to the project's `current` channel.
+3. Our Expeditor bot will automatically increment the version and update the project's changelog with your contribution. For projects that ship as a package, Expeditor will kick off a build which will publish the package to the project's `current` channel.
 
 If you would like to learn about when your code will be available in a release of Chef, read more about [Chef Release Cycles](#release-cycles).
 
@@ -90,7 +90,7 @@ The DCO requires a sign-off message in the following format appear on each commi
 Signed-off-by: Julia Child <juliachild@chef.io>
 ```
 
-The DCO text can either be manually added to your commit body, or you can add either **-s** or **--signoff** to your usual git commit commands. If you are using the GitHub UI to make a change you can add the sign-off message directly to the pull request description. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running **git commit --amend -s**. If you've pushed your changes to GitHub already you'll need to force push your branch after this with **git push -f**.
+The DCO text can either be manually added to your commit body, or you can add either **-s** or **--signoff** to your usual git commit commands. If you are using the GitHub UI to make a change you can add the sign-off message directly to the commit message when creating the pull request. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running **git commit --amend -s**. If you've pushed your changes to GitHub already you'll need to force push your branch after this with **git push -f**.
 
 ### Chef Obvious Fix Policy
 
@@ -125,7 +125,7 @@ Date:   Wed Sep 18 11:44:40 2015 -0700
 
 Our primary shipping vehicle is operating system specific packages that includes all the requirements of Chef. The packages are built with our [Omnibus](https://github.com/chef/omnibus) packing project.
 
-We also release our software as gems to [Rubygems](https://rubygems.org/) but we strongly recommend using Chef packages since they are the only combination of native libraries & gems required by Chef that we test throughly.
+We also release our software as gems to [Rubygems](https://rubygems.org/) but we strongly recommend using Chef packages since they are the only combination of native libraries & gems required by Chef that we test thoroughly.
 
 Our version numbering roughly follows [Semantic Versioning](http://semver.org/) standard. Our standard version numbers look like X.Y.Z which mean:
 
@@ -133,7 +133,7 @@ Our version numbering roughly follows [Semantic Versioning](http://semver.org/)
 - Y is a minor release, which adds both new features and bug fixes
 - Z is a patch release, which adds just bug fixes
 
-After shipping a release of Chef we bump the `Minor` version by one to start development of the next minor release. All merges to master trigger an increment of the `Patch` version, and a build through our internal testing pipeline. We do a `Minor` release approximately every month, which consist of shipping one of the already auto-incremented and tested `Patch` versions. For example after shiping 12.10.24, we incremented Chef to 12.11.0\. From there 18 commits where merged bringing the version to 12.11.18, which we shipped as an omnibus package.
+After shipping a release of Chef we bump the `Minor` version by one to start development of the next minor release. All merges to master trigger an increment of the `Patch` version, and a build through our internal testing pipeline. We do a `Minor` release approximately every month, which consist of shipping one of the already auto-incremented and tested `Patch` versions. For example after shipping 12.10.24, we incremented Chef to 12.11.0\. From there 18 commits where merged bringing the version to 12.11.18, which we shipped as an omnibus package.
 
 Announcements of releases are made to the [chef mailing list](https://discourse.chef.io/c/chef-release) when they are available and are mirrored to the #announcements channel on the [Chef Community Slack](https://community-slack.chef.io/).
 
diff --git a/README.md b/README.md
index 484126f451..c89bbbf942 100644
--- a/README.md
+++ b/README.md
@@ -18,7 +18,7 @@ Chef Infra is a configuration management tool designed to bring automation to yo
 
 ### Want to try Chef Infra?
 
-For Chef Infra usage, please refer to our [Learn Chef Rally](https://learn.chef.io/) website, which includes module-based training for Chef Infra, as well as Automate, Habitat, and InSpec.
+For Chef Infra usage, please refer to [Learn Chef](https://learn.chef.io/), our self-paced, entirely free learning platform. Learn Chef also includes module-based training for Chef Infra, as well as Chef Automate, Chef Habitat, and Chef InSpec.
 
 Other useful resources for Chef Infra users:
 
@@ -26,7 +26,7 @@ Other useful resources for Chef Infra users:
 - Source: <https://github.com/chef/chef/tree/master>
 - Tickets/Issues: <https://github.com/chef/chef/issues>
 - Slack: [Chef Community Slack](https://community-slack.chef.io/)
-- Mailing list: <https://discourse.chef.io>
+- Mailing list/Forum: <https://discourse.chef.io>
 
 ## Reporting Issues
 
@@ -46,7 +46,7 @@ We'd love to have your help developing Chef Infra. See our [Contributing Documen
 
 ## License and Copyright
 
-Copyright 2008-2019, Chef Software, Inc.
+Copyright 2008-2020, Chef Software, Inc.
 
 ```
 Licensed under the Apache License, Version 2.0 (the "License");
diff --git a/chef-config/lib/chef-config/config.rb b/chef-config/lib/chef-config/config.rb
index 5a88251dcc..fc9128823f 100644
--- a/chef-config/lib/chef-config/config.rb
+++ b/chef-config/lib/chef-config/config.rb
@@ -483,7 +483,7 @@ module ChefConfig
       # 11 (true) or Chef Server 12 (false). Chef Zero can still serve
       # policyfile objects in Chef 11 mode, as long as `repo_mode` is set to
       # "hosted_everything". The primary differences are:
-      # * Chef 11 mode doesn't support multi-tennant, so there is no
+      # * Chef 11 mode doesn't support multi-tenant, so there is no
       #   distinction between global and org-specific objects (since there are
       #   no orgs).
       # * Chef 11 mode doesn't expose RBAC objects
@@ -531,7 +531,7 @@ module ChefConfig
     # switching based on it is almost certainly doing the wrong thing and papering over
     # bugs that should be fixed in one or the other class, and will be brittle and destined
     # to break in the future (and not necessarily on a major version bump). Checking this value
-    # is also not sufficent to determine if we are not running against a server since this can
+    # is also not sufficient to determine if we are not running against a server since this can
     # be unset but :local_mode may be set.  It would be accurate to check both :solo and :local_mode
     # to determine if we're not running against a server, but the more semantically accurate test
     # is going to be combining :solo_legacy_mode and :local_mode.
@@ -956,7 +956,7 @@ module ChefConfig
     # distribution.
     #
     # The disadvantages of lazily loading files are that users some time find it
-    # confusing that their cookbooks are not fully synchronzied to the cache initially,
+    # confusing that their cookbooks are not fully synchronized to the cache initially,
     # and more importantly the time-sensitive URLs which are in the manifest may time
     # out on long Chef runs before the resource that uses the file is converged
     # (leading to many confusing 403 errors on template/cookbook_file resources).
@@ -1113,7 +1113,7 @@ module ChefConfig
     end
 
     # Given a scheme, host, and port, return the correct proxy URI based on the
-    # set environment variables, unless exluded by no_proxy, in which case nil
+    # set environment variables, unless excluded by no_proxy, in which case nil
     # is returned
     def self.proxy_uri(scheme, host, port)
       proxy_env_var = ENV["#{scheme}_proxy"].to_s.strip
diff --git a/chef-config/lib/chef-config/path_helper.rb b/chef-config/lib/chef-config/path_helper.rb
index 80cac88f97..dc57253486 100644
--- a/chef-config/lib/chef-config/path_helper.rb
+++ b/chef-config/lib/chef-config/path_helper.rb
@@ -130,16 +130,16 @@ module ChefConfig
     end
 
     # This is the INVERSE of Pathname#cleanpath, it converts forward
-    # slashes to backwhacks for Windows.  Since the Ruby API and the
+    # slashes to backslashes for Windows.  Since the Ruby API and the
     # Windows APIs all consume forward slashes, this helper function
     # should only be used for *DISPLAY* logic to send strings back
-    # to the user with backwhacks.  Internally, filename paths should
+    # to the user with backslashes.  Internally, filename paths should
     # generally be stored with forward slashes for consistency.  It is
     # not necessary or desired to blindly convert pathnames to have
-    # backwhacks on Windows.
+    # backslashes on Windows.
     #
     # Generally, if the user isn't going to be seeing it, you should be
-    # using Pathname#cleanpath intead of this function.
+    # using Pathname#cleanpath instead of this function.
     def self.cleanpath(path)
       path = Pathname.new(path).cleanpath.to_s
       # ensure all forward slashes are backslashes
@@ -265,7 +265,7 @@ module ChefConfig
       end
     end
 
-    # Determine if the given path is protected by OS X System Integrity Protection.
+    # Determine if the given path is protected by macOS System Integrity Protection.
     def self.is_sip_path?(path, node)
       if node["platform"] == "mac_os_x" && Gem::Version.new(node["platform_version"]) >= Gem::Version.new("10.11")
         # @todo: parse rootless.conf for this?
@@ -282,7 +282,7 @@ module ChefConfig
       end
     end
 
-    # Determine if the given path is on the exception list for OS X System Integrity Protection.
+    # Determine if the given path is on the exception list for macOS System Integrity Protection.
     def self.writable_sip_path?(path)
       # todo: parse rootless.conf for this?
       sip_exceptions = [
diff --git a/chef-utils/README.md b/chef-utils/README.md
index c4a926e016..e8464035c2 100644
--- a/chef-utils/README.md
+++ b/chef-utils/README.md
@@ -30,9 +30,9 @@ The Platform Family helpers provide an alternative to comparing values from `nod
 * `netbsd?`
 * `openbsd?`
 * `rhel?` - includes redhat, centos, scientific, oracle, and clearos platforms
-* `rhel6?` - includes redhat6, centos6, scientifc6, oracle6, and clearos6 platforms
-* `rhel7?` - includes redhat7, centos7, scientifc7, oracle7, and clearos7 platforms
-* `rhel8?` - includes redhat8, centos8, scientifc8, oracle8, and clearos8 platforms
+* `rhel6?` - includes redhat6, centos6, scientific6, oracle6, and clearos6 platforms
+* `rhel7?` - includes redhat7, centos7, scientific7, oracle7, and clearos7 platforms
+* `rhel8?` - includes redhat8, centos8, scientific8, oracle8, and clearos8 platforms
 * `smartos?`
 * `solaris2?`
 * `suse?` - includes suse and opensuseleap platforms
@@ -41,7 +41,7 @@ The Platform Family helpers provide an alternative to comparing values from `nod
 
 Super Families:
 
-* `fedora_based?` - anything of fedora lineage (fedora, fedhat, centos, amazon, pidora, etc)
+* `fedora_based?` - anything of fedora lineage (fedora, redhat, centos, amazon, pidora, etc)
 * `rpm_based?`- all `fedora_based` systems plus `suse` and any future linux distros based on RPM (excluding AIX)
 * `solaris_based?`- all solaris-derived systems (opensolaris, nexentacore, omnios, smartos, etc)
 * `bsd_based?`- all bsd-derived systems (freebsd, netbsd, openbsd, dragonflybsd).
@@ -224,7 +224,7 @@ Those methods are marked API private for the purposes of end-users, but are publ
 
 ## Getting Involved
 
-We'd love to have your help developing Chef Infra. See our [Contributing Document](./CONTRIBUTING.md) for more information on getting started.
+We'd love to have your help developing Chef Infra. See our [Contributing Document](../CONTRIBUTING.md) for more information on getting started.
 
 ## License and Copyright
 
diff --git a/chef-utils/lib/chef-utils/dsl/introspection.rb b/chef-utils/lib/chef-utils/dsl/introspection.rb
index 1a8dcd29fa..35a0be73bd 100644
--- a/chef-utils/lib/chef-utils/dsl/introspection.rb
+++ b/chef-utils/lib/chef-utils/dsl/introspection.rb
@@ -31,7 +31,7 @@ module ChefUtils
       # Determine if the node is a docker container.
       #
       # @param [Chef::Node] node the node to check
-      # @since 15.5
+      # @since 12.11
       #
       # @return [Boolean]
       #
diff --git a/chef-utils/lib/chef-utils/dsl/platform_family.rb b/chef-utils/lib/chef-utils/dsl/platform_family.rb
index 8feadeb9c4..cfe6b617e5 100644
--- a/chef-utils/lib/chef-utils/dsl/platform_family.rb
+++ b/chef-utils/lib/chef-utils/dsl/platform_family.rb
@@ -301,7 +301,7 @@ module ChefUtils
       end
 
       # RedHat distros -- fedora and rhel platform_families, nothing else. This is most likely not as useful as the
-      # "fedora_dervied?" helper.
+      # "fedora_derived?" helper.
       #
       # @param [Chef::Node] node the node to check
       # @since 15.5
diff --git a/chef-utils/lib/chef-utils/dsl/virtualization.rb b/chef-utils/lib/chef-utils/dsl/virtualization.rb
index 3daf47f899..ebc5d5228a 100644
--- a/chef-utils/lib/chef-utils/dsl/virtualization.rb
+++ b/chef-utils/lib/chef-utils/dsl/virtualization.rb
@@ -161,7 +161,7 @@ module ChefUtils
         node.dig("virtualization", "system") == "openvz" && node.dig("virtualization", "role") == "host"
       end
 
-      # Determine if the current node is running under any virutalization environment
+      # Determine if the current node is running under any virtualization environment
       #
       # @param [Chef::Node] node
       # @since 15.8
diff --git a/chef-utils/lib/chef-utils/dsl/which.rb b/chef-utils/lib/chef-utils/dsl/which.rb
index cc554a5e8a..a91e35da38 100644
--- a/chef-utils/lib/chef-utils/dsl/which.rb
+++ b/chef-utils/lib/chef-utils/dsl/which.rb
@@ -25,7 +25,7 @@ module ChefUtils
       # Lookup an executable through the systems search PATH.  Allows specifying an array
       # of executables to look for.  The first executable that is found, along any path entry,
       # will be the preferred one and returned first.  The extra_path will override any default
-      # extra_paths which are added (allwing the user to pass an empty array to remove them).
+      # extra_paths which are added (allowing the user to pass an empty array to remove them).
       #
       # When passed a block the block will be called with the full pathname of any executables
       # which are found, and the block should return truthy or falsey values to further filter
@@ -34,7 +34,7 @@ module ChefUtils
       # This is syntactic sugar for `where(...).first`
       #
       # This helper can be used in target mode in chef or with train using the appropriate
-      # wiring extenerally.
+      # wiring externally.
       #
       # @example Find the most appropriate python executable, searching through the system PATH
       #          plus additionally the "/usr/libexec" directory, which has the dnf libraries
@@ -55,14 +55,14 @@ module ChefUtils
       # Lookup all the instances of an an executable that can be found through the systems search PATH.
       # Allows specifying an array of executables to look for.  All the instances of the first executable
       # that is found will be returned first.  The extra_path will override any default extra_paths
-      # which are added (allwing the user to pass an empty array to remove them).
+      # which are added (allowing the user to pass an empty array to remove them).
       #
       # When passed a block the block will be called with the full pathname of any executables
       # which are found, and the block should return truthy or falsey values to further filter
       # the executable based on arbitrary criteria.
       #
       # This helper can be used in target mode in chef or with train using the appropriate
-      # wiring extenerally.
+      # wiring externally.
       #
       # @example Find all the python executables, searching through the system PATH plus additionally
       #          the "/usr/libexec" directory, which have the dnf libraries installed and available.
diff --git a/chef-utils/lib/chef-utils/internal.rb b/chef-utils/lib/chef-utils/internal.rb
index 713ac277de..731a0d1712 100644
--- a/chef-utils/lib/chef-utils/internal.rb
+++ b/chef-utils/lib/chef-utils/internal.rb
@@ -27,7 +27,7 @@ module ChefUtils
   #
   # This gem may be used by gems like mixlib-shellout which can be consumed by external non-Chef utilities,
   # so including brittle code here which depends on the existence of the chef-client will cause broken
-  # behavior downstream.  You must practice defensive coding, and not make assumptions about runnign within chef-client.
+  # behavior downstream.  You must practice defensive coding, and not make assumptions about running within chef-client.
   #
   # Other consumers may mix in the helper classes and then override the methods here and provide their own custom
   # wiring and override what is provided here.  They are marked as private because no downstream user should ever touch
diff --git a/chef-utils/spec/unit/dsl/introspection_spec.rb b/chef-utils/spec/unit/dsl/introspection_spec.rb
index 2b6c697fd7..44a228061d 100644
--- a/chef-utils/spec/unit/dsl/introspection_spec.rb
+++ b/chef-utils/spec/unit/dsl/introspection_spec.rb
@@ -31,7 +31,7 @@ RSpec.describe ChefUtils::DSL::Introspection do
   let(:test_instance) { IntrospectionTestClass.new(node) }
 
   context "#docker?" do
-    # FIXME: use a real VividMash for these tests insted of stubbing
+    # FIXME: use a real VividMash for these tests instead of stubbing
     it "is false by default" do
       expect(node).to receive(:read).with("virtualization", "systems", "docker").and_return(nil)
       expect(ChefUtils.docker?(node)).to be false
diff --git a/distro/templates/powershell/chef/chef.psm1.erb b/distro/templates/powershell/chef/chef.psm1.erb
index 652dec04f6..f8b24dc54b 100644
--- a/distro/templates/powershell/chef/chef.psm1.erb
+++ b/distro/templates/powershell/chef/chef.psm1.erb
@@ -358,7 +358,7 @@ function Run-RubyCommand($command, $argList) {
   # When arguments come into this method, the standard PS rules for interpreting cmdlet arguments
   # apply.  When using & (call operator) and providing an array of arguments, powershell (verified
   # on PS 4.0 on Windows Server 2012R2) will not evaluate them but (contrary to documentation),
-  # it will still marginally interpret them.  The behaviour of PS 5.0 seems to be different but
+  # it will still marginally interpret them.  The behavior of PS 5.0 seems to be different but
   # ignore that for now.  If any of the provided arguments has a space in it, powershell checks
   # the first and last character to ensure that they are " characters (and that's all it checks).
   # If they are not, it will blindly surround that argument with " characters.  It won't do this
@@ -381,10 +381,10 @@ function Run-RubyCommand($command, $argList) {
   # Command line:
   # "C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Apps\EchoArgs.exe"  "foo '' bar "baz"" "foo '' bar "baz""
   #
-  # $x = "abc'123'nospace`"lulz`"!!!"
+  # $x = "abc'123'nospace`"lol`"!!!"
   # & EchoArgs @($x, $x)
   # Command line:
-  # "C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Apps\EchoArgs.exe"  abc'123'nospace"lulz"!!! abc'123'nospace"lulz"!!!
+  # "C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Apps\EchoArgs.exe"  abc'123'nospace"lol"!!! abc'123'nospace"lol"!!!
   #
   # $x = "`"`"Look ma! Tonnes of spaces! 'foo' 'bar'`"`""
   # & EchoArgs @($x, $x)
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/how_chef_is_tested_and_built.md b/docs/dev/design_documents/how_chef_is_tested_and_built.md
index 094dd68caa..fda2ac6156 100644
--- a/docs/dev/design_documents/how_chef_is_tested_and_built.md
+++ b/docs/dev/design_documents/how_chef_is_tested_and_built.md
@@ -32,7 +32,7 @@ Every commit that we merge into Chef Infra should be ready to release. In order
 
 Once the version has been incremented, Expeditor will begin a build matrix in our internal Buildkite pipeline. In Buildkite, we build omnibus-based system packages of Chef Infra for multiple platforms, distros, and architectures. Each of the platforms we build are those which will eventually be available on our downloads site if this build is successful and later promoted. Upon completion, builds are promoted to the `unstable` channel and are available to any system supporting our Omnitruck API (Test Kitchen, mixlib-install, etc).
 
-Once the builds complete, Buildkite will move to the test phase where each of these builds will be verified on all the platforms that Chef officially supports. For many build artifacts, this means the artifact tests on multiple versions of the same platform. For example, Chef is built on Windows 2012 R2, yet tests are run on 2008, 2012, 2012 R2, and 2016 to ensure full compatibility. In total, this phase includes nearly three dozen test nodes. Assuming all tests pass, the build will be promoted to the `current` channel, which is available on the downloads site, in addition to being available via the Omnitruck API.
+Once the builds complete, Buildkite will move to the test phase where each of these builds will be verified on all the platforms that Chef officially supports. For many build artifacts, this means the artifact tests on multiple versions of the same platform. For example, Chef is built on Windows 2012 R2, yet tests are run on 2012, 2012 R2, and 2016 to ensure full compatibility. In total, this phase includes nearly three dozen test nodes. Assuming all tests pass, the build will be promoted to the `current` channel, which is available on the downloads site, in addition to being available via the Omnitruck API.
 
 ## Releasing Chef
 
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/design_documents/resource_load_and_converge_methods.md b/docs/dev/design_documents/resource_load_and_converge_methods.md
index b7046d1892..00b074578b 100644
--- a/docs/dev/design_documents/resource_load_and_converge_methods.md
+++ b/docs/dev/design_documents/resource_load_and_converge_methods.md
@@ -30,7 +30,6 @@ When the resource writer defines `load_current_value` on the resource class, it
 2. Copy all non-desired-state values from the desired resource into the new instance.
 3. Call `load_current_value` on the new instance.
 
-
 ```ruby
 class File < Chef::Resource
   property :path, name_attribute: true
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/building_and_installing.md b/docs/dev/how_to/building_and_installing.md
index e613de459a..9de9922108 100644
--- a/docs/dev/how_to/building_and_installing.md
+++ b/docs/dev/how_to/building_and_installing.md
@@ -1,8 +1,9 @@
 # Building and Installing
 
 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
+
+- 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 the [Chef Workstation package](https://downloads.chef.io/chef-workstation) for authoring Chef cookbooks and administering your Chef infrastructure.
 
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 ebcf4e4695..79cfa9075e 100644
--- a/docs/dev/how_to/bumping_minor_or_major_versions.md
+++ b/docs/dev/how_to/bumping_minor_or_major_versions.md
@@ -2,14 +2,15 @@
 
 ## When to Bump Versions
 
-
 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.
 
+See [Bumping The Major Version](bumping_the_major_version.md) for the major version bump process.
+
 ### 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:
- - Expeditor: Bump Version Minor
- - Expeditor: Bump Version Major
 
+- Expeditor: Bump Version Minor
+- Expeditor: Bump Version Major
diff --git a/docs/dev/how_to/bumping_the_major_version.md b/docs/dev/how_to/bumping_the_major_version.md
new file mode 100644
index 0000000000..ff93f5bcf6
--- /dev/null
+++ b/docs/dev/how_to/bumping_the_major_version.md
@@ -0,0 +1,51 @@
+# Bumping Major Version Number
+
+This document outlines the process for bumping the major version of Chef Infra Client for the yearly release.
+
+## Preparing Ohai
+
+Chef consumes Ohai from GitHub as both a runtime dependency and a testing dependency for Test Kitchen validations in Buildkite. Ohai's version is tightly coupled to that of Chef Infra Client so the first step in bumping the major release in the chef/chef repo is to bump the major version of Ohai.
+
+### Create a new stable branch of Ohai
+
+On your local machine fork the current master branch to a new stable branch. For example: `git checkout -b 15-stable`. You'll then want to edit the Expeditor config.yml file to update the branch configs like this:
+
+https://github.com/chef/ohai/commit/ad208165619425dd7886b2de3f168b49ded25146
+
+With the expeditor config complete push the branch `git push --set-upstream origin 15-stable`
+
+### Bump Ohai master to the new major version
+
+Create a PR which:
+
+- Edits the `VERSION` file in the root of the repository to the new major release
+- Updates the `chef-config` dependency to allow for the new major release of Chef Infra in `ohai.gemspec`
+
+## Fork Chef master to a stable branch
+
+Before bumping the major version of Chef Infra we want to fork off the current master to a new stable branch, which will be used to build hotfix releases. We support the N-1 version of Chef Infra Client for a year after the release of a new major version. For example Chef Infra Client 16 was released in April 2020, at which point Chef Infra Client 15 became the N-1 release. Chef Infra Client 15 will then be maintained with critical bug and security fixes until April 2021.
+
+On your local machine fork the current master branch to a new stable branch. For example: `git checkout -b chef-15` and `git push --set-upstream origin chef-15`, which can then be pushed up to GitHub.
+
+### Create a branch to fixup your new stable branch for release
+
+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_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
+- In tasks/bin/run_external_test update the ohai branch to point to your new stable ohai branch
+- In Gemfile set ohai to pull from the ohai stable branch
+- Run `rake dependencies:update`
+
+Example PR for Chef 15: https://github.com/chef/chef/pull/9236
+
+## Bump master for the new major release
+
+Create a PR that performs the following:
+
+- Update the version in the VERSION file
+- Update chef.gemspec to point to the new ohai major release
+- Update .expeditor/config.yml to include the new version_constraints you setup on your stable branch and an updated project alias
+- run `rake dependencies:update`
diff --git a/docs/dev/how_to/releasing_chef_infra.md b/docs/dev/how_to/releasing_chef_infra.md
index 8ff2165351..68070c420b 100644
--- a/docs/dev/how_to/releasing_chef_infra.md
+++ b/docs/dev/how_to/releasing_chef_infra.md
@@ -58,6 +58,7 @@ Many of our users consume Chef via Homebrew using our casks. Expeditor will crea
 Many Windows users consume our packages via Chocolatey. Make sure to update the various version strings and sha checksums here: https://github.com/chef/chocolatey-packages
 
 Once this is updated, you'll need to build / push the artifact to the Chocolatey site from a Windows host:
+
   1. `choco pack .\chef-client\chef-client.nuspec`
   2. `choco push .\chef-client.15.1.9.nupkg --key API_KEY_HERE`
 
diff --git a/docs/dev/how_to/updating_dependencies.md b/docs/dev/how_to/updating_dependencies.md
index 995bf4aabf..82bfc346bb 100644
--- a/docs/dev/how_to/updating_dependencies.md
+++ b/docs/dev/how_to/updating_dependencies.md
@@ -9,7 +9,5 @@ If you want to change our constraints (change which packages and versions we acc
 In order to update everything, run `rake dependencies`.  Note that the [Gemfile.lock](Gemfile.lock) pins Windows platform gems, 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
-bundle lock --update --add-platform x64-mingw32
-bundle lock --update --add-platform x86-mingw32
+bundle lock --update --add-platform ruby x64-mingw32 x86-mingw32
 ```
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
 
diff --git a/lib/chef/chef_fs/path_utils.rb b/lib/chef/chef_fs/path_utils.rb
index b8a83ab09f..31f1f6f12a 100644
--- a/lib/chef/chef_fs/path_utils.rb
+++ b/lib/chef/chef_fs/path_utils.rb
@@ -71,9 +71,9 @@ class Chef
       # part that actually exists.  The paths operated on here are not Chef-FS paths.
       # These are OS paths that may contain symlinks but may not also fully exist.
       #
-      # If /x is a symlink to /blarghle, and has no subdirectories, then:
-      # PathUtils.realest_path('/x/y/z') == '/blarghle/y/z'
-      # PathUtils.realest_path('/x/*/z') == '/blarghle/*/z'
+      # If /x is a symlink to /foo_bar, and has no subdirectories, then:
+      # PathUtils.realest_path('/x/y/z') == '/foo_bar/y/z'
+      # PathUtils.realest_path('/x/*/z') == '/foo_bar/*/z'
       # PathUtils.realest_path('/*/y/z') == '/*/y/z'
       #
       # TODO: Move this to wherever util/path_helper is these days.
diff --git a/lib/chef/cookbook/file_system_file_vendor.rb b/lib/chef/cookbook/file_system_file_vendor.rb
index 9cf3593838..a4a6711270 100644
--- a/lib/chef/cookbook/file_system_file_vendor.rb
+++ b/lib/chef/cookbook/file_system_file_vendor.rb
@@ -27,7 +27,7 @@ class Chef
     # and throws the rest away then re-builds the list of files on the
     # disk. This is due to the manifest not having the on-disk file
     # locations, since in the chef-client case, that information is
-    # non-sensical.
+    # nonsensical.
     class FileSystemFileVendor < FileVendor
 
       attr_reader :cookbook_name
diff --git a/lib/chef/data_collector/error_handlers.rb b/lib/chef/data_collector/error_handlers.rb
index 36252149a2..5cda3bde10 100644
--- a/lib/chef/data_collector/error_handlers.rb
+++ b/lib/chef/data_collector/error_handlers.rb
@@ -18,7 +18,7 @@
 class Chef
   class DataCollector
 
-    # This module isolates the handling of collecting error descriptions to insert into the data_colletor
+    # This module isolates the handling of collecting error descriptions to insert into the data_collector
     # report output.  For very early errors it is responsible for collecting the node_name for the report
     # to use.  For all failure conditions that have an ErrorMapper it collects the output.
     #
diff --git a/lib/chef/dsl/declare_resource.rb b/lib/chef/dsl/declare_resource.rb
index f032a76bc7..1fdd35cc3e 100644
--- a/lib/chef/dsl/declare_resource.rb
+++ b/lib/chef/dsl/declare_resource.rb
@@ -151,7 +151,7 @@ class Chef
       #     source "y.txt.erb"
       #     variables {}
       #   end
-      #   resource.variables.merge!({ home: "/home/klowns"  })
+      #   resource.variables.merge!({ home: "/home/clowns"  })
       #
       def edit_resource(type, name, created_at: nil, run_context: self.run_context, &resource_attrs_block)
         edit_resource!(type, name, created_at: created_at, run_context: run_context, &resource_attrs_block)
diff --git a/lib/chef/dsl/platform_introspection.rb b/lib/chef/dsl/platform_introspection.rb
index 50f30bda52..e3e7e2f96b 100644
--- a/lib/chef/dsl/platform_introspection.rb
+++ b/lib/chef/dsl/platform_introspection.rb
@@ -248,6 +248,8 @@ class Chef
       end
 
       # a simple helper to determine if we're on a windows release pre-2012 / 8
+      #
+      # @deprecated Windows releases before Windows 2012 and 8 are no longer supported
       # @return [Boolean] Is the system older than Windows 8 / 2012
       def older_than_win_2012_or_8?(node = run_context.nil? ? nil : run_context.node)
         node["platform_version"].to_f < 6.2
diff --git a/lib/chef/provider/package/chocolatey.rb b/lib/chef/provider/package/chocolatey.rb
index 0719eed12d..564d743c1a 100644
--- a/lib/chef/provider/package/chocolatey.rb
+++ b/lib/chef/provider/package/chocolatey.rb
@@ -251,7 +251,7 @@ class Chef
         end
 
         # Helper to convert choco.exe list output to a Hash
-        # (names are downcased for case-insenstive matching)
+        # (names are downcased for case-insensitive matching)
         #
         # @param cmd [String] command to run
         # @return [Hash] list output converted to ruby Hash