More docs on contributing

doc/development/contribution/general.rst

@@ -0,0 +1,36 @@
+General remarks
+===============
+
+You are interesting in contributing to pretix? That is awesome!
+
+If you’re new to contributing to open source software, don’t be afraid. We’ll happily review your code and give you
+constructive and friendly feedback on your changes.
+
+First of all, you'll need pretix running locally on your machine. Head over to :ref:`devsetup` to learn how to do this.
+If you run into any problems on your way, please do not hesitate to ask us anytime!
+
+Sending a patch
+---------------
+
+If you improved pretix in any way, we'd be very happy if you contribute it
+back to the main code base! The easiest way to do so is to `create a pull request`_
+on our `GitHub repository`_.
+
+Before you do so, please `squash all your changes`_ into one single commit. Please
+use the test suite to check whether your changes break any existing features and run
+the code style checks to confirm you are consistent with pretix' coding style. You'll
+find instructions on this in the :ref:`checksandtests` section of the development setup guide.
+
+We automatically run the tests and the code style check on every pull request on Travis CI and we won’t
+accept any pull requets without all tests passing. However, if you don't find out *why* they are not passing,
+just send the pull request and tell us – we'll be glad to help.
+
+If you add a new feature, please include appropriate documentation into your patch. If you fix a bug,
+please include a regression test, i.e. a test that fails without your changes and passes after applying your changes.
+
+Again: If you get stuck, do not hesitate to contact any of us, or Raphael personally at mail@raphaelmichel.de.
+
+
+.. _create a pull request: https://help.github.com/articles/creating-a-pull-request/
+.. _GitHub repository: https://github.com/pretix/pretix
+.. _squash all your changes: https://davidwalsh.name/squash-commits-git

doc/development/contribution/index.rst

@@ -0,0 +1,8 @@
+Contribution guide
+==================
+
+.. toctree::
+   :maxdepth: 2
+
+   general
+   style

doc/development/contribution/style.rst

@@ -0,0 +1,39 @@
+Coding style
+============
+
+Python code
+-----------
+
+* Basically: Follow `PEP 8`_.
+
+  Use `flake8`_ to check for conformance problems. The project includes a setup.cfg
+  with a default configuration for flake8 that excludes migrations and other non-relevant
+  code parts. It also silences a few checks, e.g. ``N802`` (function names should be lowercase) 
+  and increases the maximum line length to more than 79 characters. **However** you should 
+  still name all your functions lowercase [#f1]_ and keep your lines short when possible.
+
+* Our build server will reject all code violating other flake8 checks than the following:
+  
+  * E123: closing bracket does not match indentation of opening bracket’s line
+  * F403: ``from module import *`` used; unable to detect undefined names
+  * F401: module imported but unused
+  * N802: function names should be lowercase
+
+ So please make sure that you *always* follow all other rules and break these rules *only when
+ it makes sense*.
+
+* Use ``isort -rc pretix`` in the source directory to order your imports.
+
+* Indent your code with four spaces.
+
+* For templates and models, follow the `Django Coding Style`_.
+
+* Use Django's class-based views
+
+* Always mark all strings ever displayed to any user for translation.
+
+
+.. _PEP 8: http://legacy.python.org/dev/peps/pep-0008/
+.. _flake8: https://pypi.python.org/pypi/flake8
+.. _Django Coding Style: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/
+.. [#f1] But Python's very own ``unittest`` module forces us to use ``setUp`` as a method name...