tpa cleanup
TL;DR: remove most labels in @tor/tpa/services, keep about 20, excluding those from @tpo, which we can hopefully get rid of.
We try to minimize the number of labels in the services project. With
this, if it works like I think it does, we would end up with about 20
labels, not counting the global @tpo ones. We keep the current components from trac as (shortened) labels and add a few (like gitlab, gitweb, nextcloud, dns, and ldap).
It would be great if we could remove those @tpo labels from our
project(s). I have uncommented and added them to the delete section
to signal that, but I understand if that would not be
possible.
Unfortunately, that is kind of the deciding factor in gitlab#10: if we have ~20 labels, mostly components, then it makes sense to use labels to sort issues. But if we have double that (because of the ~20 more labels from @tpo), it would be much more difficult to users to find components in our listings.
So for now, assume the best and that we can use labels for
components. We do create a few new components from existing labels: I
think those would be useful, in general, but they do overlap with
the sysadmin label which is meant to distinguish between "service
admins" and "sysadmin" stuff.
We also aggressively get rid of priority and severity labels,
along with version, status, actualpoints, points, milestone,
owner, parent, reporter, resolution, and reviewer. To quote
from the YAML:
i have a particular pet peeve with the
severityandprioritylabels.severity, in particular: what information does it give us? if I am looking at a ticket, and it's labeled "minor" or "normal", does that mean it's easier to do than a "major" ticket? what is the distinction between "blocker", "critical", and "major"? why should that matter? what if there's a "blocker" that is "very low" priority? how can this ever make sense?
So instead of playing that crazy game, just drop those labels completely and embrace the fact that everything is high priority. some is just more high priority than others, and that's the stuff that's on top of the kanban pile. and if it's not on the top of the stack, someone should bring it up there
We completely drop the keywords fields (with some carefully picked
exceptions) as the information there is mostly garbage, or at least
not something that is useful when creating new issues. That
information is still available in the issue comments and description
for future reference, if that's ever needed.
Finally, we also drop the tpa-roadmap-* labels, as those are
replaced by kanban boards. That is some information loss as some
labels were still in use (november and october are particularly
relevant) but that information is archived in Trac and in:
I noticed a typo (tap-roadmap-may) -- which really shows the problem
with freeform fields -- and added that ticket (services#34122)
back into our backlog so it resurfaces in our roadmap (!).
Phew! Thanks for organizing this!