Merge pull request #323 from open-guides/contributing-update

Update contribution overview

CONTRIBUTING.md

@@ -8,17 +8,17 @@ Contributions of all kinds, including discussion, corrections, additions, and im
 Please Help
 -----------
 
-If you’ve found this guide useful, please join us:
+If you’ve found this guide useful, please see if you can help (in increasing levels of commitment and expertise):
 
--	The simplest thing you can do to contribute is [**join the Slack channel**](https://og-aws.slack.lexikon.io/) and **ask or answer questions** or **discuss**, which
+-	**Discussion:** The easiest thing you can do to contribute is [**join the Slack channel**](https://og-aws.slack.lexikon.io/) and ask or answer questions. As we discuss, see if it points to new things you or others can contribute to the Guide.
 helps the community and guides what contributors can focus on.
--	[**File issues**](https://github.com/open-guides/og-aws/issues) if it’s clear something needs to be improved and you’re not able to make a pull request.
--	[**Pull requests**](https://github.com/open-guides/og-aws/pulls) with changes are always welcome. Please keep them small and focused, so we can add items individually, and review the conventions below. If you want to make a larger change, try to discuss it in Slack.
--	**Review** or **comment** on existing issues and pull requests if you have expertise.
--	If you have deep expertise, we may ask you to be an **editor** or **expert**. Editors and experts are assigned roles that [help us review](#editorial-process) the Guide. Join Slack to discuss this.
+-	**Focused pull requests:** [Pull requests](https://github.com/open-guides/og-aws/pulls) with focused changes like typos, specific tips, and corrections are always welcome and fast to review and merge in. Keep them small and focused, and *use multiple PRs for unrelated changes*. (See [writing conventions](#writing-conventions) below.)
+-	**Track issues:** [File issues](https://github.com/open-guides/og-aws/issues) to aggregate ideas or links if it’s clear something needs to be improved, but it’s not possible to file a PR immediately.
+-	**Major pull requests:** Take a look at areas [where we need help](https://github.com/open-guides/og-aws/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). If you want to make a larger change, such as rewriting a lot of content, changing style, or adding a section, discussion in Slack is helpful and usually necessary. For new additions, we often create and edit the first draft in [Quip](https://quip.com/).
+-	**Deeper expertise:** If you have deep expertise, let one of the project leads know if you’re interested in being an **editor** or an **expert**. Editors and experts are assigned roles that [help us review](#editorial-process) the Guide.
 
-Making Contributions
---------------------
+Review Process
+--------------
 
 ### Pull Request Etiquette
 
@@ -49,7 +49,7 @@ When creating a PR or reviewing one, it’s helpful to consider a few questions:
 -	Roles:
 	-	**Project leads:** Own overall quality of the Guide, direction, and process.
 	-	**Editors:** Contributors own specific sections or aspects of the Guide, reviewing PRs and/or writing. Requires expert knowledge.
-	-	**Experts:** People with expert knowledge in various areas, who have agreed to review or help on demand with tougher questions or PRs.
+	-	**Experts:** People with expert knowledge in various areas, who assist editors and have agreed to review or help on demand with tougher questions or PRs.
 	-	**Contributors:** Everyone who contributes content or helps one way or another.
 -	All PRs are reviewed by an **editor** and for non-trivial changes, a **project lead**, usually in that order, but it can be reversed for expediency.
 -	In addition, anyone with relevant knowledge is encouraged to review/comment on PRs.
@@ -59,7 +59,7 @@ When creating a PR or reviewing one, it’s helpful to consider a few questions:
 Writing Conventions
 -------------------
 
-When you contribute, keep in mind these conventions:
+To keep a polished, consistent style we list a bunch of our conventions. Try to follow these and/or enforce them in reviews:
 
 -	**Abbreviations:** For AWS service names, we use the abbreviation throughout the guide if it is more common, e.g. EC2 and not Elastic Compute Cloud. We also omit “Amazon” at the front of product names, e.g. EMR and not Amazon EMR. If an abbreviation is convenient but not always used, e.g. AZ instead of Availability Zone, either use the full term once per section/paragraph and abbreviate subsequent usages or do not abbreviate it at all.
 -	Terms that appear for the first time in **boldface** are defined there in a brief summary, with a link if possible to what is probably the best page for that concept. It’s also fine to boldface **key statements** that guide the eye.
@@ -80,7 +80,7 @@ When you contribute, keep in mind these conventions:
 	-	Not all sections need to follow the above conventions exactly.
 	-	Note we try to make sections uniquely titled, so GitHub links to Markdown section anchors don’t collide and are stable.
 
-Note we keep consistent formatting in Markdown via [markdownfmt](https://github.com/shurcooL/markdownfmt). We run **admin/reformat.sh** to do this, but you don’t have to worry about it unless you really want to.
+Occasionally, we keep consistent formatting in Markdown via [markdownfmt](https://github.com/shurcooL/markdownfmt). (One of the project leads might run **admin/reformat.sh** to do this, but you can safely ignore that.)
 
 Contact
 -------