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?

Should we simply merge T87372 here?

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

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

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?

we'll sync up :)

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?

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.

Ping?

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.)

In T89270#1032542, @Legoktm wrote:

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

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

In T89270#1236279, @Aklapper wrote:

• 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 :/

Summarizing:

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 wikitech.wikimedia.org (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 wikitech.wikimedia.org 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 wikitech.wikimedia.org (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.

• I added the Labs project to all open/stalled Wikimedia-Labs-General tasks.
• I archived Wikimedia-Labs-General and updated its project description to use Cloud-Services instead. (jeremyb, scfc and Andrew listed as Wikimedia-Labs-General's members/watchers were also already members/watchers of Cloud-Services.
• Q: I don't know if I should also add it to 158 closed Wikimedia-Labs-General tasks? (Might create notifications.)

• 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-Other to VPS-Projects

• renamed #Wikimedia-Labs-wikitech-interface to wikitech.wikimedia.org (because "wikitech" can also refer to a mailing list or wiki technology in general, plus the dev.wikimedia.org has a similar full URL scheme)

Alright.

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 ? wikitech.wikimedia.org ? 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 :)

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.

In T89270#1245165, @Aklapper wrote:

Alright.

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 ? wikitech.wikimedia.org ? LabsDB-Auditor ? Others?

Yes, at least those.

• Triage / clean up tickets under Cloud-VPS

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': https://phabricator.wikimedia.org/project/sprint/board/832/query/dzMIg5Q12dHe/

• I've edited H28:
  • When all of these conditions are met:
    • Projects include any of Cloud-VPS, Toolforge (as discussed in T89270#1368792), wikitech.wikimedia.org, LabsDB-Auditor
  • Take these actions the first time this rule matches:
    • Add projects Cloud-Services
  • This will NOT retroactively add existing tickets. Anyone with acl*Batch-Editors membership can batch-edit existing tasks in those projects to add #Labs to them.
• To do: Somebody (who?) to triage >120 tasks in https://phabricator.wikimedia.org/tag/labs-infrastructure/
• Not renaming "Labs-Vagrant" to "Vagrant-Labs", as discussed.

In T89270#1374717, @Aklapper wrote:

• This will NOT retroactively add existing tickets. Anyone with acl*Batch-Editors membership can batch-edit existing tasks in those projects to add #Labs to them.
• To do: Somebody (who?) to triage >120 tasks in https://phabricator.wikimedia.org/tag/labs-infrastructure/

Anybody planning to take these two items?