For what is worth...

"Phabricator.org" project is for upstream requests, and this is clearly not one.

"Phabricator" project is for specific features and configuration in our instance. I personally think this is not one of these.

"Project-Creators" is a Phabricator related project to work on tasks related with the creation of projects, and I personally think that this is one of these.

"Phabricator.org" project is for upstream requests, and this is clearly not one.

Debatable, but that debate is happening on other reports. Feel free to create another Phabricator subproject for issues with the phabricator.wikimedia.org instance that don't fit your definition of "specific features and configuration in our instance".

[Project organization needs to primarily work for the project owners and Quim explained above the difference. Feel free to search for items under both the Phabricator and Phabricator.org if you are looking for Phab specific tasks.]

Can we just rename MediaWiki-General to MediaWiki-General?

Here's what I've been saying to do (in a couple of places on IRC already). The current MediaWiki-* tags are awful. Instead, we should have a [MediaWiki] project in which bugs about MediaWiki go. We'd then have things like [Database], [Localization], [Editing], [Parsing] that would get applied alongside.

So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database] (or even worse, adding a [MediaWiki-Core]).

The added benefit is that all extensions and other projects will get to use core's general tags like database or javascript for tagging their bugs too.

Once upon a time in Bugzilla we had a catch all component for Mediawiki: MediaWiki -> General-or-Unknown. MediaWiki-General sounds good to me.

In T76942#842969, @bd808 wrote:

Can we just rename MediaWiki-General to MediaWiki-General?

In my plan that's how I'd do it, then additionally add that tag to all MediaWiki-* tagged tasks and then rename their projects to drop the MW-* prefix.

I think this is how it should be done, and I'm personally happy that no less than the MediaWiki team is willing to move in this direction.

In addition to solving the search fragmentation problem, this also will mean that there will be better piles of untriaged tasks: a very big one (but only one) for all MediaWiki related tasks, and then one for each "discipline" (tag), where contributors specialized in that area can help with a first triage regardless of whether they are directly involved in MediaWiki core or not.

One problem to take into account are the mentions to #mediawiki the IRC channel. But well, chances that those mentions are written in MediaWiki-General related tasks are high, and if not, removing the project is easy.

So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]

And how to distinguish that from, say, bugs in some extensions with the usage of the database?

Plus, did we really surrender to the idea that to do a mere search here we'll need to edit tens of thousands bugs to update their tags?

In T76942#848047, @Nemo_bis wrote:

So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]

And how to distinguish that from, say, bugs in some extensions with the usage of the database?

You'd search for [Database] and not [MediaWiki]

Plus, did we really surrender to the idea that to do a mere search here we'll need to edit tens of thousands bugs to update their tags?

It's more than just search imho. I think the current tags are an awful way to organize bugs and my plan gives us a whole lot more flexibility in this area :)

You'd search for [Database] and not [MediaWiki]

Is "and not" allowed in the search, filters and workboard definitions consistently?

In T76942#848206, @Nemo_bis wrote:

You'd search for [Database] and not [MediaWiki]

Is "and not" allowed in the search, filters and workboard definitions consistently?

I see fields to exclude projects in all these places. Let me clarify:

1. Go to advanced search
2. Add "MediaWiki" to "Not in Projects"

In T76942#848212, @Chad wrote:

In T76942#848206, @Nemo_bis wrote:

You'd search for [Database] and not [MediaWiki]

Is "and not" allowed in the search, filters and workboard definitions consistently?

I see fields to exclude projects in all these places. Let me clarify:

1. Go to advanced search
2. Add "MediaWiki" to "Not in Projects"

That's one place, not "all these places". For instance the main search has no "Not in projects". https://phabricator.wikimedia.org/search/query/advanced/

