Added contributing guidelines

CONTRIBUTING.adoc

@@ -0,0 +1,86 @@
+Contribution Guidelines
+=======================
+
+*Note*: contributing implies that your contributions get licensed under the terms of link:LICENSE[LICENSE] (MPL 2.0).
+
+Opening issues
+--------------
+
+. Make sure you have a GitHub account.
+. Include steps to reproduce, if it is a bug.
+. Include information on what version you are using.
+
+Submit changes
+--------------
+
+Commit messages should be both _clear_ and _descriptive_. If possible they should start with the _verb_ that describes the change.
+Don't be shy to include additional information, like motivation, for that change below the initial line.
+
+Other developers should be able to understand _why_ a change occurred, when looking at it at a later point in time.
+
+Coding Style
+~~~~~~~~~~~~
+
+Make sure you adhere to the coding style, or your pull request might not get merged.
+
+. Use tabs for indentation
++
+While it makes no difference at all, this is clearly the superior choice, since only spacers will complain (as opposed to tabbers and spacers that use a different amount of spaces).
+
+. Align using a single tab
++
+I know this isn't what alignment is. I don't care though.
+
+. Function calls don't take spaces before, nor inside the parenthesis
++
+Use `function(param1, param2)` instead of `function ( param1, param2 )`.
+
+. Use spaces between keywords and the parenthesis though
++
+Use `if (condition)` instead of `if(condition)`.
+
+. Curly brackets go on the same row
++
+Saves space and I'm used to it.
+
+. Function blocks start on a new row
++
+This makes it easier with all the postfix operators, like `const`, which don't exist in C; I don't care.
+
+. Use blocks even when just putting a single statement
++
+This makes it easier to add more lines later, and we avoid two other discussions. This also doesn't break when you use a macro that expands to multiple statements.
+
+. When things are related, use an `enum`.
++
+Should be common sense. Seen too much code without it though.
+
+. Comment `// FALLTHROUGH`, `// EMPTY` and `// NOTREACHED` where applicable
++
+Explicit is better than implicit.
+
+. Don't test against booleans or `NULL`.
++
+Use the not operator instead.
+
+. Test against numbers
++
+Don't abuse that `0` is falsey.
+
+. Put headers in this order
+.. `#include "file.h"`
+.. Standard lib headers
+.. POSIX headers
+.. Library headers
+.. Own stuff
+
+. Put blocks of headers in alphabetical order
++
+If not possible comment which header requires the out-of-order one.
+
+Why am I this pedantic?
+~~~~~~~~~~~~~~~~~~~~~~~
+
+I hate it when I look at code written by 10 people and I see 15 different coding styles, and got to wrap my head around every single one. I don't really care _what_ is used, but it needs to be consistent.
+
+That said, if anything is unclear or I missed something feel free to open an issue.

README.adoc

@@ -45,5 +45,8 @@ This allows you to write your configuration in any language you want, while also
 Contribution
 ------------
 
-I'll add contribution guidelines later, when it's clear where the project is going.
+You want to contribute? Great!
-For now feel free to open issues.
+
+Future requests, bug reports and PRs are welcome. Be sure to read the link:CONTRIBUTING.adoc[CONTRIBUTING.adoc]. Note that pull requests without an issue they reference are ignored, to de decrease the amount of duplicated work.
+
+If anything is unclear, feel free to reach out to me.