Started on a contributing doc

CONTRIBUTING.md

+# Contributing to Packer
+
+**First:** if you're unsure or afraid of _anything_, just ask
+or submit the issue or pull request anyways. You won't be yelled at for
+giving your best effort. The worst that can happen is that you'll be
+politely asked to change something. We appreciate any sort of contributions,
+and don't want a wall of rules to get in the way of that.
+
+However, for those individuals who want a bit more guidance on the
+best way to contribute to the project, read on. This document will cover
+what we're looking for. By addressing all the points we're looking for,
+it raises the chances we can quickly merge or address your contributions.
+
+## Issues
+
+### Reporting an Issue
+
+* Make sure you test against the latest released version. It is possible
+  we already fixed the bug you're experiencing.
+
+* Provide a reproducible test case. If a contributor can't reproduce an
+  issue, then it dramatically lowers the chances it'll get fixed. And in
+  some cases, the issue will eventually be closed.
+
+* Respond promptly to any questions made by the Packer team to your issue.
+  Stale issues will be closed.
+
+### Issue Lifecycle
+
+1. The issue is reported.
+
+2. The issue is verified and categorized by a Packer collaborator.
+   Categorization is done via tags. For example, bugs are marked as "bugs"
+   and easy fixes are marked as "easy".
+
+3. Unless it is critical, the issue is left for a period of time (sometimes
+   many weeks), giving outside contributors a chance to address the issue.
+
+4. The issue is addressed in a pull request or commit. The issue will be
+   referenced in the commit message so that the code that fixes it is clearly
+   linked.
+
+5. The issue is closed.