Merge pull request #3402 from juliannatetreault/patch-1

Update CONTRIBUTING.md [ci skip]

CONTRIBUTING.md

@@ -2,8 +2,8 @@
 
 When filing an issue on the Solidus project, please provide these details:
 
-* A comprehensive list of steps to reproduce the issue.
-* What you're *expecting* to happen compared with what's *actually* happening.
+* A comprehensive list of steps to reproduce the issue
+* What you're *expecting* to happen compared with what's *actually* happening
 * Your application's complete `Gemfile`, and `Gemfile.lock` as text in a [Gist](https://gist.github.com) (*not as an image*)
 * Any relevant stack traces ("Full trace" preferred)
 
@@ -17,12 +17,12 @@ Any issue that is open for 14 days without actionable information or activity
 will be marked as "stalled" and then closed. Stalled issues can be re-opened if
 the information requested is provided.
 
-## Pull requests
+## Opening pull requests
 
 We gladly accept pull requests to add documentation, fix bugs and, in some circumstances,
 add new features to Solidus.
 
-Here's a quick guide:
+Here's a quick guide to opening a PR:
 
 1. Fork the repo.
 
@@ -39,8 +39,8 @@ functionality or fixing a bug, we need tests!
 to the latest stable branches and master branch, you will only need to submit one
 pull request.
 
-5. If a PR does not apply cleanly to one of its targeted branches, then a separate
-PR should be created that does. For instance, if a PR applied to master & 2-1-stable but not 2-0-stable, then there should be one PR for master & 2-1-stable and another, separate PR for 2-0-stable.
+5. If a PR does not apply cleanly to all of its targeted branches - for example,
+slighty different fixes for mulitple versions -  then multiple PRs are necessary.
 
 At this point you're waiting on us. We like to at least comment on, if not
 accept, pull requests within three business days (and, typically, one business
@@ -56,19 +56,19 @@ Though in some cases the Core Team may choose not to merge a PR that meets these
 
 ### Pull Request guidelines
 
-* The specs must pass for each individual commit.
-* Each individual commit should make sense by itself as far as possible.
-* Breaking up a large change into smaller (coherent) commits is encouraged.
+* The specs must pass for each individual commit
+* Each individual commit should make sense by itself as far as possible
+* Breaking up a large change into smaller (coherent) commits is encouraged
 * We do not currently have a policy about whether or not to force-push while
-people are reviewing your pull request.
+people are reviewing your pull request
 * Good commit messages are also encouraged. Here are some resources on writing
 good commit messages:
   * [Notes from Linus](https://github.com/torvalds/subsurface/commit/b6590150d68df528efd40c889ba6eea476b39873)
   * [Erlang's guide](https://github.com/erlang/otp/wiki/Writing-good-commit-messages)
   * [An often-cited post](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
 
 Some things that will increase the chance that your pull request is accepted,
-taken straight from the Ruby on Rails guide:
+taken straight from the [Ruby on Rails guide](http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html):
 
 * Use Rails idioms and helpers
 * Include tests that fail without your code, and pass with it