I like this approach to do labels per project. Well, maybe for example observability could cover Icinga and Shinken and #watchmouse, but it's cool either way to somehow organize the operations tickets better than just everythin in "core-ops" or "ops-requests" like in the past in RT. in RT we had "tags" which were kind of like the labels here, but we didn't use them very much. i remember once we did to tag tickets as #hackathon when we wanted to look at them during a sprint/hackathon, but that's different from subject labels.

works for me, as long as we keep it lightweight and obvious what's going on.
obviously the main flow is inbound requests from users and triaging of those for the on duty person, so the least confusing that is the better

What is left here?

In T1147#787587, @Qgil wrote:

What is left here?

can we go for all lowercase (just labels) names please?

We agreed on Title Case by default for consistency, as much as we agreed on dashes instead of spaces...

https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Name

In T1147#791129, @Qgil wrote:

We agreed on Title Case by default for consistency, as much as we agreed on dashes instead of spaces...

fair enough, we should rename existing ones mentioned in this project then:

diamond, icinga, graphite, hhvm, puppet, swift, varnish

In T1147#939465, @faidon wrote:

Finally, we're (still) thinking of deprecating ops-requests altogether, as well as tagging all of our tickets in different projects with our team tag SRE. Is there an easy way to do this without going through all of them (manually or programmatically) and mailing every subscriber in the process?

(Edited) Mmmm I don't think so, but you can warn the top users to "Ignore" notifications for project changes.

In T1147#939465, @faidon wrote:

• We need a tag for the (Elastic)Search stuff, although I think this may be a "search" team tag with @Manybubbles and @chad for now? They may have one already for the CirrusSearch work and I'm still unsure whether we should have a different one for backend work.

We've been using the CirrusSearch tag for CirrusSearch coding and deploy tasks but i have no objection to creating an Elasticsearch tag and using it for install/maintenance related stuff. There is also a Mediawiki-Search tag but that's more for user facing stuff. I blurs with the CirrusSearch tag to the point where I'm not sure when something should have one tag but not the other.

Elasticsearch already exists.

I like Debs :). With a relevant description generally shorter could be better. I am also partial in the label style project cases of arranging things so that I would search for Operations+Debs tags etc. Similar for mail or LDAP.

Side note related, Right now in order to see all operations related work we would have to search for things in 'Any' with all ops-* projects which with a saved search is pretty easy I think. Then tacking on more narrow categories like deb or elasticsearch to show all of that work across ops. Lots of ways to slice it though.

On this:

Debian packaging was raised on the list, with "Debian-packaging" or "Debs" (I prefer the latter but there's a couple of people on the list preferring the former)

I was thinking what about just "Packaging". That covers not only making packages for Debian but also tasks for getting them upstreamed, documentation, or general packaging cleanup for reprepro even.

Seems general enough to be useful but specific enough to find what we need. We could add a #Debs hashtag as well.

I created:

LDAP
Mail
PyBal

In T1147#943234, @chasemp wrote:

I was thinking what about just "Packaging".

I hope that outside reporters won't file tasks about packaging MediaWiki tarball releases ("Wiki-Release-Team" project exists for that) there. A good project summary will help clarifying.

I created:
Mail

With its current short project description which has no reference to Ops I am afraid that some people might confuse it with the existing "MediaWiki-Email" project: https://phabricator.wikimedia.org/project/view/216/
Improving the project desc is very welcome if you want less irrelevant tasks in that basket. :)

In T1147#946369, @Aklapper wrote:

In T1147#943234, @chasemp wrote:

I created:
Mail

With its current short project description which has no reference to Ops I am afraid that some people might confuse it with the existing "MediaWiki-Email" project: https://phabricator.wikimedia.org/project/view/216/
Improving the project desc is very welcome if you want less irrelevant tasks in that basket. :)

Which is why we should be flattening these projects already. </broken record>

https://phabricator.wikimedia.org/tag/mail/ is hell confusing, please delete or clarify within few days.

In general, it seems most such tags should be renamed and prefixed with Wikimedia-, given they're terribly generic.

"Mail" is gone but with no comment here. What replaced it?