Did you check the search forms of all applications which have knowledge of projects? (I don't even know which those are.)

Creating an MW Core umbrella project

1. So the proposal is to rename MediaWiki-General to MediaWiki-General ? If MW Core team is fine with that I am happy to go ahead.

2. Note that for VisualEditor I set up a Herald rule (H10, but T630):
   
   If "Projects" include any of: {VisualEditor-ContentEditable, VisualEditor-ContentLanguage, ...}, then: Add (umbrella) project "VisualEditor", every time this rule matches. ("every time" means even if someone tries to manually remove the Umbrella project that it would be readded again to a task). Is the same wanted here too?

Renaming MW Core subprojects

Renaming all those MediaWiki-* core subprojects is a separate topic (this task is about searching core tasks). See the list at https://phabricator.wikimedia.org/project/query/all/?after=MediaWiki-a (and ignore some stuff like extensions, "MediaWiki-Developer-Summit-2015" project etc.) for those projects.
If we renamed "MediaWiki-Database" to "Database" this would collide with the Herald rule that I proposed above - any task with projects "MediaWiki-extensions-Foo" and "Database" (named "MediaWiki-Database" beforehand) would get an automatic "MediaWiki" project associated with that rule. I don't think this would be helpful, and if we didn't set up a Herald rule then manually adding the "MediaWiki" umbrella project is not a great use of triage time either.
So with the current situation I'm slightly against using more generic names for those MW core subprojects.

rename MediaWiki-General-or-Unknown to MediaWiki-General

Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it MediaWiki-General, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this. Deleting the project is about as useful.

In T76942#946690, @Nemo_bis wrote:

rename MediaWiki-General-or-Unknown to MediaWiki-General

Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it MediaWiki-General, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this.

It is unclear why "we must" and who we is.
You could search for "In All Projects: MediaWiki" && "Not In Projects: ..." and save that query. Setting that query up is pretty cumbersome though.

So I'd propose creating a MediaWiki umbrella project (like VisualEditor or Multimedia) and creating a Herald rule to automatically add that umbrella project to any of the (newly created) tasks in one of MediaWiki Core's "subprojects".

(Big) But:

• Adding that umbrella project to all existing tasks will create a huge number of notifications. We are talking about roughly already 4800 open tasks here, and for proper search results I'd prefer including also closed ones which means updating approx. 26000 tasks. I am not sure if we could (ab)use a maintenance window (like T86772) and somehow disable mail notifications for that time (@chasemp: Can we do that somehow?), but that's nothing I want to do in "normal mode".
• Adding that umbrella project to all existing tasks via batch-editing will be cumbersome and time-consuming as long as T76152 is not fixed. I could survive that but it'll take some time (26000 / ~100 = 260 actions). Or I need to first play more with / learn Conduit and bots. Meh.

So until these one and a half items are sorted out, we are unfortunately stuck here.

In T76942#946690, @Nemo_bis wrote:

rename MediaWiki-General-or-Unknown to MediaWiki-General

Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it MediaWiki-General, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this. Deleting the project is about as useful.

I disagree with Nemo; renaming sounds like a good idea to me. It won't get filed if the bugs are triaged, and bugs are being triaged.

More important use-case are people filing bugs, who keep accidentally adding them in #MediaWiki-Core-Team (perhaps since that's what pops up when searching for "mediawiki core" project).

Indeed. "Unknown" should not be its own component anymore. We now have the generic "Untriaged" status and/or workboard column for that (depending on the project in question).

However, considering not all components in MediaWiki core have an appropiate place in Phabricator yet (some are simply too niche or don't fit anywhere) a "MediaWiki-Core-Misc" or "MediaWiki-Other" component may be useful. Or perhaps having just "MediaWiki" for those suffices, though I do see a use case for being able to query those at ease (and even have a workboard for it). Doing an exclusion search is imho unacceptable. Also because the list of MediaWiki subcomponents will inevitably change over time, and will keep changing a lot in the short term as we identify more components in MediaWiki and move other things out into libraries.

I've tried to make a complete list of all MediaWiki core components, saved in the profile description of MediaWiki-General: https://phabricator.wikimedia.org/project/profile/135/

In T76942#1287991, @Krinkle wrote:

We now have the generic "Untriaged" status

There is no such task status but a "Needs Triage" priority but the task priority field is not used by every team so that does not entirely sound like the same.

However, considering not all components in MediaWiki core have an appropiate place in Phabricator yet (some are simply too niche or don't fit anywhere) a "MediaWiki-Core-Misc" or "MediaWiki-Other" component may be useful.

"Misc" to me is pretty much the same as "General" which already is part of the current name... but interpretation of words might be different.

I've tried to make a complete list of all MediaWiki core components, saved in the profile description of MediaWiki-General: https://phabricator.wikimedia.org/project/profile/135/

Uh, thanks! I hope we will remember to update that when needed...

I think this discussion deserves to be resurrected now that we have real subproject support in phabricator.

The problem it was blocked on was disabling notifications, right? Having an umbrella project would make sense, with or without subproject support, but Andre has a point about spam.

A question @Nikerabbit asked reminded me of this bug, specifically of the use case: list the I18n tasks filed against a MediaWiki core/MediaWiki extensions component, to have an overview similar to what was provided by SMW on https://translatewiki.net/wiki/Support/Open_requests#MediaWiki .

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Also note that nowadays, a lot of MediaWiki core tasks are under #Core Platform Team and #Core Platform Team Backlog tags. See for example https://phabricator.wikimedia.org/T219524#5070460

In T76942#5214363, @Aklapper wrote:

Also note that nowadays, a lot of MediaWiki core tasks are under #Core Platform Team and #Core Platform Team Backlog tags. See for example https://phabricator.wikimedia.org/T219524#5070460

That seems like an antipattern (if at all intentional).

In T76942#2503522, @mmodell wrote:

I think this discussion deserves to be resurrected now that we have real subproject support in phabricator.

Indeed. I think nowadays the way to go would be converting all current separate #MediaWiki-* parent projects which are about the MediaWiki Core codebase (note that not all are!) to subprojects of a new #MediaWiki or #MediaWiki-Core parent project.
Why a new parent project?

• A task cannot have both the parent project and a subproject of that parent project associated. So if the already existing project called #MediaWiki-General became the parent project and a task is both associated with the #MediaWiki-General project and another now-to-become subproject, we'd have data inconsistency in the database due to T224421.
• Furthermore, when a first subproject is added to a parent project, all of the parent project members shift to the first subproject. Parent projects do not support adding members.

That's why it would probably make more sense to keep the #MediaWiki-General project and not make it a parent project, but instead create a new parent project and make the existing #MediaWiki-General (or #MediaWiki-Misc or whatever to call it) a subproject of that new parent project.

For completeness: A task can have more than one subproject of the same parent project associated (at least when I tested this locally). So there should not be issues having more than one #MediaWiki-* now-to-become subproject associated to a task. (Not the case for milestones but we don't talk about milestones here.)

I hope I did not forget any relevant aspects when I wrote this comment.

In T76942#5405654, @Aklapper wrote:

In T76942#2503522, @mmodell wrote:

I think this discussion deserves to be resurrected now that we have real subproject support in phabricator.

Indeed. I think nowadays the way to go would be converting all current separate #MediaWiki-* parent projects which are about the MediaWiki Core codebase (note that not all are!) to subprojects of a new #MediaWiki or #MediaWiki-Core parent project.

Premising I don't have a 100% big picture of the Wikidata stuff in Wikimedia Phabricator, implementing Sub-Projects makes really sense from me from a Phorge/Phabricator perspective. Everything in the Sub-Projects automatically ends up in the root Project, making any wide search definitively easier, without the need to list all Sub-projects manually.