Merge branch 'release/2.0.2'

CONTRIBUTING.md

@@ -46,7 +46,7 @@ git config user.email "username@domain.suffix"
 
 #### Hotfixes and Support branches
 
-It's basically the same process but use the word `hotfix` or `support` instead of `feature`.  `git flow` knows what to do. Just keep in mind that any changes are going to happen to your fork, and not the upstream repo. If you need to merge a `hotfix` into upstream master you may only do it va a reviewed pull request.
+It's basically the same process but use the word `hotfix` or `support` instead of `feature`. `git flow` knows what to do. Just keep in mind that any changes are going to happen to your fork, and not the upstream repo. If you need to merge a `hotfix` into upstream master you may only do it va a reviewed pull request.
 
 ### Releasing to production
 
@@ -56,7 +56,7 @@ It's basically the same process but use the word `hotfix` or `support` instead o
 4. Now go back to GitHub and raise a Pull Request to merge the upstream master from your fork's `master` branch. When that goes through you are done.
 5. In your command-line go back and clean up any outstanding branches and `git pull upstream` your local `master` and `develop` branches to ensure everything on your local machine is up to date with everyone's changes.
 
-Note you will **never** push changes directly to the upstream project, *only to your own fork*.
+Note you will **never** push changes directly to the upstream project, _only to your own fork_.
 
 **Changes may only be introduced into the upstream project via a properly reviewed pull request.**
 
@@ -72,27 +72,27 @@ Note this will creating a feature via `git flow` will create a branch called `fe
 
 ### Commit Messages
 
-When commiting something use the `-m` flag to add a short commit message of the format `{issue number} summary of what you changed`.  So for example if you are working on issue `ABC-1` and you added a method to the `aardvark_controller` you might use the following commit message `"ABC-1 added anteater method to aardvark controller"`
+When commiting something use the `-m` flag to add a short commit message of the format `{issue number} summary of what you changed`. So for example if you are working on issue `ABC-1` and you added a method to the `aardvark_controller` you might use the following commit message `"ABC-1 added anteater method to aardvark controller"`
 
 Commit messages ought to be in the past tense.
 
 In general try to group file changes wherever appropriate, so if your controller change also involved updating something in a helper file, the one commit message can happily encompas the changes to both files. The message ought to reflect the main aim of the change.
 
 ### Pull Requests
 
-Pull requests must be named as follows `[issue type, issue number] high level description of change`.  The following Issue Types are recognised
+Pull requests must be named as follows `[issue type, issue number] high level description of change`. The following Issue Types are recognised
 
-* `Bug Fix` - the change fixes a bug
-* `Feature` - the change adds a new feature (the usual issue type)
-* `Documentation` — The change is a documentation only change
-* `Optimisation` - The change is an optimisation of the code base without any functional changes
+- `Bug Fix` - the change fixes a bug
+- `Feature` - the change adds a new feature (the usual issue type)
+- `Documentation` — The change is a documentation only change
+- `Optimisation` - The change is an optimisation of the code base without any functional changes
 
 If your change does not fit any of these categories, use `Feature`. Likewise if your change is not tied to an issue number you may use `n/a` instead.
 
 So to use the above example your Pull Request would be named `[Feature, ABC-1] added anteater to aardvark`
 
 ### You built it, you merge it
 
-A developer must be responsible for their own work, from accepting a task through to merging to production.  With that in mind if you review another developer's PR, please don't then merge it yourself.  As a general rule you must let the developer merge her own PRs.
+A developer must be responsible for their own work, from accepting a task through to merging to production. With that in mind if you review another developer's PR, please don't then merge it yourself. As a general rule you must let the developer merge her own PRs.
 
-Likewise, don't expect someone else to merge your PR.  Unless you do not have write permission on a project, you will always aim to take personal responsibility for the quality of the code that gets merged in.
+Likewise, don't expect someone else to merge your PR. Unless you do not have write permission on a project, you will always aim to take personal responsibility for the quality of the code that gets merged in.