Contributor guide update (nci#787)

* Update contributor guide to include more information on forking and branch management

docs/contributing.md

@@ -25,15 +25,23 @@ Please submit bug reports, feature requests and feedback as issues in GitHub: [h
 
 Please see the information provided in [SECURITY.md](SECURITY.md)
 
+## Creating Your Own Fork  of `scores` for the First Time
+
+Unless you are an advanced Git user, we would recommend you follow this process:
+
+1. First (i.e. **before** cloning the `scores` repository) create your own fork using the GitHub web user interface.
+2. Clone **your fork**. (Do not clone github.com/nci/scores).
+3. Immediately create a new local branch, with a command such as `git checkout -b branch_name`.
+
 ## Workflow for Submitting Pull Requests
 
 Prior to developing a pull request, it may be a good idea to create a [GitHub issue](https://github.com/nci/scores/issues) to capture what the pull request is trying to achieve, any pertinent details, and (if applicable) how it aligns to the roadmap. Otherwise, please explain this in the pull request.
 
 To submit a pull request, please use the following workflow: 
-1. create a fork of the `scores` repository, 
-2. create a feature branch on your fork,
-3. keep your feature branch rebased and up-to-date with the `scores` develop branch,
-4. when ready, submit a pull request to the develop branch of `scores`.
+
+1. Ensure you are working on a new feature branch in **your fork** (see [the section above](#creating-your-own-fork-of-scores-for-the-first-time)).
+2. Keep your feature branch rebased and up-to-date with the develop branch of `scores`. You can do this by first syncing the develop branch on your fork, and then rebase your feature branch against the develop branch on your fork.
+3. When ready, submit a pull request to the develop branch of github.com/nci/scores.
 
 To help disambiguate branches, some contributors like to prefix their branch names with a short numerical indentifier. This is up to the contributor and any approach to branch naming is welcome. 
 
@@ -110,6 +118,18 @@ To automate linter and fixer checks this project uses `pre-commit` which is set
 pre-commit install -t pre-commit -t pre-push
 ```
 
+## Pull Request Etiquette
+
+In general, the originator of a pull request will be the person who does all the coding work, including responding to feedback from others. Typically, feedback will be provided in the form of comments or code suggestions made through the GitHub web user interface.
+
+Sometimes, it may be pragmatic for the package maintainers to make or request a more complex code change. This typically occurs when a complex Git operation is needed to keep a pull request (PR) up to date, to resolve conflicts, or to make changes where the originator of the PR does not know how to proceed. It can also occur in the final stages of a PR lifecycle if there are small tidyups needed and time is a factor.
+
+Not every possibility can be accounted for, and the package maintainers will (if needed) push code directly to a PR to get something over the line. However, special circumstances aside, the maintainers will first leave a comment on the PR asking how the originator would like to proceed, so that there are no surprises.
+
+Most of these kinds of code change can also be handled as a PR by the reviewer onto the fork of the originator. This is slightly slower (i.e. does not take effect immediately), but allows for more control by the originator. This is probably most developer's general preference.
+
+In short - once you have made a PR, the maintainers may then take it, modify it, or include it as-is. However, every effort will be made to communicate about that process and make sure that the originator of the PR is happy with any modifications made.
+
 ## Review Processes
 
 All pull requests will undergo a review process prior to being included in the develop branch in order to ensure both the coding and the scientific validity of changes.