Update contribution guide

1 files changed, 19 insertions, 32 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 31243fd72..8044b0e83 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,62 +1,49 @@
-# 0x.js CONTRIBUTING.md
+0x Protocol Contributing Guide
+------------------------------
 
-Thank you for your interest in contributing to 0x.js! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
+Thank you for your interest in contributing to 0x protocol! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
 
 ## Developer's guide
 
-## How to contribute
+### How to contribute
 
-If you'd like to contribute to 0x.js, please fork the repo, fix, commit and send a pull request against the `development` branch for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with a core dev first on [our gitter channel](https://gitter.im/0xProject/Lobby) or  in the `#dev` channel on our [slack](https://slack.0xproject.com/) to ensure those changes are in line with the general philosophy of the project and/or to get some early feedback which can make both your efforts easier as well as our review and merge procedures quick and simple.
+If you'd like to contribute to 0x protocol, please fork the repo, fix, commit and send a pull request against the `development` branch for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check with a core dev first on [our RocketChat #dev channel](http://chat.0xproject.com) to ensure those changes are in-line with the general philosophy of the project and/or to get some early feedback which can make both your efforts easier as well as our review and merge procedures quick and simple.
 
-We encourage a “PR early” approach so create the PR as early as possible even without the fix/feature ready, so that devs and other volunteers know you have picked up the issue. These early PRs should indicate an 'in progress' status by adding the '[WIP]' prefix to the PR title. Please make sure your contributions adhere to our coding guidelines:
+We encourage a “PR early” approach so create the PR as early as possible even without the fix/feature ready, so that devs and other contributors know you have picked up the issue. These early PRs should indicate an 'in progress' status by adding the '[WIP]' prefix to the PR title. Please make sure your contributions adhere to our coding guidelines:
 
 * Pull requests adding features or refactoring should be opened against the `development` branch
 * Pull requests fixing bugs in the latest release version should be opened again the `master` branch
 * Write [good commit messages](https://chris.beams.io/posts/git-commit/)
 
-## Code quality
+### Code quality
+
+Because 0x.js is used by multiple relayers in production and their businesses depend on it, we strive for exceptional code quality. Please follow the existing code standards and conventions. `tslint` and `prettier` (described below) will help you.
 
-Because 0x.js is used by multiple relayers in production and their businesses depend on it, we strive for excellent code quality. Please follow the existing code standards and conventions. `tslint` (described below) will help you.
 If you're adding functionality, please also add tests and make sure they pass. We have an automatic coverage reporting tool, so we'll see it if they are missing ;)
 If you're adding a new public function/member, make sure you document it with Java doc-style comments. We use typedoc to generate [awesome documentation](https://0xproject.com/docs/0xjs) from the comments within our source code.
 
-## Running and building
-
-First thing to do with an unknown code base is to run the tests.
-We assume that you have `npm` and `yarn` installed.
-
-To do that:
-
-* Install dependencies: `yarn`
-* Initialize the testrpc state (migrate the contracts) by doing one of the following:
-    * Manual contracts migration:
-        * Run testrpc: `yarn testrpc`
-        * Clone the `[contracts](https://github.com/0xProject/contracts)` repo and run `yarn migrate`
-    * Use one of the existing testrpc snapshots
-        * Check out `circle.yml` for an example
-* Run tests: `yarn test`
+If the sub-package you are modifying has a `CHANGELOG.md` file, make sure to add an entry in it for the change made to the package. For published packages, only changes that modify the public interface or behavior of the package need a CHANGELOG entry.
 
-To build run: `yarn build`
+### Styleguide
 
-We also recommend you read through the tests.
-
-## Styleguide
-
-We use [TSLint](https://palantir.github.io/tslint/) with [custom configs](https://github.com/0xProject/tslint-config-0xproject) to keep our code style consistent.
+We use [TSLint](https://palantir.github.io/tslint/) with [custom configs](https://github.com/0xProject/0x.js/tree/development/packages/tslint-config) to keep our code style consistent.
 
 To lint your code just run: `yarn lint`
 
+We also use [Prettier](https://prettier.io/) to auto-format our code. Be sure to either add a [text editor integration](https://prettier.io/docs/en/editors.html) or a [pre-commit hook](https://prettier.io/docs/en/precommit.html) to properly format your code changes.
+
 If using the Atom text editor, we recommend you install the following packages:
 
 * [atom-typescript](https://atom.io/packages/atom-typescript)
 * [linter-tslint](https://atom.io/packages/linter-tslint)
+* [prettier-atom](https://atom.io/packages/prettier-atom)
+* [language-ethereum](https://atom.io/packages/language-ethereum)
 
-Our CI will also run it as a part of the test run when you submit your PR.
-
+Our CI will also run TSLint and Prettier as a part of the test run when you submit your PR. Make sure that the CI tests pass for your contribution.
 
-## Branch structure & versioning
+### Branch structure & versioning
 
-We use [semantic versioning](http://semver.org/), but before we reach v1.0.0 all breaking changes as well as new features will be minor version bumps.
+We use [semantic versioning](http://semver.org/), but before a package reaches v1.0.0 all breaking changes as well as new features will be minor version bumps.
 
 We have two main branches: `master` and `development`.