Skip to content

tpa cleanup

anarcat requested to merge (removed):tpa-cleanup into main

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 severity and priority labels.

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:

https://web.archive.org/web/20200618142059/https://trac.torproject.org/projects/tor/wiki/org/teams/SysadminTeam

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!

Edited by anarcat

Merge request reports