RickCogley · December 28, 2014 19:53
diff --git a/GitHub issue label .txt b/GitHub issue label .txt

 The trickiest thing to get right is the labels. One that worked well for us is the idea of two-dimensional labelling (i.e. every issue has two labels):

 Severity label: these labels have colors to make them visually identifiable. It’s important to not have too many of these, to make the choice easy, here are some suggestions:
 blocking: drop everything you’re working on, this needs to be fixed today (we also had “überblocking” for extremely severe issues)
 critical: this should be the next thing to work on, should be fixed within a few days
 high priority: important to work on
 low priority: if you have some spare time this would be nice to have.
 Component label: which aspect of the project the issue related to, such as “debugger”, “dashboard” etc.
 The labels are assigned by the reporter and adjusted (if necessary) by quality assurance people or the product/project manager

	The trickiest thing to get right is the labels. One that worked well for us is the idea of two-dimensional labelling (i.e. every issue has two labels):

	Severity label: these labels have colors to make them visually identifiable. It’s important to not have too many of these, to make the choice easy, here are some suggestions:
	blocking: drop everything you’re working on, this needs to be fixed today (we also had “überblocking” for extremely severe issues)
	critical: this should be the next thing to work on, should be fixed within a few days
	high priority: important to work on
	low priority: if you have some spare time this would be nice to have.
	Component label: which aspect of the project the issue related to, such as “debugger”, “dashboard” etc.
	The labels are assigned by the reporter and adjusted (if necessary) by quality assurance people or the product/project manager