This is an unofficial standard and guide for creating scalable and efficient naming conventions and practices for GitHub Issues, where the default labels are unfortunately not enough for larger, collaborative, projects.
This standard practice can be applied to newly created GitHub repositories or added on top of existing ones. The philosophy behind this unofficial standard is to not only add scalable structure to the naming conventions of the label, but also the colors, sub-categories, and personal discipline.
Please, please, please contribute. If you see a mistake in grammar, spelling, syntax, usage of words, etc, do open a pull request! Help build this standard. Supply your opinion, your suggestion, your edits, your enhancements.
TODO
If we compare color to its wavelength in visible light, it can be attributed that violet, blue, and green (darker colors), respectively have shorter wavelengths than yellow, orange, red (brighter colors), respectively having longer wavelengths.
- yellow
- orange
- red
Similarly, amongst the longer wavelengths, we associate yellow with caution and
yield. Less of an emergency but still a priority. orange we can see as a neutral
between the two long wavelengths, which serves its purpose as a more neutral
emergency but still unsettling as we can't tell which way it could go (lighter
to yellow, or darker to red)
- violet
- blue
- green
Short-wave colors, on the other hand, the more dark colors which may or may not include achromatic colors, which ironically means "without color."
A literal translation of Achromatic is "without color." Taking into n
- gray
- black
- white
GitHub's label color defaults are actually interesting, as you have the option to use a dark tint of a specified color or its respective dark tint. These different tints of colors can act as the contrast between severity and gentility.
As humans, we generally associate certain colors with certain emotional bonds.
As an example when we think of red we think of love, sex and fire, but we also
see it as urgent, emergent, or error.
- yellow (refactor, trivial, open, in review)
- orange (security, performance, major, minor, in progress)
- red (bug, blocker, critical, blocked)
- violet (free)
- blue (free)
- green (enhancement, update, accepted)
- gray (documentation, help, abandoned, invalid, duplicate)
- black (reserved for release number or version)
To ensure better separation, we can use different tints of these colors in order to differentiate between top-level categories (type, priority, etc).
| color | darkest | darker | * | lighter | lightest |
|---|---|---|---|---|---|
| yellow | refactor | in review | trivial | open | discussion |
| yellow |  |
 |
 |
 |
 |
| orange | major | in progress | performance | security | minor |
| orange |  |
 |
 |
 |
 |
| red | critical | bug | blocker | blocked | |
| red |  |
 |
 |
 |
 |
| green | enhancement | feature | update | ||
| green |  |
 |
 |
 |
 |
| gray | help | documentation | abandoned | duplicate | invalid |
| gray |  |
 |
 |
 |
 |
- bug
- enhancement
- discussion
- feature
- regression
- security
- performance
- documentation
- refactor
- update
- blocker
- critical
- major
- minor
- trivial
- in discussion
- in progress
- in review
- open
- abandoned
- accepted
- invalid
- duplicate
- blocked
GitHub Issue's does not provide a very intuitive way to bulk create or import labels. However, there are numerous open-source modules that serve this very purpose. Some of which accept templates.
MIT