docs: update CONTRIBUTING.md (#3045)

CONTRIBUTING.md

@@ -10,18 +10,24 @@ Following these guidelines helps to communicate that you respect the time of the
 
 - There are hooks to add your own features, so we should not add less-common features.
 - The workflow should be to start webpack-dev-server as a separate process, next to the "normal" server and to request the script from this server or to proxy from dev-server to "normal" server (because webpack blocks the event queue too much while compiling which can affect "normal" server).
-- A user should not try to implement stuff that accesses the webpack filesystem. This lead to bugs (the middleware does it while blocking requests until the compilation has finished, the blocking is important).
+- A user should not try to implement stuff that accesses the webpack filesystem. This leads to bugs (the middleware does it while blocking requests until the compilation has finished, the blocking is important).
 - It should be a development only tool. Compiling in production is bad, one should precompile and deliver the compiled assets.
 - Processing options and stats display is delegated to webpack, so webpack-dev-server/middleware should not do much with it. This also helps us to keep up-to-date with webpack updates.
 - The communication library (`SockJS`) should not be exposed to the user.
 
 ## Submitting a Pull Request
 
-Good pull requests, such as patches, improvements, and new features, are a fantastic help. They should remain focused in scope and not contain unrelated commits.
+- Good pull requests, such as patches, improvements, and new features, are a fantastic help. They should remain focused in scope and not contain unrelated commits.
 
-It is advised to first create an issue (if there is not one already) before making a pull request. This way the maintainers can first discuss with you if they agree and it also helps with providing some context.
+- It is advised to first create an issue (if there is not one already) before making a pull request. This way the maintainers can first discuss with you if they agree and it also helps with providing some context.
 
-Run the relevant [examples](https://github.com/webpack/webpack-dev-server/tree/master/examples) to see if all functionality still works. When introducing new functionality, also add an example. This helps the maintainers to understand it and check if it still works.
+- Run the relevant [examples](https://github.com/webpack/webpack-dev-server/tree/master/examples) to see if all functionality still works. When introducing new functionality, also add an example. This helps the maintainers to understand it and check if it still works.
+
+- Write tests.
+
+- Follow the existing coding style.
+
+- Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. ([More info](https://github.com/blog/1506-closing-issues-via-pull-requests))
 
 ## Setting Up a Local Copy
 
@@ -31,7 +37,7 @@ Run the relevant [examples](https://github.com/webpack/webpack-dev-server/tree/m
 
 3. Run `npm link && npm link webpack-dev-server` to link the current project to `node_modules`.
 
-Once it is done, you can modify any file locally. In the `examples/` directory you'll find a lot of examples with instructions on how to run it. This can be very handy when testing if your code works.
+Once it is done, you can modify any file locally. In the `examples/` directory you'll find a lot of examples with instructions on how to run them. This can be very handy when testing if your code works.
 
 If you are modifying a file in the `client/` directory, be sure to run `npm run build:client` after it. This will recompile the files.