You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
42 lines
1.3 KiB
42 lines
1.3 KiB
# 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.
|
|
|