Update documentation

.github/CONTRIBUTING.md

@@ -1,10 +1,10 @@
 # Contributing
 
-### Building
+## Building
 
 You need either [Docker](https://github.com/docker/docker) and `make` (Method 1), or `go` (Method 2) in order to build traefik. For changes to its dependencies, the `glide` dependency management tool and `glide-vc` plugin are required.
 
-#### Method 1: Using `Docker` and `Makefile`
+### Method 1: Using `Docker` and `Makefile`
 
 You need to run the `binary` target. This will create binaries for Linux platform in the `dist` folder.
 
@@ -26,9 +26,9 @@ $ ls dist/
 traefik*
 ```
 
-#### Method 2: Using `go`
+### Method 2: Using `go`
 
-###### Setting up your `go` environment
+##### Setting up your `go` environment
 
 - You need `go` v1.8+
 - It is recommended you clone Træfik into a directory like `~/go/src/github.com/containous/traefik` (This is the official golang workspace hierarchy, and will allow dependencies to resolve properly)
@@ -55,7 +55,7 @@ GORACE=""
 ## more go env's will be listed 
 ```
 
-###### Build Træfik
+##### Build Træfik
 
 Once your environment is set up and the Træfik repository cloned you can build Træfik. You need get `go-bindata` once to be able to use `go generate` command as part of the build.  The steps to build are:
 
@@ -75,7 +75,7 @@ go build ./cmd/traefik
 
 You will find the Træfik executable in the `~/go/src/github.com/containous/traefik` folder as `traefik`. 
 
-#### Setting up `glide` and `glide-vc` for dependency management
+### Setting up `glide` and `glide-vc` for dependency management
 
 - Glide is not required for building; however, it is necessary to modify dependencies (i.e., add, update, or remove third-party packages)
 - Glide can be installed either via homebrew: `$ brew install glide` or via the official glide script: `$ curl https://glide.sh/get | sh`
@@ -99,7 +99,7 @@ $ go build ./cmd/traefik
 
 ### Tests
 
-##### Method 1: `Docker` and `make`
+#### Method 1: `Docker` and `make`
 
 You can run unit tests using the `test-unit` target and the
 integration test using the `test-integration` target.
@@ -136,14 +136,14 @@ TESTFLAGS="-check.f MyTestSuite.*Test" make test-integration
 
 More: https://labix.org/gocheck
 
-##### Method 2: `go`
+#### Method 2: `go`
 
 - Tests can be run from the cloned directory, by `$ go test ./...` which should return `ok` similar to:
 ```
 ok      _/home/vincent/src/github/vdemeester/traefik    0.004s
 ```
 
-### Documentation
+## Documentation
 
 The [documentation site](http://docs.traefik.io/) is built with [mkdocs](http://mkdocs.org/)
 
@@ -173,3 +173,54 @@ INFO    -  Cleaning site directory
 [I 160505 22:31:24 handlers:59] Start watching changes
 [I 160505 22:31:24 handlers:61] Start detecting changes
 ```
+
+
+## How to Write a Good Issue
+
+Please keep in mind that the GitHub issue tracker is not intended as a general support forum, but for reporting bugs and feature requests.
+
+For end-user related support questions, refer to one of the following:
+- the Traefik community Slack channel: [![Join the chat at https://traefik.herokuapp.com](https://img.shields.io/badge/style-register-green.svg?style=social&label=Slack)](https://traefik.herokuapp.com) 
+- [Stack Overflow](https://stackoverflow.com/questions/tagged/traefik) (using the `traefik` tag)
+
+### Title
+
+The title must be short and descriptive. (~60 characters)
+
+### Description
+
+- Respect the issue template as more as possible. [template](ISSUE_TEMPLATE.md)
+- If it's possible use the command `traefik bug`. See https://www.youtube.com/watch?v=Lyz62L8m93I. 
+- Explain the conditions which led you to write this issue: the context.
+- The context should lead to something, an idea or a problem that you’re facing.
+- Remain clear and concise.
+- Format your messages to help the reader focus on what matters and understand the structure of your message, use [Markdown syntax](https://help.github.com/articles/github-flavored-markdown)
+
+
+## How to Write a Good Pull Request
+
+### Title
+
+The title must be short and descriptive. (~60 characters)
+
+### Description
+
+- Respect the pull request template as more as possible. [template](PULL_REQUEST_TEMPLATE.md)
+- Explain the conditions which led you to write this PR: the context.
+- The context should lead to something, an idea or a problem that you’re facing.
+- Remain clear and concise.
+- Format your messages to help the reader focus on what matters and understand the structure of your message, use [Markdown syntax](https://help.github.com/articles/github-flavored-markdown)
+
+### Content
+
+- Make it small.
+- Do only one thing.
+- Write useful descriptions and titles.
+- Avoid re-formatting.
+- Make sure the code builds.
+- Make sure all tests pass.
+- Add tests.
+- Address review comments in terms of additional commits.
+- Do not amend/squash existing ones unless the PR is trivial.
+
+Read [10 tips for better pull requests](http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/).

.github/MAINTAINER.md

@@ -1,5 +1,17 @@
 # Maintainers
 
+## The team
+
+- Emile Vauge [@emilevauge](https://github.com/emilevauge)
+- Vincent Demeester [@vdemeester](https://github.com/vdemeester)
+- Ed Robinson [@errm](https://github.com/errm)
+- Daniel Tomcej [@dtomcej](https://github.com/dtomcej)
+- Manuel Zapf [@SantoDE](https://github.com/SantoDE)
+- Timo Reimann [@timoreimann](https://github.com/timoreimann)
+- Ludovic Fernandez [@ldez](https://github.com/ldez)
+- Julien Salleyron [@juliens](https://github.com/juliens)
+- Nicolas Mengin [@nmengin](https://github.com/nmengin)
+
 ## Labels
 
 If we open/look an issue/PR, we must add a `kind/*` and an `area/*`.
@@ -7,6 +19,7 @@ If we open/look an issue/PR, we must add a `kind/*` and an `area/*`.
 ### Contributor
 
 * `contributor/need-more-information`: we need more information from the contributor in order to analyze a problem.
+* `contributor/waiting-for-feedback`: we need the contributor to give us feedback.
 * `contributor/waiting-for-corrections`: we need the contributor to take actions in order to move forward with a PR. **(only for PR)**
 * `contributor/needs-resolve-conflicts`: use it only when there is some conflicts (and an automatic rebase is not possible). **(only for PR)** _[bot, humans]_
 
@@ -34,6 +47,17 @@ If we open/look an issue/PR, we must add a `kind/*` and an `area/*`.
 
 ### Area
 
+* `area/acme`: ACME related.
+* `area/api`: Traefik API related.
+* `area/authentication`: Authentication related.
+* `area/cluster`: Traefik clustering related.
+* `area/documentation`: regards improving/adding documentation.
+* `area/infrastructure`: related to CI or Traefik building scripts.
+* `area/healthcheck`: Health-check related.
+* `area/logs`: Traefik logs related.
+* `area/middleware`: Middleware related.
+* `area/middleware/metrics`: Metrics related. (Prometheus, StatsD, ...)
+* `area/oxy`: Oxy related.
 * `area/provider`: related to all providers.
 * `area/provider/boltdb`: Boltd DB related.
 * `area/provider/consul`: Consul related.
@@ -46,17 +70,10 @@ If we open/look an issue/PR, we must add a `kind/*` and an `area/*`.
 * `area/provider/mesos`: Mesos related.
 * `area/provider/rancher`: Rancher related.
 * `area/provider/zk`: Zoo Keeper related.
-* `area/middleware`: Middleware related.
-* `area/acme`: ACME related.
-* `area/authentication`: Authentication related.
-* `area/api`: Traefik API related.
-* `area/logs`: Traefik logs related.
 * `area/sticky-session`: Sticky session related.
+* `area/tls`: TLS related.
 * `area/websocket`: WebSocket related.
 * `area/webui`: Web UI related.
-* `area/infrastructure`: related to CI or Traefik building scripts.
-* `area/documentation`: regards improving/adding documentation.
-* `area/cluster`: Traefik clustering related.
 
 ### Priority