trim some fat - sub-labels are used too infrequently

Issue-Labelling.md

@@ -1,11 +1,7 @@
 # Meaning of the Labels
 
-- **feature** - new end user functionality, available sublabels for estimates:
-  - **estimate/hours**, **estimate/days**, **estimate/weeks** - ballpark estimate for feature
-- **bug** - broken end use or developer functionality; not working as the developers intended it, available sublabels for priority:
-  - **bug/P0** - Urgent issue that caused someone to be paged, must be updated hourly
-  - **bug/P1** - High impact issue, must be updated daily, must be resolved before resuming milestone work
-  - **bug/P2** - Issue is affecting users, should be resolved before resuming milestone work
+- **feature** - new end user functionality
+- **bug** - broken end use or developer functionality; not working as the developers intended it
 - **techdebt** - unpleasantness that does (or may in future) affect development
 - **chore** - refinement / improvement of end user or developer functionality, or new developer functionality
 - **dogfood** - important for the developer's own use of the project
@@ -26,7 +22,7 @@ NB: suggestions for refining the above explanations based on edge cases / exampl
 There are a few guidelines to follow when labelling issues:
 
 - every issue should be labelled with exactly one of 'feature', 'bug', 'techdebt', 'chore' (aka "category labels")
-- apply other labels as appropriate (component, estimates, bug priority); avoid attaching a large number of labels - that typically indicates that the issue should be split up
+- apply other labels as appropriate, in particular component; avoid attaching a large number of labels - that typically indicates that the issue should be split up
 
 # Creating a new Label