Page MenuHomePhabricator

Labs' Phabricator tags overhaul
Closed, ResolvedPublic


Right now we have multiple Phabricator tags tracking the work that is happening for or in Wikimedia Labs. However, due to legacy reasons (e.g. Bugzilla) and organic growth, the tags have grown into being quite confusing. Both their scope (Labs team? Labs projects? Tools) and their naming is wildly inconsistent and team planning within WMF is hard.

To sum up, we currently have:

  • Cloud-Services the "team" tag that contains WMF Labs staffers + volunteer admins. Many infrastructure-related tasks are tagged with this tag.
  • Toolforge for the Tool Labs project. Unfortunately, most tasks tagged with that are not tagged with Cloud-Services as well; both projects have their own workboards but are worked on by mostly the same people, which makes team planning difficult.
  • #Wikimedia-Labs-Infrastructure which has Labs infrastructure-related tasks. Most tasks there are not tagged with Cloud-Services either :(
  • Wikimedia-Labs-General & #Wikimedia-Labs-Other, with a distinction that very confusing even to old-timers (also see T87372).
  • #Wikimedia-Labs-wikitech-Interface for requests (wikitech isn't just Labs though and may not have OpenStackManager at all soon, so it's really confusing)
  • VPS-project-Wikistats & #Wikimedia-Labs-extdist (& possibly others); this is for specific Labs projects that have nothing to do with the Labs team, despite the similarity in namespace. Other projects have completely differently-named tags, such as Beta-cluster.
  • #tool-labs-tools-* (e.g. Tool-Article-request ), similar to the above but for Tools.
  • Labs-Vagrant which has nothing to do with neither the Labs team nor a specific Labs project but is something more generic.
  • Others?

I propose:

  • Everything that the Labs team is/should be working on should be tagged with Cloud-Services. This is actually a hard requirement for team-planning/prioritization purposes within the WMF structure.
  • Toolforge should probably remain a project-tag.
  • ☑ #Wikimedia-Labs-Infrastructure should be renamed to Labs-Infrastructure and converted into a yellow tag. All tasks tagged with it should also be tagged with Cloud-Services and it should be also applied consistently for past tickets as well with a triaging session.
  • Wikimedia-Labs-General should be dropped entirely. Every task there should be tagged with just Cloud-Services instead.
  • ☑ #Wikimedia-Labs-wikitech-Interface should probably be converted into a yellow tag and be renamed to 'Wikitech'. Its description should mention MediaWiki-extensions-OpenStackManager for software-related bugs / features, rather than operationsl issues.

Things I'm not yet sure about:

  • Labs-Vagrant … maybe rename to "Vagrant-Labs"? It sounds silly but it's really more of a Vagrant project than a Labs project.
  • ☑ #Wikimedia-Labs-Other … I'm not sure about this at all. What is it being used for now? We could name it something like #Labs-project (suggestion for a better name is welcome) and make it a yellow tag. One thing I know for sure is that tasks there should not be tagged with Cloud-Services (unless there's some dependency on the Labs infrastructure).
  • VPS-project-Wikistats & #Wikimedia-Labs-extdist should probably be named just "wikistats" and "extdist". Or something like that. Those projects are hardly about Labs at all. Not sure, though.
  • #tool-labs-tools-*. Maybe rename to just #tool-*? In any case, like above, no Herald rules to tag with Cloud-Services — this is about individual teams working on Tools, not the main Labs team.

I'd like to solicit feedback for this and form a plan forward, especially from the Labs team, Labs volunteers & the ECT team (@Qgil, @Aklapper in particular). This is not yet actionable.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

This all sounds good to me. I could quibble over the names but I won't because it's all arbitrary anyway.

Strongly agree that wikimedia-labs-other should die. Maybe we could do something like

"labs-project-<whatever>" for specific labs projects
"labs-project" for things that are about specific labs projects but don't deserve their own tag yet

and a similar prefix/bare-prefix scheme in tools?

Wikimedia-Labs-extdist is for bugs about the "extdist" project in labs ( Renaming it to "Labs-project-extdist" is fine with me.

All of those sound sane to me, including @Andrew's suggestion re labs-project-*

Aklapper triaged this task as Medium priority.Feb 12 2015, 2:32 PM

I think sufficient time has passed for comments and response has been positive. I think we can just implement this — the sooner the better :)

Is that why you claimed the task, @Aklapper?

I know @chasemp has some scripts to facilitate mass renames/additions/removals like this. Maybe you should coordinate this with him? How can I help?

All seems good to me.

One (minor?) quibble I have would be to have ToolLabs also auto-add Labs to it. I personally see those two as somewhat distinct - there is *some* overlap, but a lot of toollabs stuff doesn't really have relevance to labs as a whole. An analogy might be how every bug for MW extensions don't get tagged with MW tag itself - ToolLabs lives on top of Labs, and sometimes fixing ToolLabs involves fixing things in labs, but mostly not. This would also clutter up the general labs workboard.

So everything *except* the herald rule, perhaps.

