docs(eslint): sync with upstream docs (#404)

Fixes #403

packages/conventional-changelog-eslint/README.md

@@ -6,40 +6,42 @@
 
 ## ESLint Convention
 
-Make the changes to the code and tests and then commit to your branch. Be sure to follow the commit message conventions.
-
-Commit message summaries must follow this basic format:
+Our commit message format is as follows:
 
 ```
-Tag: Message (fixes #1234)
+Tag: Short description (fixes #1234)
+
+Longer description here if necessary
 ```
 
-`Tag` should not be confused with git tag.
-`Message` should not be confused with git commit message.
+The first line of the commit message (the summary) must have a specific format. This format is checked by our build tools.
 
 The `Tag` is one of the following:
 
 * `Fix` - for a bug fix.
-* `Update` - for a backwards-compatible enhancement.
-* `Breaking` - for a backwards-incompatible enhancement.
+* `Update` - either for a backwards-compatible enhancement or for a rule change that adds reported problems.
+* `New` - implemented a new feature.
+* `Breaking` - for a backwards-incompatible enhancement or feature.
 * `Docs` - changes to documentation only.
 * `Build` - changes to build process only.
-* `New` - implemented a new feature.
 * `Upgrade` - for a dependency upgrade.
+* `Chore` - for refactoring, adding tests, etc. (anything that isn't user-facing).
+
+Use the [labels of the issue you are working on](working-on-issues.md#issue-labels) to determine the best tag.
 
-The message summary should be a one-sentence description of the change. The issue number should be mentioned at the end. * The commit message should say "(fixes #1234)" at the end of the description if it closes out an existing issue (replace 1234 with the issue number). If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
+The message summary should be a one-sentence description of the change, and it must be 72 characters in length or shorter. If the pull request addresses an issue, then the issue number should be mentioned at the end. If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
 
 Here are some good commit message summary examples:
 
 ```
 Build: Update Travis to only test Node 0.10 (refs #734)
 Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
-Upgrade: Esprima to 1.2, switch to using Esprima comment attachment (fixes #730)
+Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
 ```
 
 The commit message format is important because these messages are used to create a changelog for each release. The tag and issue number help to create more consistent and useful changelogs.
 
-Based on https://github.com/eslint/eslint.github.io/blob/master/docs/developer-guide/contributing/pull-requests.md
+Based on https://eslint.org/docs/developer-guide/contributing/pull-requests#step2
 
 [npm-image]: https://badge.fury.io/js/conventional-changelog-eslint.svg
 [npm-url]: https://npmjs.org/package/conventional-changelog-eslint