Additional corrections

Signed-off-by: Ian Maddaus <[email protected]>

Author: IanMadd

archetypes/all_the_resources.md

@@ -70,7 +70,7 @@ The following properties are common to every resource:
 `sensitive`
 : **Ruby Type:** true, false | **Default Value:** `false`
 
-  Ensure that sensitive resource data is not logged by Chef Infra Client.
+  Ensure that sensitive resource data isn't logged by Chef Infra Client.
 
 #### Examples
 

content/attribute_precedence.md

@@ -227,7 +227,7 @@ When the default attribute precedence `node['foo']['bar']` is removed:
 node.rm_default('foo', 'bar') #=> {'baz' => 52, 'thing' => 'allthestuff'}
 ```
 
-What is left under `'foo'` is only `'bat'`:
+What's left under `'foo'` is only `'bat'`:
 
 ```ruby
 node.attributes.combined_default['foo'] #=> {'bat' => { 'things' => [5,6] } }

content/azure_cwa_cloud_shell.md

@@ -37,7 +37,7 @@ need for a local shell.
 ## Azure Cloud Shell Installation
 
 Ensure you have an accessible Azure Cloud Shell instance. You may need
-to create a storage account to use Azure Cloud Shell if you have not used
+to create a storage account to use Azure Cloud Shell if you haven't used
 it before in this tenant. For more information on accessing, setting up,
 and using Azure Cloud Shell, see the [Cloud Shell
 Documentation](https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart).

content/community_contributions.md

@@ -107,7 +107,7 @@ By making a contribution to this project, I certify that:
     Indicated in the file; or
 
 (c) The contribution was provided directly to me by some other
-    person who certified (a), (b) or (c) and I have not modified
+    person who certified (a), (b) or (c) and I haven't modified
     it.
 
 (d) I understand and agree that this project and the contribution

content/community_guidelines.md

@@ -233,7 +233,7 @@ that behavior. The Community Advocate may:
 - Allow time for the violator to correct the behavior.
 
 The Community Advocate should take the following steps if the behavior
-is not brought in-line with our guidelines or the incident isn't
+isn't brought in-line with our guidelines or the incident isn't
 resolved:
 
 - Consult with another Community Organizer to make a judgment call

content/ctl_chef_client.md

@@ -687,9 +687,9 @@ Infra Client on a logical partition (LPAR). When the system process
 limits are too low, the Chef Infra Client won't be able to create
 threads. To increase the system process limits:
 
-1. Validate that the system process limits have not already been increased.
+1. Validate that the system process limits haven't already been increased.
 
-2. If they have not been increased, run the following commands as a root user:
+2. If they haven't been increased, run the following commands as a root user:
 
     ```bash
     chsec -f /etc/security/limits -s default -a "rss=-1"

content/custom_resources_notes.md

@@ -92,9 +92,9 @@ end
 
 ## Library Resources/Providers
 
-Library resources are discouraged since you can shoot yourself in the foot. They used to be encouraged back before Chef Infra Client 12.0 `provides` was introduced since it allowed for renaming the resource so that it did not have to be prefixed by the cookbook name.
+Library resources are discouraged since you can shoot yourself in the foot. They used to be encouraged back before Chef Infra Client 12.0 `provides` was introduced since it allowed for renaming the resource so that it didn't have to be prefixed by the cookbook name.
 
-There are many ways to go wrong writing library providers. One of the biggest issues is that internal Chef Infra Client code superficially looks like a library provider, but it's not. Chef internal resources don't inherit from `LWRPBase` and we've had to manually create resources directly through `Chef::Resource::File.new()`, we also have not been able to `use_inline_resources` and not had access to other niceties that cookbook authors have had access to for years now. We've got some modernization of internal Chef cookbook code now and resources like `apt_update` and `apt_repository` in core have started to be written more like cookbook code should be written, but core resources are actually behind the curve and are bad code examples.
+There are many ways to go wrong writing library providers. One of the biggest issues is that internal Chef Infra Client code superficially looks like a library provider, but it's not. Chef internal resources don't inherit from `LWRPBase` and we've had to manually create resources directly through `Chef::Resource::File.new()`, we also haven't been able to `use_inline_resources` and not had access to other niceties that cookbook authors have had access to for years now. We've got some modernization of internal Chef cookbook code now and resources like `apt_update` and `apt_repository` in core have started to be written more like cookbook code should be written, but core resources are actually behind the curve and are bad code examples.
 
 in `libraries/resource_my_resource.rb`:
 
@@ -176,7 +176,7 @@ action :run do
 end
 ```
 
-That is the magic of `use_inline_resources` (and why `use_inline_resources` is turned on by default in Chef Infra Client 12.5 resources) The sub-resources are defined in a sub-resource collection which is compiled and converged as part of the provider executing. Any resources that update in the sub-resource collection cause the resource itself to be updated automatically. Notifications then fire normally off the resource. It also works to arbitrary levels of nesting of sub-sub-sub-resources being updating causing the wrapping resources to update and fire notifications.
+That's the magic of `use_inline_resources` (and why `use_inline_resources` is turned on by default in Chef Infra Client 12.5 resources) The sub-resources are defined in a sub-resource collection which is compiled and converged as part of the provider executing. Any resources that update in the sub-resource collection cause the resource itself to be updated automatically. Notifications then fire normally off the resource. It also works to arbitrary levels of nesting of sub-sub-sub-resources being updating causing the wrapping resources to update and fire notifications.
 
 This also gets the why-run case correct. If all the work that you do in your resource is done by calling sub-resources, then why-run should work automatically. All your sub-resources will be NO-OP'd and will report what they would have done instead of doing it.
 

content/deprecations_attributes.md

@@ -10,7 +10,7 @@ aliases = "/deprecations_attributes.html"
 
 +++
 
-We are continuously improving and streamlining the way attributes work
+We're continuously improving and streamlining the way attributes work
 in Chef, to make it easier for users to reason about and safely
 configure their servers.
 

content/deprecations_custom_resource_cleanups.md

@@ -9,7 +9,7 @@ aliases = "/deprecations_custom_resource_cleanups.html"
 
 +++
 
-We are continuously improving and streamlining the way custom resources
+We're continuously improving and streamlining the way custom resources
 work in Chef, to make it easier for cookbook authors and Chef developers
 to build resources.
 
@@ -39,7 +39,7 @@ Otherwise, remove the `default: nil` statement from the property.
 ## Invalid Defaults
 
 Current versions of Chef emit a warning when a property's default value
-is not valid. This is often because the type of the default value
+isn't valid. This is often because the type of the default value
 doesn't match the specification of the property. For example:
 
 ```ruby

content/deprecations_namespace_collisions.md

@@ -152,7 +152,7 @@ action :doit do
 end
 ```
 
-We are now enforcing this as the correct way to write resources.
+We're now enforcing this as the correct way to write resources.
 
 Note that this namespace collision between custom resources and
 subresources occurs with properties that aren't also being immediately