Also, including tools creates other inconsistencies. Do you include beta as well? If so, that's just a lot of noise, and the Labs team board becomes less useful. If not, why not?

So, who's implementing that then?

My guess is @Aklapper resigned as he doesn't know the answer to @yuvipanda's questions and this feels like a still in discussion task. Not really following all the the labs work diligently I am not sure myself. If someone could edit the description with a final "action" plan about what needs to be done here I think @Aklapper and myself will knock this out. That has been a common pattern for bikeshedding type things, we usually try to put the absolute and final outcome in the description. maybe @Andrew or @yuvipanda could do this?

hashar set Security to None.

I'm fine with either, although the points raised by @yuvipanda make sense. I would say "do without the automatic tagging and we'll add it if it turns out to be needed in practice"

I've edited the description a bit, please feel free to disagree / revert.

I think that tools and beta tickets should probably /not/ add labs by default; those tasks which bubble up into the labs infrastructure can have that tag added manually.

Assigning to me again (temporarily unassigned it to avoid cookie-licking) and I need to take a look at this and sort out my thoughts - anyone please feel free to steal this from me.
Please also see T90491: Create policy projects and convert people projects to open.

We discussed this in the phab meeting today and it's on the radar. @chasemp has built a tool that can help with this cleanup, we just need to figure out how and when we are going to make time to get this all straight.

Oh my. This is quit a mess. I wasn't aware of this ticket when I created XTools and started adding tickets to it. Please let me know if there is anything I need to do to clean up after myself, and I will happily do so.

Ping? It's been quite a while.

