Add proper README for how to develop on hacking

Move parts of HACKING to README, along with how to add rules, how to
version. This is the first pass at the README, it's expected to continue
to grow

Change-Id: I2dcbc0ae8a65f67c64cf406ac2efc6ee4a305ee4
Reviewed-on: https://review.openstack.org/30942
Reviewed-by: Mark McLoughlin <markmc@redhat.com>
Reviewed-by: Sean Dague <sean@dague.net>
Approved: Mark McLoughlin <markmc@redhat.com>
Tested-by: Jenkins

HACKING.rst

@@ -1,8 +1,3 @@
-Introduction
-============
-
-hacking is a set of flake8 plugins that test and enforce:
-
 OpenStack Style Commandments
 ============================
 
@@ -301,24 +296,3 @@ and how to split up commits into a series of changes, consult the
 project wiki:
 
    http://wiki.openstack.org/GitCommitMessages
-
-Local Checks
-============
-
-hacking supports having local changes in a source tree. They can be configured
-to run in two different ways. They can be registered individually, or with
-a factory function.
-
-For individual registration, put a comma separated list of pep8 compatible
-check functions into the hacking section of tox.ini. Like
-
-  [hacking]
-  local-check = nova.tests.hacking.bad_code_is_terrible
-
-Alternately, you can specify the location of a callable that will be called
-at registration time and will be passed the registration function. The callable
-should expect to call the passed in function on everything if wants to
-register. Such as:
-
-  [hacking]
-  local-check-factory = nova.tests.hacking.factory

README.rst

@@ -0,0 +1,50 @@
+Introduction
+============
+
+hacking is a set of flake8 plugins that test and enforce the OpenStack Style Commandments, `HACKING.rst <HACKING.rst>`_.
+
+
+Versioning
+==========
+
+hacking uses the major.minor.maintenance release notation, where maintenance releases cannot contain new checks.  This way projects can gate on hacking by pinning on the major.minor number while accepting maintenance updates without being concerned that a new version will break the gate with a new check.
+
+
+Adding additional checks
+========================
+
+Each check is a pep8 plugin so read
+
+   https://github.com/jcrocholl/pep8/blob/master/docs/developer.rst#contribute
+
+Requirements
+------------
+- The canonical source of the OpenStack Style Commandments is `HACKING.rst <HACKING.rst>`_, and hacking just enforces them; so when adding a new check, it must be in HACKING.rst
+- False negatives are ok, but false positives are not
+- Cannot be project specific, project specific checks should be `Local Checks`_
+- Docstring tests
+- Registered as entry_points in `setup.cfg <setup.cfg>`_
+- Error code must be in the relevant ``Hxxx`` group
+
+
+Local Checks
+============
+
+hacking supports having local changes in a source tree. They can be configured
+to run in two different ways. They can be registered individually, or with
+a factory function.
+
+For individual registration, put a comma separated list of pep8 compatible
+check functions into the hacking section of tox.ini. Like
+
+  [hacking]
+  local-check = nova.tests.hacking.bad_code_is_terrible
+
+Alternately, you can specify the location of a callable that will be called
+at registration time and will be passed the registration function. The callable
+should expect to call the passed in function on everything if wants to
+register. Such as:
+
+  [hacking]
+  local-check-factory = nova.tests.hacking.factory
+

hacking/core.py

@@ -47,6 +47,8 @@ def flake8ext(f):
     f.version = '0.0.1'
     return f
 
+# Error code block layout
+
 #H1xx comments
 #H2xx except
 #H3xx imports