Update contributing.md

Closes #3916

Author: russcam

contributing.md

@@ -2,13 +2,15 @@
 
 Contributing back to `Elasticsearch.Net` and `NEST` is very much appreciated. 
 Whether you [feel the need to change one character](https://github.com/elasticsearch/elasticsearch-net/pull/536) or have a go at 
-[mapping new API's](http://github.com/elasticsearch/elasticsearch-net/pull/376) no PR is too small or too big. 
+[mapping new APIs](http://github.com/elasticsearch/elasticsearch-net/pull/376), no pull request (PR) is too small or too big. 
 
-In fact many of our most awesome features/fixes have been provided to us by [these wonderful folks](https://github.com/elasticsearch/elasticsearch-net/graphs/contributors) to which we are forever indebted 
+In fact many of our most awesome features/fixes have been provided to us by [these wonderful folks](https://github.com/elasticsearch/elasticsearch-net/graphs/contributors) to which we are forever indebted.
+
+It's usually best to open an issue first to discuss a feature or bug, before opening a pull request. Doing so can save time and help further ascertain the crux of an issue.
 
 ## Sign the CLA
 
-We do ask that you sign the [Elasticsearch CLA](http://www.elasticsearch.org/contributor-agreement/) before we can accept pull requests from you. 
+We do ask that you sign the [Elasticsearch CLA](https://www.elastic.co/contributor-agreement/) before we can accept pull requests from you. 
 
 ## Coding Styleguide
 
@@ -20,13 +22,14 @@ In most cases we won't shun a PR just because it uses the wrong indentation sett
 
 ## Tests
 
-PR's with tests are more likely to be reviewed faster because it makes the job or reviewing the PR much easier. That being said,
-we respect that you are fixing a bug in your own time and might not have the time/energy to submit a PR with complete tests. 
-In those cases we tend to pull your bits locally and write tests ourselves, but this may mean your PR might sit idle longer than you would like.
+PRs with tests are more likely to be reviewed faster because it makes the job or reviewing the PR much easier. That being said,
+we respect that you may be fixing a bug in your own time and might not have the time/energy to submit a PR with complete tests. 
+In those cases, we tend to pull your bits locally and write tests ourselves, but this may mean your PR might sit idle longer than you would like.
 
 ## Branches
 
-- `master` for the latest client (currently _7.x alpha_)
+- `master` for the latest client (currently _7.x_)
+- `7.x` for 7.x compatible client
 - `6.x` for 6.x compatible client
 - `5.x` for 5.x compatible client
 - `2.x` for 2.x compatible client (no longer maintained)
@@ -47,13 +50,9 @@ Please submit your [Pull Requests](https://help.github.com/articles/creating-a-p
 
 The solution uses a number of awesome Open Source software tools to ease development:
 
-## Paket
-
-[Paket](https://fsprojects.github.io/Paket/) is the dependency manager of choice for handling dependencies of both the solution and the build automation system. It works for both .NET and Mono, with an ability to reference packages from Nuget and also files directly from github.
+## Bullseye
 
-## FAKE
-
-[FAKE (F# MAKE)](http://fsharp.github.io/FAKE/) is used as the build automation system for the solution. To get started after cloning the solution, it's best to run the build script in the root
+[Bullseye](https://github.com/adamralph/bullseye) is used as the build automation system for the solution. To get started after cloning the solution, it's best to run the build script in the root
 
 for Windows 
 
@@ -69,7 +68,7 @@ build.sh
 
 This will
 
-- Pull down all the paket dependencies for the build process as well as the solution
+- Pull down all the dependencies for the build process as well as the solution
 - Run the default build target for the solution
 
 You can also compile the solution within Visual Studio if you prefer, but the build script is going to be _much_ faster.
@@ -82,11 +81,11 @@ The `Tests` project contains both xunit unit and integration tests. A `tests.yam
 - `i` for integration tests
 - `m` for mixed mode i.e. unit and integration tests
 
-The build script has a number of different build targets to run different types of tests, see the [`Targets.fsx` script in the `scripts` project](https://github.com/elastic/elasticsearch-net/blob/master/build/scripts/Targets.fsx) for the complete list, but the main ones are:
+The build script has a number of different build targets to run different types of tests, see the [`Targets.fs` file in the `scripts` project](https://github.com/elastic/elasticsearch-net/blob/master/build/scripts/Targets.fs) for the complete list, but the main ones are:
 
 ### Compile and run unit tests
 
-```bash
+```bat
 build.bat
 ```
 with no target will run the `Build` target, compiling the solution and running unit tests
@@ -117,15 +116,3 @@ You may come across an exception similar to below when running the build script
 The `1.x` and `master` branches have diverged dramatically as a result of changes in preparation for 2.0. This includes changes to the build process such that switching between the `master` and `1.x` branches and back again can change the versions of packages used within the build processes. To rectify this issue, try deleting the `packages` folder within the root of the solution and run the build script again.
 
 If working on both 1.x and 2.x and 5.x versions of NEST, it is recommended to clone the git repository for each version into separate directories to avoid the need to switch between the divergent branches.
-
-### System.Exception: Attempting to run with dotnet.exe with 1.0.x but global.json mandates 1.0.1
-
-When running the `build` script, you may encounter a mismatch with your version of the .NET Core runtime. Ensure your version of .NET Core exactly matches the version specified under `sdk` in the `global.json` file.
-
-```json
-{
-  "sdk": {
-    "version": "1.0.1"
-  }
-}
-```