Merge pull request creativecommons#193 from creativecommons/update_contrib_guidelines

Updated contribution and PR guidelines; removed issue assignment step.

Author: kgodey

content/contributing-code/contents.lr

@@ -16,11 +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.
-* 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, issues with this tag can be reassigned to someone else.
-* 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.
-* 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.
+* **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)
@@ -32,17 +37,20 @@ Some helpful saved searches on GitHub than can assist with finding an issue:
 
 Once you've found an issue you'd like to work on, please follow these steps to make your contribution:
 
-1. Comment on it and say you'd like to work on that issue.
-2. Wait for someone (usually a CC staff member or project maintainer) to confirm that you may work on the issue before writing any code. The person who confirms will assign the issue to you add an "in progress" label to the issue to indicate that the issue is being worked on.
-3. Once the issue has been updated to "in progress", write your code and submit your pull request. Be sure to read and follow our **[pull request guidelines](/contributing-code/pr-guidelines)**!
-4. Wait for code review and address any issues raised as soon as you can.
+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)**!
+3. Wait for code review and address any issues raised as soon as you can.
 
-Even if you're not done with the issue, 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/). If we haven't heard from you in over a week and someone else expresses interest in that issue, we will reassign the issue to the new person.
+**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.
 
 ## Proposing a new issue
 
-If you want to work on something that there is no GitHub issue for, then create a a new GitHub issue associated with the relevant repository and propose your change there. Be sure to include implementation details and the rationale for the proposed change.
+If you want to work on something that there is no GitHub issue for, follow these steps:
 
-If the project has a roadmap documented in the README, checking the roadmap to see if the feature is already in our pipeline would be a good first step.
+1. Create a a new GitHub issue associated with the relevant repository and propose your change there. Be sure to include implementation details and the rationale for the proposed change.
+    * We are very reluctant to accept random pull requests without a related issue created first.
+2. The issue will automatically have the `not ready for work` label applied. Wait for a project maintainer to evaluate your issue and decide whether it's something that we will accept a pull request for.
+3. Once the project maintainer has approved the issue and removed the `not ready for work` label, you may start work on code as described in the "Contribution process" section above.
 
 When in doubt, ask a question on [one of our community forums](/community).

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

@@ -8,12 +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.
 
-* 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