diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d8d3b60ecc99d..db620e994c998 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,47 +1,215 @@
-# How to contribute
+# Contribution Guide #
+TiDB is a community driven open source project and we welcome any contributor. The process of contributing to the TiDB project
+may be different than many other projects you have been involved in. This document outlines some conventions about development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted. This document is the canonical source of truth for things like supported toolchain versions for building and testing TiDB.
 
-This document outlines some of the conventions on development workflow, commit message formatting, contact points and other
-resources to make it easier to get your contribution accepted.
+## Pre submit pull request/issue flight checks
 
-## Getting started
+Before you move on, please make sure what your issue and/or pull request is, a simple bug fix or an architecture change.
 
-- Fork the repository on GitHub.
-- Read the README.md for build instructions.
-- Play with the project, submit bugs, submit patches!
+In order to save reviewers' time, each issue should be filed with template and should be sanity-checkable in under 5 minutes.
 
-## Contribution flow
+### Is this a simple bug fix?
 
-This is a rough outline of what a contributor's workflow looks like:
+Bug fixes usually come with tests. With the help of continuous integration test, patches can be easy to review. Please update the unit tests so that they catch the bug! Please check example [here](https://github.com/pingcap/tidb/pull/2808).
 
-- Create a topic branch from where you want to base your work. This is usually master.
-- Make commits of logical units and add test case if the change fixes a bug or adds new functionality.
-- Run tests and make sure all the tests are passed.
-- Make sure your commit messages are in the proper format (see below).
-- Push your changes to a topic branch in your fork of the repository.
-- Submit a pull request to pingcap/tidb.
-- Your PR must receive LGTMs from two maintainers found in the [MAINTAINERS](./docs/MAINTAINERS.md) file.
+### Is this an architecture improvement?
 
-Thanks for your contributions!
+Some examples of "Architecture" improvements:
 
-### Code style
+- Converting structs to interfaces.
+- Improving test coverage.
+- Decoupling logic or creation of new utilities.
+- Making code more resilient (sleeps, backoffs, reducing flakiness, etc).
 
-The coding style suggested by the Golang community is used in TiDB. See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
+If you are improving the quality of code, then justify/state exactly what you are 'cleaning up' in your Pull Request so as to save reviewers' time. An example will be this [pull request](https://github.com/pingcap/tidb/pull/3113).
 
-Please follow this style to make TiDB easy to review, maintain and develop.
+If you're making code more resilient, test it locally to demonstrate how exactly your patch changes
+things.
+
+## Building TiDB on a local OS/shell environment
+
+TiDB development only requires `go` set-up. If you already have, simply type `make` from terminal.
+
+### Go
+
+TiDB is written in [Go](http://golang.org).
+If you don't have a Go development environment,
+please [set one up](http://golang.org/doc/code.html).
+
+After installation, you'll need `GOPATH` defined,
+and `PATH` modified to access your Go binaries.
+
+A common setup is the following but you could always google a setup for your own flavor.
+```sh
+export GOPATH=$HOME/go
+export PATH=$PATH:$GOPATH/bin
+```
+
+#### Dependency management
+
+TiDB build/test scripts use [`glide`](https://github.com/Masterminds/glide) to
+manage dependencies.
+
+```sh
+go get -u  github.com/Masterminds/glide
+```
+
+## Workflow
+
+### Step 1: Fork in the cloud
+
+1. Visit https://github.com/pingcap/tidb
+2. Click `Fork` button (top right) to establish a cloud-based fork.
+
+### Step 2: Clone fork to local storage
+
+Per Go's [workspace instructions][go-workspace], place TiDB's code on your
+`GOPATH` using the following cloning procedure.
+
+Define a local working directory:
+
+```sh
+# If your GOPATH has multiple paths, pick
+# just one and use it instead of $GOPATH here
+working_dir=$GOPATH/src/github.com/pingcap
+```
+
+> If you already worked with Go development on github before, the `pingcap` directory
+> will be a sibling to your existing `github.com` directory.
+
+Set `user` to match your github profile name:
+
+```sh
+user={your github profile name}
+```
+
+Create your clone:
+
+```sh
+mkdir -p $working_dir
+cd $working_dir
+git clone https://github.com/$user/tidb.git
+# the following is recommended
+# or: git clone git@github.com:$user/tidb.git
+
+cd $working_dir/tidb
+git remote add upstream https://github.com/pingcap/tidb.git
+# or: git remote add upstream git@github.com:pingcap/tidb.git
+
+# Never push to upstream master since you do not have write access
+git remote set-url --push upstream no_push
+
+# Confirm that your remotes make sense:
+# It should look like:
+# origin    git@github.com:$(user)/tidb.git (fetch)
+# origin    git@github.com:$(user)/tidb.git (push)
+# upstream  https://github.com/pingcap/tidb (fetch)
+# upstream  https://github.com/pingcap/tidb (push)
+git remote -v
+```
+
+#### Define a pre-commit hook
+
+Please link the TiDB pre-commit hook into your `.git` directory.
+
+This hook checks your commits for formatting, building, doc generation, etc.
+
+```sh
+cd $working_dir/tidb/.git/hooks
+ln -s ../../hooks/pre-commit .
+```
+Sometime, pre-commit hook can not be executable. In such case, you have to make it executable manually.
+
+```sh
+chmod +x hooks/precommit
+```
 
-### Format of the Commit Message
 
-We follow a rough convention for commit messages that is designed to answer two
-questions: what changed and why. The subject line should feature the what and
-the body of the commit should describe the why.
 
+### Step 3: Branch
+
+Get your local master up to date:
+
+```sh
+cd $working_dir/tidb
+git fetch upstream
+git checkout master
+git rebase upstream/master
+```
+
+Branch from master:
+```sh
+git checkout -b myfeature
+```
+
+Then edit code on the `myfeature` branch.
+
+#### Build
+
+```sh
+# Run unit test to make sure all test passed
+make dev
+
+# Build tidb-server to make sure a binary can be built
+cd $working_dir/tidb
+make
+
+# Check checklist before you move on
+make checklist
+```
+
+### Step 4: Keep your branch in sync
+
+```sh
+# While on your myfeature branch
+git fetch upstream
+git rebase upstream/master
+```
+
+### Step 5: Commit
+
+Commit your changes.
+
+```sh
+git commit
 ```
-store/localstore: add comment for variable declaration.
+Likely you'll go back and edit/build/test some more than `commit --amend`
+in a few cycles.
 
-Improve documentation.
+### Step 6: Push
+
+When ready to review (or just to establish an offsite backup or your work),
+push your branch to your fork on `github.com`:
+
+```sh
+git push -f origin myfeature
 ```
 
-The format can be described more formally as follows:
+### Step 7: Create a pull request
+
+1. Visit your fork at https://github.com/$user/tidb (replace `$user` obviously).
+2. Click the `Compare & pull request` button next to your `myfeature` branch.
+
+#### Step 8: get a code review
+
+Once your pull request has been opened, it will be assigned to at least two
+reviewers. Those reviewers will do a thorough code review, looking for
+correctness, bugs, opportunities for improvement, documentation and comments,
+and style.
+
+Commit changes made in response to review comments to the same branch on your
+fork.
+
+Very small PRs are easy to review. Very large PRs are very difficult to
+review.
+
+## Code style ##
+
+The coding style suggested by the Golang community is used in TiDB. See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
+
+
+## Commit message style ##
+Please follow this style to make TiDB easy to review, maintain and develop.
 
 ```
 <subsystem>: <what changed>
@@ -63,3 +231,12 @@ If the change affects many subsystems, you can use ```*``` instead, like ```*:``
 For the why part, if no specific reason for the change,
 you can use one of some generic reasons like "Improve documentation.",
 "Improve performance.", "Improve robustness.", "Improve test coverage."
+
+[Os X GNU tools]: https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x
+[go-1.8]: https://blog.golang.org/go1.8
+[go-workspace]: https://golang.org/doc/code.html#Workspaces
+[issue]: https://github.com/pingcap/tidb/issues
+[mercurial]: http://mercurial.selenic.com/wiki/Download
+
+
+