Page MenuHomePhabricator

Imported items in actual sub-projects (VE, Parsoid, others?) should be tagged against the super-project too
Closed, DeclinedPublic

Description

All the items in https://bugzillapreview.wmflabs.org/tag/visualeditor-data_model/ should also be in the main VisualEditor project, which is currently called https://bugzillapreview.wmflabs.org/tag/visualeditor-general/ (and per T856: VisualEditor / General project should be imported as simply "VisualEditor" won't be re-named until after the import).

I support the ~8000 bugs could all just be mass-added(?) after the import, but this feels like a perfect opportunity to get it done right from the start.

Event Timeline

Jdforrester-WMF raised the priority of this task from to Needs Triage.
Jdforrester-WMF updated the task description. (Show Details)
Jdforrester-WMF changed Security from none to None.
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

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.

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?

Qgil triaged this task as Low priority.Oct 24 2014, 5:58 PM
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.

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:

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.

Qgil claimed this task.

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.

According to your previous post, this query was meant to be used basically by the development team leadership. Even if not, I personally think that a query URL posted and updated at the parent project description would be more useful than flooding the parent project with >1000 tasks. HOWEVER, none of this really matters. You are the product owner and you decide how you want to organize your projects. :)

Back to the initial request, it looks clear at this point that tagging tasks also against a super-project is more a particular approach than a solution for everybody. Therefore, we will not touch the migration script, and we will leave this decision to project owners, who can do this manually pretty easily with batch edits.

Resolving as Declined.

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