Updated contribution and PR guidelines based on feedback.

Author: kgodey

content/contributing-code/contents.lr

@@ -16,13 +16,16 @@ Here's a list of [all our current projects](/projects). We use GitHub issues ass
 
 We make extensive use of issue labels to desginate the status of various issues. We have a standard set of labels across all projects, [documented here](https://github.com/creativecommons/ccos-scripts/blob/master/normalize_repos/labels.py). Here are some of the ones that are most relevant to finding a good issue to work on:
 
-* Issues tagged `help wanted` and/or `good first issue` are available for community contribution. You may work on an issue labeled `good first issue` even if it's not your first issue.
-    * Check the issue comments to see whether someone else has indicated that they are working on it. If there hasn't been any issue or PR activity for at least 7 days, then that issue can be considered up for grabs.
-* Issues tagged `in progress` are being worked on by someone else.
-    * If there hasn't been any issue or PR activity for at least 7 days, then that issue can be considered up for grabs.
-* Issues tagged `blocked`, `not ready for work` or `ticket work required` are not yet ready for work. They need something else to be done first before they are ready. Do not work on these issues.
-* Issues tagged `CC staff only` are not suitable for community contribution, usually because it requires infrastructure access or institutional knowledge that would be impractical to provide to the community. Do not work on these issues.
-* Issues without any of the above labels _may_ be open for contribution. Please add a comment to ask whether the issue is available.
+* **Issues tagged `help wanted` or `good first issue`** are available for community contribution**
+    * These issues are available for community contribution and you do not need our permission to work on one of these.
+    * You may work on an issue labeled `good first issue` even if it's not your first issue.
+    * Check the issue comments/labels to see whether someone else has indicated that they are working on it. If someone is already working on it and there has been activity within the last 7 days, you may want to find a different issue to work on.
+* **Issues tagged with one of these labels: `blocked`, `not ready for work`, `ticket work required`, `CC staff only` are not available to the community. Do not work on these.**
+    * Issues tagged `blocked` are blocked by other work that needs to be done first.
+    * Issues tagged `not ready for work` or `ticket work required` need additional work done on the issue before they can be opened to community contributors.
+    * Issues tagged `CC staff only` are not suitable for community contribution, usually because it requires infrastructure access or institutional knowledge that would be impractical to provide to the community.
+* **Issues without any of the above labels _may_ be open for contribution.**
+    * Please add a comment to ask whether the issue is available before starting work.
 
 Some helpful saved searches on GitHub than can assist with finding an issue:
 - [issues labeled "good first issue"](https://github.com/search?q=org%3Acreativecommons+is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
@@ -37,7 +40,6 @@ Once you've found an issue you'd like to work on, please follow these steps to m
 1. Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
     * A project maintainer may mark the issue with an `in progress` label at this point, but we don't always get around to that.
 2. Write your code and submit your pull request. Be sure to read and follow our **[pull request guidelines](/contributing-code/pr-guidelines)**!
-    * Please link to your branch or PR in the issue as soon as you push it, even if it's only an early draft.
 3. Wait for code review and address any issues raised as soon as you can.
 
 **A note on collaboration:** We encourage people to collaborate as much as possible. We especially appreciate contributors reviewing each others pull requests, as long as you are [kind and constructive](https://medium.com/@otarutunde/comments-during-code-reviews-2cb7791e1ac7) when you do so.

content/contributing-code/pr-guidelines/contents.lr

@@ -8,13 +8,20 @@ body:
 
 We ask that contributors to CC projects submit a pull request with your changes. If you're not familiar with pull requests, please read [this GitHub documentation](https://help.github.com/en/articles/about-pull-requests). Here are our expectations for pull requests; following them will expedite the process of merging your code in.
 
-* **Please create a separate branch for each issue that you're working on. Do not make changes to the `master` branch of your fork.**
-* Even if you're not done with the issue you're working on, create a [draft pull request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests) and push your code [early and often](https://www.worklytics.co/blog/commit-early-push-often/).
 * Read and follow the contributing guidelines and code of conduct for the project. Here are screenshots of where to find them for [first time contributors](first-time-contributor-resources.png) and [previous contributors](previous-contributor-resources.png).
-* Use the format specified in pull request template for the repository.
-* Describe your change in detail. Too much detail is better than too little.
-* Describe how you tested your change.
-* If a reviewer is not assigned automatically, manually [request a review](https://help.github.com/en/articles/requesting-a-pull-request-review) from either the repository maintainer (if you have that information) or `@creativecommons/engineering`.
+* **Make a Branch**
+    * Please create a separate branch for each issue that you're working on. Do not make changes to the default branch (e.g. `master`, `develop`) of your fork.
+* **Push your code ASAP** 
+    * Push your code as soon as you can. Follow the "[early and often](https://www.worklytics.co/blog/commit-early-push-often/)" rule. 
+    * Make a pull request as soon as you can and mark the title with a "[WIP]". You can create a [draft pull request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests).
+* **Describe Your Pull Request**
+    * Use the format specified in pull request template for the repository.
+    * Describe your change in detail. Too much detail is better than too little.
+    * Describe how you tested your change.
+* **Request Review**
+    * Once your PR is ready, remove the "[WIP]" from the title and/or change it from a draft PR to a regular PR.
+    * If a specific reviewer is not assigned automatically, please [request a review](https://help.github.com/en/articles/requesting-a-pull-request-review) from the project maintainer and any other interested parties manually.
+    * Be sure to **re-request review** once you have made changes after a code review.
 
 ## Code guidelines