diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..9964c380
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,42 @@
+# CONTRIBUTING GUIDELINE
+
+1. [Luke, use the search](#luke-use-the-search)
+2. [You have a problem](#you-have-a-problem)
+3. [You have a solution](#you-have-a-solution)
+
+**BONUS:** [You have free time to volunteer](#you-have-free-time-to-volunteer)
+
+## LUKE, USE THE SEARCH
+
+May the experiences of other people be with you
+
+
+## YOU HAVE A PROBLEM
+
+See point 1, then look at FAQ or Troubleshooting wiki pages (first we'll have to make them)
+
+
+## YOU HAVE A SOLUTION
+
+See point 1, then go ahead (unless your solution is yet another theme)
+
+
+## YOU HAVE FREE TIME TO VOLUNTEER
+
+Cool! Please have a look at the list below to understand how oh-my-zsh categorizes its issues.
+
+Classification of issues and
+
+- Bugs, which may be:
+  - Specific of zsh \*
+  - Regressions, in which we should summon the author of the offending commit once it is located
+
+- Feature requests
+
+- Helpdesk, which may be:
+  - Specific of zsh \*
+  - Everything else
+
+\* In the case of bugs, I see the benefit in going through the trouble of responding to that. After all, oh-my-zsh should be the missing link that makes zsh perfect, and hunting down an upstream bug can lead to a submitted PR.
+In the case of helpdesk, minimal response should be done. That is, provide a link to the wiki with the relevant information, or
+add it to the FAQ of the wiki and point to it afterwards.