Isn't Wikimedia implied? This is the Wikimedia Phabricator, after all. I do buy the argument that some of these tags are ambiguous with regards to infrastructure and code but on the other hand, the lines aren't always very clear. I think that most of these are fine.

"Mail" is now https://phabricator.wikimedia.org/tag/mail_%5Bplaceholder%5D/ for the time being and we don't need to prefix everything with "Wikimedia". Also see T43.

"mail" as a tag is meant to be generic. It would be given context in conjunction with other tags (preferably not of the 'label' type to associate humans). mail+operations is one thing. mail+fundraising is another. The ability to see all mail related things by going to /tag/mail is intended. So far we have moved over hierarchy in tag form from bugzilla and rt, and (at least within the phabricator team) there has been some handwringing over how tags should be oriented in general. Should it always be foo+bar with distinct small bite tags that need to be collated to provide full context on a ticket, or should each tag be an island with parsable hierarchy embedded. I think we are realizing we need both cases. Tags (yellow) that provide a wide umbrella like "mail" or "ldap" are meant to do so across teams and even functional boundaries. If we end up with things from non-technical people being filed with the "mail" tag that dilute the usefulness then it is time to reassess and factor out into multiple tags. So mail being killed here I don't agree with.

Should we end up with operations-mail, mediawiki-mail, fundraising-mail? All of which would need the additional tag operations, mediawiki, fundraising almost certainly anyways. That makes much less sense than trying out the generic mail tag to me and seeing whether it is too broad in practice.

Fully agreed with @chasemp on the generic names.

On an unrelated note, we also need a couple of new tags for HTTPS-related work: HTTPS as a simple (yellow) tag to tag all HTTPS-related issues (whether ops-related or not) and another one for an HTTPS-by-default milestone HTTPS-by-default. It could be argued that this can be a simple tag as well, a "release" tag or a "sprint"; personally I think release fits best, but I don't care all that much.

+1 to what Chase wrote. Projects with Yellow color and the tag symbol imply that a second component-style project is wanted for such tasks.

Mail should have a description pointing out that MediaWiki's internal emailing functions are in MediaWiki-Email and that mail rather refers to mail issues with Wikimedia servers.

For consistency, Graphite should also become yellow/tag style?

HTTPS brought up by Faidon: Could we tackle the needs of HTTPS in a separate task? Simply because it's messy already (T29946 and #wikimedia-ssl-related exist from Bugzilla) and I'd like to see it less messy / sort that out in a dedicated task.

Yes, please make Graphite a yellow-style tag. I'm fine with your suggestion regarding mail as well, go ahead and implement it.

In T1147#960608, @Aklapper wrote:

HTTPS brought up by Faidon: Could we tackle the needs of HTTPS in a separate task? Simply because it's messy already (T29946 and #wikimedia-ssl-related exist from Bugzilla) and I'd like to see it less messy / sort that out in a dedicated task.

Done: T86063.

As for subteams:

• We agreed on the list to split the operations aspects of fundraising (i.e. mostly @Jgreen's work) into a different project. I was thinking of "ops-fundraising" but Analytics did the same (for @Ottomata's work) already with "analytics-cluster" (previously named "analytics-refinery"). Something consistent would be nice, suggestions welcome :) I'm unsure whether these should be projects or teams, although I'm leaning towards the latter. These would be mutually exclusive to the project ops-core and possibly to the SRE team as well (with the exception of crossover work, obviously)

My vote is for ops-{whatever} or operations-{whatever} -- it's a little clearer when you consider other team's tags 'Fundraising Dash" and "Fundraising-Backlog" etc.

What is specifically left to do / discuss here to close this ticket? Can this be closed as resolved?
Ops-FR is covered in T89160...

A few of my suggestions/requests above haven't been implemented. We have no tags for DBA work yet — I pinged @Springle about it this on Monday, I'll re-ping. OTRS hasn't been done yet either. That's the only two that are left I think, I didn't check thoroughly if there are others…

I did Znuny

+1 to a DBA or Databases tag.

Although given our future includes various databases like MariaDB, Cassandra and Titan-er-some-graphdb, perhaps tags should be specific.