Diff
1diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
2new file mode 100644
3index 0000000000000000000000000000000000000000..9964c380d34d87b1e2bfbdaf99f8d1292dfdf3fc
4--- /dev/null
5+++ b/CONTRIBUTING.md
6@@ -0,0 +1,42 @@
7+# CONTRIBUTING GUIDELINE
8+
9+1. [Luke, use the search](#luke-use-the-search)
10+2. [You have a problem](#you-have-a-problem)
11+3. [You have a solution](#you-have-a-solution)
12+
13+**BONUS:** [You have free time to volunteer](#you-have-free-time-to-volunteer)
14+
15+## LUKE, USE THE SEARCH
16+
17+May the experiences of other people be with you
18+
19+
20+## YOU HAVE A PROBLEM
21+
22+See point 1, then look at FAQ or Troubleshooting wiki pages (first we'll have to make them)
23+
24+
25+## YOU HAVE A SOLUTION
26+
27+See point 1, then go ahead (unless your solution is yet another theme)
28+
29+
30+## YOU HAVE FREE TIME TO VOLUNTEER
31+
32+Cool! Please have a look at the list below to understand how oh-my-zsh categorizes its issues.
33+
34+Classification of issues and
35+
36+- Bugs, which may be:
37+ - Specific of zsh \*
38+ - Regressions, in which we should summon the author of the offending commit once it is located
39+
40+- Feature requests
41+
42+- Helpdesk, which may be:
43+ - Specific of zsh \*
44+ - Everything else
45+
46+\* 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.
47+In the case of helpdesk, minimal response should be done. That is, provide a link to the wiki with the relevant information, or
48+add it to the FAQ of the wiki and point to it afterwards.