ylib/ohmyzsh
1
0
Fork 0
mirror of https://github.com/ohmyzsh/ohmyzsh.git synced 2024-11-22 14:55:51 +08:00
Code Projects Releases Wiki Activity

Revert "Add a CONTRIBUTING file to instruct people on issues and pull requests"

Browse Source
This commit is contained in:
Robby Russell 2014-09-01 12:59:47 +02:00
parent fdba0f43f5
commit 39fb6c9d35
1 changed files with 0 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
CONTRIBUTING.md
View File

@ -1,42 +0,0 @@
# 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.