So to make me finally start with at least some of the many many things in this task (which all sound pretty good as it's a complete mess):

  • I triaged the open #Wikimedia-Labs-other tickets. Two remaining, I'm on them. I want to archive/close that project.
  • Unrelated: I archived/closed Utilities-Other project (unrelated but the mess of calling everything a "tool" came back up in my mind and those issues already in BZ).
  • I updated the description of Wikimedia-Labs-wikitech-interface to mention "operational issues" and it now mentions MediaWiki-extensions-OpenStackManager.
  • Sent an email to rlane about the many tasks still assigned to him (having real people as default assignees for a Bugzilla component was a bad bad idea that predates me)

Would anybody be willing to go through the ~35 open Wikimedia-Labs-wikitech-interface tasks and check which of them should be moved to / associated with the MediaWiki-extensions-OpenStackManager project? (Batch edits might save time.)

Wikimedia-Labs-extdist is for bugs about the "extdist" project in labs ( Renaming it to "Labs-project-extdist" is fine with me.

Thanks; I have renamed #Wikimedia-Labs-extdist to VPS-project-Extdist.

  • Sent an email to rlane about the many tasks still assigned to him (having real people as default assignees for a Bugzilla component was a bad bad idea that predates me)

Mass-unassigned Ryan from his tasks to avoid cookie-licking, as requested by Ryan.

@Aklapper, 1,000,000 thanks for taking this on. I'm happy to review those tasks, although you might have to ping me directly on IRC to remind me to really do it :/


Cloud-Services will be/become the "central" place for planning.

First phase (in April 2015):

  • Clean up and then kill/Archive #Wikimedia-Labs-Other
  • Archive Wikimedia-Labs-General and mass-add all its tasks into Cloud-Services (37 open tasks; 195 total; might create notifications when adding to Cloud-Services )
  • Rename #Wikimedia-Labs-Infrastructure (104 open tasks; 306 total; might create notifications when mass-adding Cloud-Services to them) to Cloud-VPS and convert into a yellow tag
  • Rename #Wikimedia-Labs-wikitech-interface (31 open tasks; 81 total) to (I'm afraid that only "wikitech" let's people associate mailing lists or general wiki technology)

Less urgent stuff, second phase:

  • Question: I'm also wondering if renaming Toolforge to #Tool-Labs-Infrastructure might make people realize it's not about projects on Tool Labs.
  • Question: (Future) Tasks in which projects should also be automatically (via a Herald rule) in the Cloud-Services project? #Wikimedia-Labs-Infrastructure (soon to be Cloud-VPS) for sure. Toolforge maybe. But also #Wikimedia-Labs-wikitech-interface (soon to be a yellow tag)? What about LabsDB-Auditor ?
  • Renaming #tool-labs-tools-* seems to have no urgency (but could be renamed per-project, as done already for e.g. Tool-WMT-bots ).
  • @Technical13: XTools (confusing name) could just be renamed to XTools (like Jupyter-Hub or VPS-project-Wikistats though they are Labs projects and not on Tool Labs).
  • For Labs-Vagrant, I don't see a big issue with its name per se. No-one of the Labs team is "forced" to look at its tasks, but if there is a strong opinion we could rename to #Vagrant-Labs.
  • Make (previous #Wikimedia-Labs-wikitech-interface) a yellow tag?

Question: I'm also wondering if renaming Tool-Labs to #Tool-Labs-Infrastructure might make people realize it's not about projects on Tool Labs.

I think it's fine if people use Tool-Labs if they don't know the relevant project to place the bug. Typically, the people who don't know the relevant project would report issues that can also be solved by TL admins (webservice down, etc), or we can just bump the bugs to the relevant project.

T94359: Provide 'Support request' tool labs project (declined) is somewhat related to that.

  • Added Cloud-Services to all tickets in #Wikimedia-Labs-Infrastructure
  • Renamed #Wikimedia-Labs-Infrastructure to Cloud-VPS.
  • Set up a global Herald rule {H28} to automatically add Cloud-Services to any tasks filed under Cloud-VPS. Herald rules can be adjusted/changed by any Phab admin (due to T630).
  • (I'm not fully convinced by turning it into yellow hence not done yet)
  • Triaging session for Cloud-VPS still needed (please {just do it}).
  • renamed #Wikimedia-Labs-wikitech-interface to (because "wikitech" can also refer to a mailing list or wiki technology in general, plus the has a similar full URL scheme)


What I see left here (I won't have time the next two weeks for these items so I unassign myself from this task to not lick cookies):

  • Define which other projects should automatically add Cloud-Services to their tasks via enhancing H28: Toolforge ? ? LabsDB-Auditor ? Others?
  • Triage / clean up tickets under Cloud-VPS
  • Potentially rename Tool-Labs-Tools-* (I don't see an issue per se currently)
  • Potentially rename Labs-Vagrant to Vagrant-Labs (I don't see an issue per se currently)
  • Potentially rename Tool-Labs-xTools
  • Bikeshed about yellow vs blue project colors :)
Aklapper removed a project: ECT-April-2015.
Dzahn added a subscriber: Dzahn.

removed tag "wikistats" because that has already been renamed from the former labs-related name and wasn't relevant here anymore

Anybody up to make decisions on T89270#1245165 ?
If not this might just be "works enough for me" and get closed.


What I see left here (I won't have time the next two weeks for these items so I unassign myself from this task to not lick cookies):

Yes, at least those.

Yes :)

  • Potentially rename Tool-Labs-Tools-* (I don't see an issue per se currently)

I'd like that as I originally suggested but let's wait from feedback from the Labs team.

  • Potentially rename Labs-Vagrant to Vagrant-Labs (I don't see an issue per se currently)

I'd also like that. This is not a Labs project.

I don't object to anything that Faidon said, except that I'm confused about Labs-Vagrant. There /is/ a feature that allows the application of Vagrant to a labs VM, and that is in a puppet module called 'labs-vagrant'. So if that's what we're talking about... it should keep its name and it /is/ a labs project.

If, on the other hand, people have started classifying everything vagrant-related as 'labs vagrant' then... that's clearly wrong.

Ping? Three weeks passed since my last comment.

We're also missing retroactively tagging e.g. Toolforge tickets with Cloud-Services, as well as Herald rules for these.

Still -1 to tagging Tool-Labs tickets with Labs. Tool Labs is not Labs, and only things that are Labs wide issues should be tagged with Labs.

Also -1 to renaming Labs-Vagrant to Vagrant-Labs - Labs-Vagrant is how it is referred to in all documentation, the puppet roles, etc. Changing just the tag name would cause confusion.

The only issues left I can see are to actually triage the tickets under Labs-Infrastrcuture and Labs (and all the others).

After more conversations with @faidon, I'm ok with auto tagging Tool-Labs tickets with Labs since the Labs tag is is a 'team' tag. I'm still not convinced it's useful, but if it's useful to people outside the Labs team... :)

No auto tagging for Labs-Vagrant, however - perhaps it could auto tag MediaWiki-Vagrant for every Labs-Vagrant ticket?

FWIW, my view is:

  • Cloud-Services is a purple "team" tag. As explained in the task's description from the get-go, I find it very useful to keep track of what the Labs team is working on, could be working on next and has worked on in the past. It can serve as a source of tasks for the Labs sprints, as a metric of how the team's input/output/throughput has progressed over the years etc. It's as useful as other similar people/team tags are.
  • In that sense, there are a bunch of Toolforge (but not Cloud-Services) tasks that the team has been working on, on their work hours and as part of their regular duties. I don't think that's right and I think it should be fixed. I don't have as strong feelings for the automatic tagging via Herald of those. The reasoning for this was/is that Toolforge (the infrastructure) is a foundation project, with a blue/project label, and is one that maintained primarily by the Labs team (staff & volunteers).

Labs-Vagrant can stay — I don't care much about this and let's not create more confusion.

In that case, we should deprecate the Tool Labs workboard, and move all statuses in that board to the corresponding column in the Labs board. People interested in bugs that are related to TL specifically (i.e., myself) can then filter the Labs workboard for tasks that are tagged Tool Labs, and use that as new 'Tool Labs workboard':

Aklapper removed a project: ECT-June-2015.

Anybody planning to take these two items?

Aklapper lowered the priority of this task from Medium to Lowest.Sep 2 2015, 12:34 PM
Aklapper claimed this task.

Done now, as the silence got too loud.

I'll leave that to the Cloud-Services team.

Finally closing this task as resolved. If there's more stuff file new tasks. Cheers.