Update to Contributing Guidelines per comment

Author: buzzsurfr

CONTRIBUTING.adoc

@@ -16,7 +16,7 @@ The following labels are used to track bug related issues: link:https://github.c
 === Before Submitting a Bug Report
 Before submitting a bug report, please do the following:
 
-1. Do a search through the existing issues to make sure it has not already been reported. If there's an existing one, be sure give a +1 reaction which will help us prioritize which issues to address first.
+1. Do a search through the existing issues to make sure it has not already been reported. If there's an existing one, be sure to give a +1 reaction which will help us prioritize which issues to address first.
 
 2. Provide as much information about your environment, software version, and relevant dependencies as possible. For example, let us know what version of kubernetes you are using, which launch type for the kubernetes cluster (e.g. EKS or kops), and the environment your code is running in. (e.g Cloud9).
 
@@ -35,7 +35,7 @@ So that we are able to assist you as effectively as possible with the issue, ple
 === Tracking your Bug Report
 You will automatically be notified of any changes to a bug report. Either a maintainer or a community member may comment on the bug report requiring further input. We encourage all contributors to stay active on their bug reports reports. This helps the community to focus on issues with more influence and activity.
 
-We understand that contributors cannot devote 100% of their time to a project, just as our maintainers cannot devote 100% of their time to the project.. We want to squash bugs as often as we can, but sometimes require comments from the submitter or community in order to proceed.
+Any input to the workshop is always appreciated. Our maintainers cannot devote 100% of their time to this project, but will try to respond in a timely manner. We want to squash bugs as often as we can, but sometimes require comments from the submitter or community in order to proceed.
 
 If a bug report has been inactive (waiting on comment from submitter or community) for 14 days, a maintainer may label the issue as stale.  Once a bug report has been inactive for more than 28 days, the issue will be administratively closed. Issues can be re-opened after being administratively closed by commenting on the issue requesting to re-open and providing the necessary comment.
 
@@ -62,10 +62,10 @@ Contributions to the workshop are done through link:https://github.com/aws-sampl
 
 * The workshop is released under the link:https://github.com/aws-samples/aws-workshop-for-kubernetes/blob/master/LICENSE[Apache 2.0 License]. Any code you submit will be released under this license. If you are contributing a large/substantial enhancement, you may be asked to sign a link:https://github.com/aws/aws-cla[Contributor License Agreement (CLA)].
 
-* For anything but very small or quick changes, you should always start by checking the link:https://github.com/aws-samples/aws-workshop-for-kubernetes/issues[Issues] page to see if the work is already being done by another person.
+* You should always start by checking the link:https://github.com/aws-samples/aws-workshop-for-kubernetes/issues[Issues] page to see if the work is already being done by another person. We require that pull requests reference an issue.
 
 [NOTE]
-If you're working on a bug fix, check to see if the bug has already been reported. If it has but no one is assigned to it, ask one of the maintainers to assign it to you before beginning work.  If you're confident the bug hasn't been reported yet, create a new link:#bug-reports[Bug Report] then ask to be assigned to it.
+If you're working on a bug fix, check to see if the bug has already been reported. If it has but no one is assigned to it, comment that you are assigning it to yourself before beginning work.  If you're confident the bug hasn't been reported yet, create a new link:#bug-reports[Bug Report] then comment that you are assigning it to yourself.
 
 [NOTE]
 If you are thinking about adding entirely new functionality, open an link:#enhancements[Enhancements] or link:https://gitter.im/aws-samples/aws-workshop-for-kubernetes[ping] the maintainers to ask for feedback first before beginning work; again this is to make sure that no one else is already working on it, and also that it makes sense to be included in the workshop.
@@ -76,7 +76,7 @@ Before submitting your pull request, refer to the pull request readiness checkli
 * [ ] Includes tests to exercise the new behavior
 * [ ] Code is documented, especially public and user-facing constructs
 * [ ] Git commit message is detailed and includes context behind the change
-* [ ] If the change is related to an existing Bug Report or Enhancement, the issue number is referenced
+* [ ] The issue number for the bug report or enhancement is referenced
 
 [NOTE]
 Some changes have additional requirements. Refer to the section below to see if your change will require additional work to be accepted.
@@ -87,4 +87,7 @@ All Pull Requests must be reviewed and approved by at least two other contributo
 If your branch has more than one commit when it's approved, you may also be asked to link:https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History[squash] them into a single commit before it is merged in.
 
 == Getting in Contact
-* Come chat with us on link:https://gitter.im/aws-samples/aws-workshop-for-kubernetes[Gitter]!
+Come chat with us on:
+* link:https://gitter.im/aws-samples/aws-workshop-for-kubernetes[Gitter]!
+* **#eks** channel in **Kubernetes** Slack workspace
+* **#containers** and **#kubernetes** channels in **aws-developers** Slack workspace