Add contribution guide

Author: MarkusH

CONTRIBUTING.rst

@@ -0,0 +1,66 @@
+Contributing
+============
+
+Thank you for your interest in contributing.
+
+This document is a guideline. Don't worry about getting everything perfect.
+We are happy to work with you on your contribution.
+
+`Upvoting existing issues <#upvoting-issues>`_, `reporting new issues
+<#reporting-issues>`_, or `giving feedback <#tell-us-about-your-experience>`_
+about your experience are the easiest ways to contribute.
+
+We also accept pull requests for changes to the code and to the documentation.
+For more information on how to do this, read our `developer guide`_.
+
+If you have any questions, please reach out via any of our `support channels`_.
+
+
+Upvoting Issues
+---------------
+
+An easy way to contribute is to upvote existing issues that are relevant to
+you. This will give us a better idea what is important for you and other users.
+
+Please avoid content-less ``+1`` comments but instead use the emoji reaction to
+upvote with a 👍. This allows people to `sort issues by reaction`_ and doesn't
+spam the maintainers.
+
+
+Reporting Issues
+----------------
+
+Before you report an issue, please `search the existing issues`_ to make sure
+someone hasn't already reported it.
+
+When reporting a new issue, include as much detail as possible. Please include:
+
+- What you did, what happened, and what you expected to happen
+
+- Steps to reproduce the issue
+
+- Which CrateDB Kubernetes Operator version you're using
+
+- Which Kubernetes version you're using
+
+- Logs or stacktraces
+
+  - For example, operator can be started with an environment variable
+    ``CRATEDB_OPERATOR_LOG_LEVEL=DEBUG`` to get a full list of its interactions
+    with Kubernetes.
+
+
+Tell us about your experience
+=============================
+
+You don't have to create a detailed bug report or request a new feature to make
+a valuable contribution. Giving us feedback about your experience with the
+CrateDB Kubernetes Operator is incredibly valuable as well. Please `get in
+touch`_ with us to tell us what you like and don't like about it.
+
+
+.. _developer guide: docs/source/development.rst
+.. _support channels: https://crate.io/support/
+.. _sort issues by reaction: https://github.com/crate/crate-operator/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
+.. _search the existing issues: https://github.com/crate/crate-operator/issues
+.. _get in touch: https://crate.io/contact/

docs/source/development.rst

@@ -1,6 +1,30 @@
 Working on the operator
 =======================
 
+Contributing
+------------
+
+Before we can accept any pull requests, we need you to agree to our CLA_.
+
+Once that is complete, you should:
+
+- Create an issue on GitHub to let us know that you're working on the issue.
+
+- Use a feature branch and not ``master``.
+
+- Rebase your feature branch onto the upstream ``master`` before creating the
+  pull request.
+
+- `Be descriptive in your PR and commit messages
+  <#meaningful-commit-messages>`_. What is it for? Why is it needed? And so on.
+
+- If applicable, `run the tests <#testing>`_.
+
+- Squash related commits.
+
+
+.. _testing:
+
 Testing
 -------
 
@@ -88,5 +112,76 @@ For the following steps we assume the next version is going to be ``$VERSION``.
       $ git pull
       $ ./devtools/create_tag.sh "$VERSION"
 
+
+General Tips
+------------
+
+.. _commit-message-style:
+
+Meaningful Commit Messages
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Please choose a meaningful commit message. The commit message is not only
+valuable during the review process, but can be helpful for reasoning about any
+changes in the code base. For example, PyCharm's "Annotate" feature, brings up
+the commits which introduced the code in a source file. Without meaningful
+commit messages, the commit history does not provide any valuable information.
+
+The first line of the commit message (also known as "subject line") should
+contain a summary of the changes. Please use the imperative mood. The subject
+can be prefixed with "Test: " or "Docs: " to indicate the changes are not
+primarily to the main code base. For example::
+
+   Put a timeout on all bootstrap operations
+   Test: Increase bootstrap timeout in tests
+   Docs: Copyedit docs on configuration options
+
+See also: https://chris.beams.io/posts/git-commit/
+
+Updating Your Branch
+^^^^^^^^^^^^^^^^^^^^
+
+If new commits have been added to the upstream ``master`` branch since you
+created your feature branch, please do not merge them in to your branch.
+Instead, rebase your branch::
+
+   $ git fetch upstream
+   $ git rebase upstream/master
+
+This will apply all commits on your feature branch on top of the upstream
+``master`` branch. If there are conflicts, they can be resolved with ``git
+merge``. After the conflict has been resolved, use ``git rebase --continue`` to
+continue the rebase process.
+
+Squashing Minor Commits
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Minor commits that only fix typos or rename variables that are related to a
+bigger change should be squashed into that commit.
+
+This can be done with the following command::
+
+   $ git rebase -i origin/master
+
+This will open up a text editor where you can annotate your commits.
+
+Generally, you'll want to leave the first commit listed as ``pick``, or change
+it to ``reword`` (or ``r`` for short) if you want to change the commit message.
+And then, if you want to squash every subsequent commit, you could mark them
+all as ``fixup`` (or ``f`` for short).
+
+Once you're done, you can check that it worked by running::
+
+   $ git log
+
+If you're happy with the result, do a **force** push (since you're rewriting
+history) to your feature branch::
+
+   $ git push -f
+
+
+See also: http://www.ericbmerritt.com/2011/09/21/commit-hygiene-and-git.html
+
+.. _CLA: https://crate.io/community/contribute/agreements/
 .. _setuptools-scm: https://pypi.org/project/setuptools-scm/
 .. _Semantic Versioning: https://semver.org/