Page MenuHomePhabricator

Migrating projects to subprojects for Apps teams
Closed, DeclinedPublic

Description

There are projects that the Android and iOS teams use to categorically track their tasks. These include:

Android-app-feature-Navigation
#android-app-feature-navigation-mvp
Android-app-feature-Feeds

and

iOS-app-feature-iPad
iOS-app-feature-Offline
iOS-app-feature-Namespaces
iOS-app-Bugs
iOS-app-feature-Saved
iOS-app-feature-TopRead
iOS-app-feature-Performance
iOS-app-feature-WP0
iOS-app-feature-TOC
iOS-app-feature-Accessibility
iOS-app-feature-Analytics
iOS-app-feature-Links
iOS-app-feature-Multilingual
iOS-app-feature-Notifications
iOS-app-feature-Places
iOS-app-feature-Database

One downside of having all of these projects is that sometimes users file tasks against them, rather than Wikipedia-iOS-App-Backlog or Wikipedia-Android-App-Backlog where the teams can triage. This causes the tasks to fall out of process and get ignored.

Android has mitigated this via Herald (H168), but it's an inelegant approach because it must be manually updated. iOS is considering a Herald rule, too.

An alternative approach would be to have these projects as subprojects of the Apps teams parent backlogs. My understanding is that by doing so, tasks tagged with the subproject will automatically receive the parent project.

Thoughts from the Project Admins?

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 29 2016, 7:42 PM

@mmodell I was told you might be able to migrate projects to subprojects, and would welcome your thoughts here. :)

Danny_B triaged this task as Low priority.Jun 30 2016, 11:05 PM

It occurs to me that subprojects do not automatically tag their parent project for tasks tagged with the subproject, so herald may be necessary anyway.

It occurs to me that subprojects do not automatically tag their parent project for tasks tagged with the subproject, so herald may be necessary anyway.

What would be the usecase? It's impossible anyway due to what subprojects are.

@Aklapper The use case is that the each of the teams have one board that aggregates all of their tasks (their backlog). The component projects exist so that they can sort/filter their backlogs more easily (or use the component project board to do work breakdown, a la Android-app-feature-Feeds). Sometimes, when new tasks are filed (especially from outside the team), the backlog is not tagged, so nobody actually sees the tasks (they are only looking at the main backlog, otherwise they would have to maintain too many project boards). Herald 168 mitigates this (for Android, anyway), but it's not a sustainable approach. It would be useful if these projects could be subprojects because they technically are already (hence the prefixes like "iOS-app-feature-"). More importantly, it would make sense that if a project is part of another existing project, that it would get both tags. Otherwise it's just another project that happens to be a subproject (which isn't much of a feature, IMO).

Milestones do the above, to some degree, but in this case it would be important to maintain column structures that the team uses to organize, so using Milestones just for the tagging would be inappropriate.

It would appear the Herald is necessary. Regardless, it makes sense that these projects would be subprojects of their parent projects (Wikipedia-Android-App-Backlog and Wikipedia-iOS-App-Backlog respectively).

@MBinder_WMF:

Yes I can migrate the projects. This is done with a rough but adequate migration script that upstream provided.

Milestones might make sense but the major limitation with them is that a task can only have one milestone from a given project group. Adding another milestone removes the first one.

The use case is that the each of the teams have one board that aggregates all of their tasks (their backlog).

That's already the case, as all subprojects tasks are also displayed on the parent project workboard in one column per subproject.

More importantly, it would make sense that if a project is part of another existing project, that it would get both tags.

So far I do not think that it would make sense.

That's already the case, as all subprojects tasks are also displayed on the parent project workboard in one column per subproject.

Could you show me an example? As far as I can tell, this is only true for Milestones, not Subprojects.

More importantly, it would make sense that if a project is part of another existing project, that it would get both tags.

So far I do not think that it would make sense.

Example: iOS has iOS-app-Bugs . Someone files a task against it. If the iOS uses that to filter and organize their bugs, but doesn't use that board for workflow (instead using Wikipedia-iOS-App-Backlog ), then they will never see the task. Herald can be made to catch it, but that means updating the Herald every time the team creates a new project for similar filtering.

Does that help clarify?

Could you show me an example? As far as I can tell, this is only true for Milestones, not Subprojects.

@MBinder_WMF: I am sorry. You are right of course!

Does that help clarify?

Yesss! :)

I wonder if this might be a compromise to the issues stated:

This way, the team can

  • maintain its column architecture in Wikipedia-iOS-App-Backlog , and
  • use the Milestones columns in the subproject to organize the tagging, and
  • use Herald for affecting the subproject (and thereby never having to update it, since the Milestones will be created within the subproject)

iOS-app-Bugs could be an exception, as it's own subproject, because it has existing milestones and is unlikely to be changed for the Herald's sake.

Would love to hear your opinions. :)

MBinder_WMF added a comment.EditedJul 19 2016, 7:35 PM

One downside to the above that I have realized is that you cannot cross-tag Milestones of the same project. So if something belongs in iOS-app-Bugs and iOS-app-feature-Accessibility , for example, the above scenario prevents that.

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptAug 2 2016, 7:32 PM
MBinder_WMF closed this task as Declined.Aug 25 2016, 10:17 PM

I don't think this is viable. Herald may have to be the way.

Subprojects do everything you would want EXCEPT for showing up as columns on the parent projects workboard. So if you use maniphest advanced search for the parent project, you will find tasks which are in a subproject.

https://secure.phabricator.com/T10349 discusses some of the reasons behind the current situation and that would be the right place to discuss any improvements that can be made in projects functionality. I suspect that upstream is not planning any more major changes in the near future but I also get the impression that feedback is still solicited.

A parent projects for the app-related projects is very much needed. The current jungle of projects makes searches etc. practically impossible.