Different teams might want to deal with this situation in different ways. You are saying: all tasks in a subproject must be added to the parent project as well. Others might prefer the current situation, where tasks in a subproject are not "duplicated" in a parent project.

For instance, this is what we are doing in the Phabricator project. As soon as a task is defined as "Code-Review" or "Project-Management", we usually place them in these subprojects only, removing them from "Phabricator" unless for some reason we want to keep it as a reminder. This keeps the parent project backlog still usable, allowing us to put some attention to the tasks that are not placed in some other subproject.

In T859#14519, @Qgil wrote:

Different teams might want to deal with this situation in different ways. You are saying: all tasks in a subproject must be added to the parent project as well. Others might prefer the current situation, where tasks in a subproject are not "duplicated" in a parent project.

For instance, this is what we are doing in the Phabricator project. As soon as a task is defined as "Code-Review" or "Project-Management", we usually place them in these subprojects only, removing them from "Phabricator" unless for some reason we want to keep it as a reminder. This keeps the parent project backlog still usable, allowing us to put some attention to the tasks that are not placed in some other subproject.

Sure, but for the projects I listed the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.

Umbrella projects: If you don't want to spend time manually adding super-projects to task in projects there needs to be some rule or even code to automatically do that...

In general we prefer to keep the Bugzilla-to-Phab import code simple and not handle project rename requests in there.

In T859#14534, @Aklapper wrote:

Umbrella projects: If you don't want to spend time manually adding super-projects to task in projects there needs to be some rule or even code to automatically do that...

Sure, that's what Herald is for. :-)

In general we prefer to keep the Bugzilla-to-Phab import code simple and not handle project rename requests in there.

Yeah, fine for T856: VisualEditor / General project should be imported as simply "VisualEditor" to be fixed manually by me after the migration. If necessary, I can fix this request manually too after the migration, but….

Also, wouldn't the right solution be to move the "General" tasks to the main project and then archive the "General" project?

In T859#14564, @Qgil wrote:

Also, wouldn't the right solution be to move the "General" tasks to the main project and then archive the "General" project?

Yes, that's what T856 said. Except that there is no "main project"; "General" is the principal project.

In T859#14527, @Jdforrester-WMF wrote:

the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.

I'm not sure a list with ~8000 bugs is useful to "triage me" anything. Besides, you can just get that list with a saved search query whenever you need it.

In T859#14800, @Qgil wrote:

In T859#14527, @Jdforrester-WMF wrote:

the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.

I'm not sure a list with ~8000 bugs is useful to "triage me" anything. Besides, you can just get that list with a saved search query whenever you need it.

No.

All new VE bugs go into the VE mega-project (with a status of "Needs triage"). As part of the triage, it will be given a priority and added to one or more projects of which it's a part – e.g. "VisualEditor MediaWiki integration" or "VisualEditor table editing" or "VisualEditor ContentEditable" or "VisualEditor performance" or whatever.

Most people will care about a particular feature or aspect of functionality, and so will only follow those particular projects. A few people, like the development team leadership, will want to see the overall priorities across the whole of the VisualEditor mega-project to decide whether to pull resources from one area and put it into another. The ACL for merge/etc. access will also belong to members of the VisualEditor mega-project (probably), as more fine-grained control is not needed and locking-down controls is against our general ethos at Wikimedia.

Does this make sense?

I still don't see why you cannot do what you explain with the search query I'm proposing.

Let me explain you the situation of the Wikimedia Phabricator team, which is very similar to your case. We don't have a mega-project. In most cases, tasks that can go to a specialized project are not listed under "Phabricator". If we want to triage tasks tasks regardless of the subproject they are in, we only need to query https://phabricator.wikimedia.org/maniphest/query/q47HlqJVpTSy/

One list, all tasks, grouped by priority. And still someone can go to "Phabricator" and get a sane list of tasks, because we are not duplicating by default. We did that at the beginning, and it didn't take long before we moved away. If we want to aggregate, we can use saved queries, leaving the default/general projects genuinely for tasks that don't fit anywhere else (just like you have in Bugzilla, btw).

PS: ACL has nothing to do with this discussion, and I suspect it doesn't work as you think it works. See https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Policy

In T859#15771, @Qgil wrote:

I still don't see why you cannot do what you explain with the search query I'm proposing.

[Snip]

The number of sub-projects inside VisualEditor changes quite frequently. Right now they are tracked by a combination of Bugzilla tracking bugs (mostly for features) and Bugzilla components (for code areas and types of problem). On average I'd say a new project comes along every month or so.

Because the saved searches for Phabricator work the way they do, this means that every month or so we'd need to ping out an e-mail to everyone who might care about VisualEditor telling them to forget the old search URL and use a new one. The only way to work around this, AFAIAA, is to cheat with a mega-project that is added to everything anyway.

I'm sure you've considered this and decided that for Phabricator you don't need it, which is awesome, but some of us do. :-)

PS: ACL has nothing to do with this discussion, and I suspect it doesn't work as you think it works. See https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Policy

Well, no. The team "VisualEditor" will have special status in the ACL of the "VisualEditor" repos but probably not needed in the ACL of the "VisualEditor" project's tasks. Probably.

Cf. T100, T72, T101 on subprojects and parent projects.