To be clear, I'm looking for advice what's the best way to track these issues and help to implement that.

Currently there are hundreds of subtasks of this task. This makes it very hard to browse them and see what's open.

Indeed. Workaround: https://phabricator.wikimedia.org/maniphest/query/fHGV6TWVhlBY/#R lists them.

To document the current situation:

translatewiki.net currently says:

"Work by translatewiki.net (staff) which does not fall into any extension code, like server configuration, pet projects, writing new deployment system and so on."

and currently has the workboard columns:

• Backlog;
• New projects for translation;
• Configuration changes;
• Processes;
• System admin stuff;
• Features;
• External

T41480 says:

"Permanent tracking bug for bugs affecting translatewiki.net most, starting with those which flood us with errors. The following must not be added to blockers: reports against components maintained by people in TWN core staff (particularly Translate); tasks explicitly assigned to the TWN staff by addition to the translatewiki.net project.
These are usually bugs either in (the last revision of) MediaWiki or in its compatibility with frequently used extensions such as Semantic MediaWiki and LiquidThreads, so they should probably taken care of before the following release."

Regarding translatewiki.net, I'm not sure what "which does not fall into any extension code" means exactly as I see extension tasks tagged with MediaWiki-extensions-CLDR or MediaWiki-extensions-Translate there.

Regarding T41480, I am not sure what "blockers" means exactly.

Could the subtasks of T41480 be in the "External" column, or do I misinterpret its meaning?

I would like to keep the work we translatewiki.net folks do separate from the issues we notice in "upstream" code while operating a MediaWiki instance.

Benefits for keeping them separate:

• One can watch translatewiki work without being spammed with all those "upstream" bug reports.
• One could watch our "upstream" tag as early warning system for possible train blockers.
• There is single URL/place I can give to MediaWiki developers who want to help or just show how much "upstream" issues we have to deal with.
• I could use columns for categorizing the issues by further like logspam/minor bugs/major issues/worked around/waiting to be confirmed or core/extensions.

There are some blurry lines: sometimes I/we have to fix those upstream issues ourselves, or sometimes the issues are in Translate extension, for example. But they could still be tagged upstream issues.

In translatewiki.net we mostly track work that involves the translatewiki repository or stuff inside the wiki or system admin tasks.

Hmm I see. Sounds like two separate tags to me then. Something like #translatewiki.net-Infrastructure (or such; currently #translatewiki.net) and #translatewiki.net-external (currently T41480) basically?

Yeah two tags. And naming is hard.

I also prefer the approach of having multiple tags rather than a single one. The proposed columns under the new external project tag also sound good.

Okay, we need to settle on a name here I guess. After that I could proceed.

I was thinking what similar tags already exist. Wikimedia-production-error is very similar. If we use that pattern, it would be #translatewiki.net-production-error.

I am not sure about the name #translatewiki.net-production-error. By the name itself it is difficult to understand that it contains external issues affecting Twn.

The scope for Wikimedia-production-error says:

• Errors logged server-side (syslog, Logstash, mwlog, stderr), typically browsed via Kibana (if indexed).
• JavaScript errors logged to browser consoles.

Which I think is different than the scope of our tag.

Most of our issues are what I call logspam. Another option would be #translatewiki.net-mediawiki-error if the word production is troublesome. Strictly speaking, there are other projects tracked here in Phabricator that we use, like keyholder, which we might encounter issues.
We could just copy the task name #affects-translatewiki.net - if that isn't too uncovential name for a task?

I'm fine with #affects-translatewiki.net and maybe renaming translatewiki.net to translatewiki.net-server or something like that? Shrug, I'm basically still wondering how someone who wants to file a task has less problems to find the right project tag out of these two.

Also note that the first sentence (until a full stop appears) of a project tag description is shown in the project tag search results (once you've clicked the magnifier icon in the "Project Tags" field), so you may want to think how to phrase that first sentence for both tags.

I'd not rename #translatewiki.net. It being the shorter name, I expect people to automatically pick that one.

Alright. Guess we have consensus.

I prefer #affects-translatewiki.net as well.