Summary: create a bunch of labels or projects to regroup issues for all documented services, clarify policy on labels (mostly TPA services) vs projects (git, external consultants) usage.

• Background
  • Goals
    • Must have
    • Nice to have
• Proposal
  • Scope
  • Current labels
  • New labels
  • Current projects
    • New projects
• Personas
  • Anathema: the sysadmin
  • Wouter: the webmaster
  • Petunia: the project manager
  • Charlie, the external consultant
  • Mike, the service provider
  • George, the GitLab service admin
• Alternatives considered
  • All projects
  • All labels
  • Both project and label
• References

Background

Inside TPA, we have used, rather inconsistently, projects for certain things (e.g. tpo/tpa/gitlab) and labels for others (e.g. ~Nextcloud). It's unclear when to use which and why. There's also a significant number of services that don't have any project or label associated with them.

This proposal should clarify this.

Goals

Must have

• we should know whether we should use a label or project when reporting a bug or creating a service

Nice to have

• every documented service in the service list should have a label or project associated with it

Proposal

Use a project when:

• the service has a git repository (e.g. tpo/tpa/dangerzone-webdav-processor, most web sites)
• the service is primarily managed by service admins (e.g. tpo/tpa/schleuder) or external consultants (e.g. tpo/web/civicrm) who are actively involved in the GitLab server and issue queues

Use a label when:

• the service is only (~DNS) or primarily (~Gitlab) managed by TPA
• it is not a service (e.g. ~RFC)

Scope

This applies only to TPA services and services managed by "service admins".

Current labels

TODO: should we add an "issues" column to the service list with this data?

Those are the labels that are currently in use inside tpo/tpa/team:

New labels

Those are labels that would need to be created inside tpo/tpa/team and linked in their service page.

Note that undocumented and retired projects do not currently have explicit labels or projects associated with them.

Current projects

Those are services which currently have a project associated with them:

New projects

Those are services that should have a new project created for them:

Personas

Anathema: the sysadmin

Anathema manages everything from the screws on the servers to the CSS on the websites. Hands in everything, jake-of-all-trades-master-of-none, that's her name. She is a GitLab admin, but normally uses GitLab like everyone else. She files a boatload of tickets, all over the place. Anathema often does triage before the triage star of the week even wakes up in the morning.

Changes here won't change her work much: she'll need to remember to assign issues to the right label, and will have to do a bunch of documentation changes if that proposal passes.

Wouter: the webmaster

Wouter works on many websites and knows Lektor inside and out. He doesn't do issues much except when he gets beat over the head by the PM to give estimates, arghl.

Changes here will not affect his work: his issues will mostly stay in his project, because most of them already have a Git repository assigned.

Petunia: the project manager

Petunia has a global view of all the projects at Tor. She's a GitLab admin and her mind holds more tickets in her head than you ever will even imagine.

Changes here will not affect her much because she already has a global view. She should be able to help move tickets around and label everything properly after the switch.

Charlie, the external consultant

Charlie was hired to deal with CiviCRM but also deals with the websites.

Their work won't change much because all of those services already have projects associated.

Mike, the service provider

Mike provides us with our Nextcloud service, and he's awesome. He can debug storage problem while hanging by his toes off a (cam)bridge while simultaneously fighting off DDOS attacks from neonazi trolls.

He typically can't handle the Nextcloud tickets because they are often confidential, which is annoying. He has a GitLab account so he will be possibly happy to be able to do triage in a new Nextcloud project, and see confidential issues there. He will also be able to watch those issues specifically.

George, the GitLab service admin

George is really busy with dev work, but really wanted to get GitLab off the ground so they helped with deploying GitLab, and now they're kind of stuck with it. They helped an intern develop code for anonymous tickets, and triaged issues there. They also know a lot about GitLab CI and try to help where they can.

Closing down the GitLab subproject means they won't be able to do triage unless they are added to the TPA team, something TPA has been secretly conspiring towards for months now, but that, no way in hell, will not happen.

Alternatives considered

All projects

In this approach, all services would have a project associated with them. In issue tpo/tpa/gitlab#10, we considered that approach, arguing that there were too many labels to chose from so it was hard to figure out which one to pick. It was also argued that users can't pick labels so that we'd have to do the triage anyways. And it is true that we do not necessarily assign the labels correctly right now.

Ultimately, however, having a single project to see TPA-specific issues turned out to be critical to survive the onslaught of tickets in projects like GitLab lobby, Anon ticket and others. If every single service had its own project, it would mean we'd have to triage all those issues at once, which is currently overwhelming.

All labels

In this approach, all services would be labels. This is simply not possible, if only because some service absolutely do require a separate project to host their git repository.

Both project and label

We could also just have a label and a project, e.g. keep the status quo between tpo/tpa/gitlab and ~Gitlab. But then we can't really tell where to file issues, and even less where to see the whole list of issues.

References

This proposal is discussed in issue tpo/tpa/team#40649. Previous discussion include:

• issue tpo/tpa/gitlab#10, "move tpa issues into subprojects or cleanup labels"; ended up in the status quo: current labels kept, no new subproject created
• issue tpo/tpa/gitlab#55, "move gitlab project back into tpo/tpa/team"; ended up deciding to keep the project and create subprojects for everything (ie. reopening tpo/tpa/gitlab#10 above, which was ultimately closed)

See also the TPA-RFC-5: GitLab migration proposal which sets the policy on other labels like ~Doing, ~Next, ~Backlog, ~Icebox and so on.