Diff
1diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
2deleted file mode 100644
3index 9964c380d34d87b1e2bfbdaf99f8d1292dfdf3fc..0000000000000000000000000000000000000000
4--- a/CONTRIBUTING.md
5+++ /dev/null
6@@ -1,42 +0,0 @@
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.