Added contributing policy

Fixes #14.
> Correct, but they make sense in the context of their parent and in context of the branch

Which in turn is hard to see, you need graphical visualization tools just to be able to find the historic branches. Which gets *really* messy, especially with multiple merges from master into the branch.

Btw, I'm not advocating rebasing the feature into master. You still have merge commits, even if you squash some of your commits in the PR.

> That completely differs with my experience; it is not prevented at all

It is not prevented, but you need to find the commit with the good documentation among multiple fix- and typo-commits which don't add any "real" value by themselves.

> You may be looking for -m (alas I don't think it has a descriptive longopt)

Github doesn't show it though. It's unnecessary additional work.

As a realworld example, see the following three commits:

https://github.com/celery/celery/commit/133f2a1aecf5c6bb6e7e04978d14d041a9706c42
https://github.com/celery/celery/commit/49d356d61a67bed94ef343ae588928873ca35867
https://github.com/celery/celery/commit/05e2567ede7c71f523cc5783ccb47ad8eac951d8

While the commits are fine, you need to jump around between all three of them just to get "the big picture". One of the commits moves around one of the new methods (which appears as a deletion and an addition) and adds a docstring to a method that was created in one of the previous two commits. While this is not "bad", it would be much nicer if there were one commit adding the method including a good docstring. While the second commit could stay separate as it adds value (-> a new method), the third one does not add any value on its own.