Move all contribution info to readme. arskom#298

CONTRIBUTING.rst

@@ -1,32 +1,58 @@
+
 Spyne development guidelines
 ============================
 
+If you wish to contribute to Spyne's development, create a personal fork
+on GitHub. When you are ready to push to the upstream repository,
+submit a pull request to bring your work to the attention of the core
+committers. They will respond to review your patch and act accordingly.
+
 Code format
 -----------
 
-The code should comply with PEP8.
-
+Please follow the `PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_
+style guidelines for both source code and docstrings.
 
 Branching
 ---------
 
-For fixing an issue or adding a feature create a new branch from ``master`` branch.
+For fixing an issue or adding a feature create a new branch from ``master``
+branch.
 
+Github's pull-request feature is awesome, but there's a subtlety that's not
+totally obvious for newcomers: If you continue working on the branch that you
+used to submit a pull request, your commits will "pollute" the pull request
+until it gets merged. This is not a bug, but a feature -- it gives you the
+ability to address reviewers' concerns without creating pull requests over and
+over again. So, if you intend to work on other parts of spyne after submitting
+a pull request, please do move your work to its own branch and never submit a
+pull request from your master branch. This will give you the freedom to
+continue working on Spyne while waiting for your pull request to be reviewed.
 
-Pull request
-------------
+Pull requests
+-------------
 
 When submitting a pull request:
 
-* add and run tests.
-* describe the changes in ``CHANGELOG.rst``.
-* create a pull request from your topic branch to ``master`` in upstream Spyne repo.
-* review the diff of the pull request on github.
+* Add and run tests.
+* If needed, shortly describe the changes in ``CHANGELOG.rst``.
+* Create a pull request from your topic branch to ``master`` in upstream Spyne
+  repo, unless the work you're doing is part of a bigger ongoing effort under
+  the Spyne project.
+
+Do note that we keep the master branch on the upstream repository clean. So we
+never merge pull requests with failing tests. So make sure all old and new tests
+pass before submitting pull requests.
 
+Regular contributors may be invited to join as a core Spyne committer on
+GitHub. Even if this gives the core committers the power to commit directly
+to the core repository, we highly value code reviews and expect every
+significant change to be committed via pull requests.
 
 Development principles
 ----------------------
 
-* when overriding a method in a class use ``super`` to call the parent implementation instead of
-  directly specifying the parent class. This is needed to correctly call all implementations
-  according to MRO when having "diamond inheritance".
+* When overriding a method in a class use the ``super()`` to call the parent
+  implementation instead of explicitly specifying the parent class. This is
+  needed to correctly call all implementations of the overridden method
+  according to MRO in cases of multiple inheritance.

README.rst

@@ -133,40 +133,5 @@ You can also use the 'spyne' tag to ask questions on
 Contributing
 ============
 
-If you wish to contribute to Spyne's development, create a personal fork
-on GitHub.  When you are ready to push to the upstream repository,
-submit a pull request to bring your work to the attention of the core
-committers. They will respond to review your patch and act accordingly.
-
-To save both parties time, make sure the existing tests pass. If you are
-adding new functionality or fixing a bug, please have the accompanying test.
-This will both help us increase test coverage and insure your use-case
-is immune to feature code changes. You could also summarize in one or
-two lines how your work will affect the life of Spyne users in the
-CHANGELOG file.
-
-Please follow the `PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_
-style guidelines for both source code and docstrings.
-
-We could also use help with the docs, which are built from
-`restructured text <http://docutils.sourceforge.net/rst.html>`_ using
-`Sphinx <http://sphinx.pocoo.org>`_.
-
-Regular contributors may be invited to join as a core Spyne committer on
-GitHub. Even if this gives the core committers the power to commit directly
-to the core repository, we highly value code reviews and expect every
-significant change to be committed via pull requests.
-
-
-A small note about submitting Pull Requests
--------------------------------------------
-
-Github's pull-request feature is awesome, but there's a subtlety that's not
-totally obvious for newcomers: If you continue working on the branch that you
-used to submit a pull request, your commits will "pollute" the pull request
-until it gets merged. This is not a bug, but a feature -- it gives you the
-ability to address reviewers' concerns without creating pull requests over and
-over again. So, if you intend to work on other parts of spyne after submitting
-a pull request, please do move your work to its own branch and never submit a
-pull request from your master branch. This will give you the freedom to
-continue working on Spyne while waiting for your pull request to be reviewed.
+Please see the CONTRIBUTING.rst file in the Spyne source distribution for
+information about how you can help Spyne get more awesome.

doc/source/index.rst

@@ -36,6 +36,7 @@ Other Goodies
    tests
    faq
    h_and_f
+   ../../CONTRIBUTING.rst
 
 ##################
 Indices and tables