Create contributing.md

CONTRIBUTING.md

@@ -0,0 +1,29 @@
+Contributing to Esp-Link
+========================
+
+Esp-link is not the work of a single individual, rather many people have contributed directly or indirectly.
+Your contribution is very much appreciated, but please follow these guidelines to make the task easier on
+everyone.
+
+- Contributions do not have to be in the form of code: often documentation, how-tos are very valuable and answering questions
+  in github issues as well as gitter is also very valuable and welcome!
+- Before you make a change or submit a change via a pull request, **open an issue and discuss your proposed change**. Gitter
+  is a good alternative to a github issue. This ensures that you don't spend time doing work that ultimately won't be accepted.
+  There's nothing more frustrating than receiving a pull-request that has lots of goodies but doesn't fit because it wasn't
+  discussed and agreed upon up-front.
+- Keep your pull request as small as practical, if you have 3 things you want to change, please create 3 pull requests,
+  or at the very least, make sure your 3 changes are in different commits. This makes the review and testing easier
+  and ensures that if one feature is good to go it can be merged even if another feature needs more tweaking.
+- The esp-link codebase is not uniform, it comes from a variety of sources, in particular esphttpd. A result of this is
+  that there is more than one coding style in use. If you make changes to existing files, please respect the file's
+  coding style (yes, sometimes that's not even totally uniform). Your overall goal should be for your code or changes to
+  look as if the original author had made them, not how you would like them to look.
+- Changes that reformat or reorganize code will generally not be accepted, please do not mix them with other functionality
+  changes you are making and certainly discuss them first. Accept the fact that some people prefer bastards over pure-breads ;-).
+- Esp-link has a mission stated in the readme.md, changes that deviate from that mission will generally be rejected. The reason
+  is that at the end of the day focusing on doing one thing well has a higher chance of succeeding than doing many things.
+  In that sense, esp-link is not a swiss-army knife firmware. (This being said, many people have used esp-link as a basis to add
+  their own functionality, which is very cool.)
+  
+I believe the above guidelines are pretty standard across a very large number of open source projects and not unique to esp-link,
+so please do not get discouraged. Thank you for taking a look at esp-link!