Added contributing policy

Fixes #14.

CONTRIBUTING.md

@@ -0,0 +1,35 @@
+# Contributors Guidelines
+
+Contributions to py3minepi are welcome! Please adhere to the following
+contribution guidelines though:
+
+- Run the [test suite](https://github.com/py3minepi/py3minepi#testing) before
+  committing and pushing your changes.
+- Please follow the [coding
+  guidelines](https://github.com/py3minepi/py3minepi#coding-guidelines).
+- Use meaningful commit messages: First line of your commit message should be a
+  very short summary (ideally 50 characters or less). After the first line of
+  the commit message, add a blank line and then a more detailed explanation (when
+  relevant).  [This](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+  is a nice blog post concerning git commit messages.
+- Add yourself to the [AUTHORS.txt
+  file](https://github.com/py3minepi/py3minepi/blob/master/AUTHORS.txt).
+- Even if you have write access to the repository, never push commits directly
+  to master. Always create a branch or a fork and post a pull request. The pull
+  request will then be merged by someone other than you after at least 1
+  approving comment by a py3minepi organization member.
+
+The following items make our lifes easier, but are optional:
+
+- If you know how to use `git rebase`, please rebase/sqash your commits so that
+  unnecessary noise in the commit history is avoided.
+- If you have have previously filed a GitHub issue and want to contribute code
+  that addresses that issue, we prefer it if you use
+  [hub](https://github.com/github/hub) to convert your existing issue to a pull
+  request. To do that, first push the changes to a separate branch in your fork
+  and then issue the following command: `hub pull-request -b py3minepi:master -i
+  <issue-number> -h <your-github-username>:<your-branch-name>` This is no strict
+  requirement though, if you don't have hub installed or prefer to use the web
+  interface, then feel free to post a traditional pull request.
+
+Thanks for your contribution!

README.rst

@@ -17,6 +17,7 @@ approval) and offering it for download here.
 
 We hope this makes people's lives easier.
 
+
 Goals
 -----
 
@@ -31,6 +32,61 @@ Goals
 - [ ] Improve code documentation both in the code base and with a RTD page
 - [ ] Find missing functions that are in the java API but not described in the python API
 
+
+Coding Guidelines
+-----------------
+
+All code (except legacy API compatibility code) should adhere to `PEP8
+<http://legacy.python.org/dev/peps/pep-0008/>`_ with some exceptions:
+
+- Try to keep your line length below 80, but if it looks better then use up to
+  99 characters per line.
+- You can ignore the following three PEP8 rules: E126 (continuation line
+  over-indented for hanging indent), E127 (continuation line over-indented for
+  visual indent), E128 (continuation line under-indented for visual indent).
+
+You can check the code style for example by using `flake8
+<https://pypi.python.org/pypi/flake8>`_.
+
+Some other things you should keep in mind:
+
+- Function names should mirror ingame commands where possible.
+- Group imports into three groups: First stdlib imports, then third party
+  imports, then local imports. Put an empty line between each group.
+- Backwards compatibility must be maintained unless you have a very compelling
+  reason.
+- KISS!
+
+
+Testing
+-------
+
+Testing for swidGenerator is set up using `Tox <http://tox.readthedocs.org/>`_
+and `pytest <http://pytest.org/>`_. Violations of the `coding guidelines
+<#coding-guidelines>`__ are counted as test fails.
+
+The only requirement to run the tests is tox::
+
+    $ pip install tox
+
+**Running tests**
+
+To run the tests on all supported Python versions, simply issue ::
+
+    $ tox
+
+To test only a single Python version, use the ``-e`` parameter::
+
+    $ tox -e py32
+
+To see the test coverage, use the ``cov`` testenv (which uses Python 3.2 by
+default)::
+
+    $ tox -e cov
+
+All Python versions you need to test on need to be installed of course.
+
+
 Links
 -----