@mmodell, do we have subproject support yet?

@Yurik: Yes, since January.

@mmodell, ah, I found the button, but it gives me a scary warning about converting to parent project and moving all members to subprojects (a bit confusing). On top of that, it warns that it hasn't been fully implemented :)

So yes, all of the above could be subprojects, and the sprint could be made a milestone (thus allowing the sprint to contain items that are otherwise only marked as Maps. Also, Maps could be made a subproject of discovery.

Is it possible to join existing projects as subprojects?

In T137816#2380575, @Yurik wrote:

do we have subproject support yet?

https://www.mediawiki.org/wiki/Phabricator/Project_management#Parent_Projects.2C_Sub-projects_and_Milestones

@Yurik: Let me know if I can help with this.

@ksmith - sure, i'm just scared about pushing the scary "convert to parent" button.

As long as we can restructure projects later, e.g. make Maps the subproject of Discovery-ARCHIVED ( or #interactive ;) ) - i'm fine with structuring it this way.

I can convert existing projects into subprojects / milestones.

The issues with converting to a parent project are real and need consideration:

parent projects (any project that contains any subproject) cannot have members. The membership of a parent project is calculated as the union of all it's subprojects.

Milestones also cannot have any members. They inherit the membership of their parent project.

So all members must join subprojects (not milestones) and the parent of all subprojects can not be directly joined, you must join one of the subprojects.

Milestones appear on their parent project's workboard as a new column. Moving a task into a milestone removes it from the parent project and all other milestines in the same series. The task exists virtually in the parent project as long as it's in a milestone under that project but it can't be in multiple milestones of the same parent at the same time.

Adding team members: @MaxSem, @JGirault, @Gehel - should we convert Maps into a parent project? The current structure of the Maps workboard is already exactly as described above.

@Yurik: So your proposal is that Maps would be a project, and Kartotherian (for example) would become a sub-project. And there would not be any milestones. Right?

Sounds reasonable to me. I (and we in Discovery) haven't had much of a chance to experiment with sub-projects and milestones yet, so it would be great to try them if you think they'll work.

@ksmith, yep, that's the idea. And, as always, the interactive team can be the guinea-pig ))

Wouldn't you want them to be milestones? Subprojects do not appear on the parent-project workboard like milestones do.

@mmodell, in this case I fail to understand why have "parent" project concept. Tasks can be in the parent and in subproject, and they don't show up in the parent. Parent does not allow membership, only subprojects do. I guess you can search using parent as a group. So it appears that the parent is fairly useless other than to group several subprojects together? And we could consider all current unattached "projects" as really subprojects of a null parent?

@Yurik - yes, subprojects are not good for much other than grouping related projects under an umbrella "parent project".

It's milestones that are more interesting for tracking tasks on workboards. They are still a kind of subproject, just without members and with their own workboard column on the parent project.

@mmodell ok, so if 1) milestone can have its own workboard, 2) milestone automatically appear in the parent workboard as a column, we could use it, but I am a bit concerned about the membership, because often people will want to keep track of all the tasks in one milestone (e.g. everything related to Maps (Kartographer)), without paying any attention at the other ones.

My main usecase to use Maps to quickly find a task - i simply open that workboard and do a ctrl+F, and to subscribe to all tasks in it.

The only exception to milestones is the Maps-Sprint -- we want tasks to exist in both the milestone and in the sprint at the same time.

In T137816#2381594, @Yurik wrote:

@mmodell ok, so if 1) milestone can have its own workboard, 2) milestone automatically appear in the parent workboard as a column, we could use it,

Yes and Yes.

but I am a bit concerned about the membership, because often people will want to keep track of all the tasks in one milestone (e.g. everything related to Maps (Kartographer)), without paying any attention at the other ones.

It's still possible to subscribe to the milestone project to keep track of the associated tasks without being a member.

The only exception to milestones is the Maps-Sprint -- we want tasks to exist in both the milestone and in the sprint at the same time.

Ok so this one stays a separate project.

So what's the difference between subscribing to milestone and being a member of the milestone? I thought they are the same thing?

You can't be a member of any milestones. So that's the difference. Wait, let me try that again with less snark...

The difference between membership and subscription is this:

With some projects, membership can give you access to objects that you would otherwise be unable to access (by way of policies. We try to limit this to very special cases with acl* projects but there are others like WMF-NDA and Security )

Ok, so if subscribing is all we want (which notifies us whenever any of the tasks in that milestone is changed without explicitly subscribing to that task), lets do it! I propose:

• #interactive as the "parent" team project, with Maps being a subproject, and Maps (Kartographer) Maps (Kartotherian) Maps (Tilerator) Maps (Map-Styles) being milestones. Plus Maps-Sprint can be renamed into Maps-Sprint and also be made a subproject of the #interactive. Sounds good?

Task title/description updated to reflect the proposed changes.

Surely, Discovery-Interactive?

@Jdforrester-WMF : Although the folks working on interactive happen to be in Discovery, only the maps part it officially Discovery work. (Graphs are not). So I'm not sure whether it should be Discovery-interactive or just Interactive.

Similarly, it seems like it should be Discovery-maps-sprint, since that is an official Discovery activity, and for consistency with other Discovery team sprint naming. But I'm not sure.

@Yurik (and others):
It seems very odd that the sprint itself wouldn't be a milestone, because the primary purpose of milestones, from what I can tell, is for sprints. But I guess in this case, because the sprint is associated with the team, and the team spans multiple domains, it makes sense.

Would the project type of Maps change to be an umbrella rather than a group (or component)?

@ksmith: Yes I think umbrella would be appropriate.

In T137816#2382922, @ksmith wrote:

@Jdforrester-WMF : Although the folks working on interactive happen to be in Discovery, only the maps part it officially Discovery work. (Graphs are not). So I'm not sure whether it should be Discovery-interactive or just Interactive.

And all of it is within the umbrella of Editing (and specifically Multimedia), confusingly.

In T137816#2382948, @Jdforrester-WMF wrote:

And all of it is within the umbrella of Editing (and specifically Multimedia), confusingly.

Only MediaWiki-extensions-Graph, right? Maps is not related to Editing or Multimedia that I can see, nor are the components like Maps (Kartotherian). And the interactive umbrella wouldn't have any relationship to editing or multimedia either, that I know of.

In T137816#2382977, @ksmith wrote:

In T137816#2382948, @Jdforrester-WMF wrote:

And all of it is within the umbrella of Editing (and specifically Multimedia), confusingly.

Only MediaWiki-extensions-Graph, right? Maps is not related to Editing or Multimedia that I can see, nor are the components like Maps (Kartotherian). And the interactive umbrella wouldn't have any relationship to editing or multimedia either, that I know of.

Yuri and I have discussed this before, but mostly Discovery is working on this stuff because it is; the natural home of mapping and any other static and user-interactive types of media which are added to pages to illustrate or enhance them is Multimedia, yes.

Heh, I guess Interactive team is targeting cross-team "features", which involve the whole vertical - data storage (geojson/tabular data on commons), editing it, retrieval (accessing that data from Lua & frontend), as well as accessing other data sources like Wikidata, display and interaction on wiki page, providing those tools to other usecases (like Wikidata Query service data visualization), allowing commons to show maps/graphs to alter upload experience, etc. But in any case, this is totally unrelated to the bug in question :D

@Yurik: Please edit the task description to summarize the discussion in this task and to list which things are now exactly wanted. Thanks!

@Aklapper We are discussing this now. Hopefully we can have something sorted out by tomorrow.

@debt : I just updated the task description to reflect the conversation so far. My main question is whether there should be a "product backlog" somewhere outside the sprint workboard.

It could just be a column on the sprint workboard, but that tends to get unwieldy. The #discovery-interactive project could have a workboard with a product backlog, either split out by time (e.g. soon/later/eventually) or by functional area. But either way seems like it would be highly duplicative of the Maps project with its milestones.

Should we (you/me/@Yurik) have a hangout to try to finalize this?

@ksmith by product backlog, do you mean per product list of high priority tasks that should be worked on first? Should we use "priority" for that? As for Maps - I hope that it would be fully automatic - basically adding a task to Maps (Kartographer) should also show up in Maps. The only use that I see from Maps is a one page view (and ctrl+F search) of everything maps related. Plus each column should probably be sorted by priority. So no work should actually be done on Maps - like moving things around, etc.

@Yurik: A typical split for a team might be to have a Product Backlog which has maybe 100-1000+ tasks on it, and then a Sprint Backlog which has maybe 20. The term "Product Backlog" is misleading for a team that works on multiple products, so you can think of it as a "Long-term team backlog".

It will be automatic that something in Maps (Kartographer) will automatically appear in the Kartographer column of the Maps workboard. Technically that task won't be "in" Maps itself, because it will be in "Maps (Kartographer)" instead. And yes, each column in Maps (like Kartographer) can be sorted. Either automatically by the priority field, or manually by dragging up/down.

The team would have to decide whether to do the Maps (Kartographer) prioritization in the Kartographer column of Maps, or in whatever columns are set up in the Maps (Kartographer) workboard. Each task would be in both places, but the relative position in each workboard would be independent of each other.

For an example of a Product Backlog, see Discovery-Search. As tasks become the highest-priority tasks there, they get moved to Discovery-Search (Current work) (which is a milestone, so it is both its own project and also appears as a column in Discovery-Search ). That's an example of a product backlog organized by time. Note that many tasks are also tagged with the component they relate to (CirrusSearch Elasticsearch etc.).

I hope that helps.

@Yurik (and @debt): See also: https://www.mediawiki.org/wiki/Phabricator/Project_management#Implementing_Common_Project_Management_Practices_in_Phabricator which has some great diagrams.

This proposal at the moment would be "Columns show categories". I'm wondering if it would be better to do something closer to "One project board, different tags for components, and a status board."

In the interest of keeping this as a simple incremental step forward, my new proposal is to just make the components milestones within Maps. We can avoid creating the new parent project, and we can just leave the sprint project detached.

Eventually, I think we're going to want a team board at a higher level than the sprint board, but that can wait until we have a clearer idea of how it would be used.

@Yurik and @debt: If this sounds OK, I'll update the task description and move forward with implementation.

Sure, would be a good first step. Thanks!

Sounds good, thanks @ksmith for orchestrating this!

ok I can convert the projects to milestones of maps.

done:

Maps (Kartographer)
Maps (Kartotherian)
Maps (Tilerator)
Maps (Map-Styles)

@mmodell thanks! Could you also do it for Maps (Maps-data) ? We seemed to have missed that one. Thanks!

@Yurik: done

Should we also add in the Commons-Datasets project to the Maps board?

aaa, make it stop!! :) @mmodell I think herald is still auto-adding Maps to various tasks, effectivelly removing them from sub-dashboard. See the log of T152751

@Yurik: I disabled the herald rule that was causing trouble. There may be others though.

Thanks @mmodell, works! I think we should merge Commons-Datasets (possibly renaming it structured data? Or should we do another board for "#geojson-data" ... not to be confused with Maps (Maps-data)...)

Also....should MediaWiki-extensions-Graph and Maps-Sprint be added in as well? I think that's all the boards that the Interactive team puts tickets on...

Bummer, now we no longer get any of the Phabricator notifications in the wikimedia-interactive IRC channel :( @mmodell do you know anything about that?

@Yurik: https://phabricator.wikimedia.org/diffusion/TWBT/browse/master/channels.yaml

@Aklapper but it was there -- https://phabricator.wikimedia.org/diffusion/TWBT/browse/master/channels.yaml;80355c5fb0b870ea70cae0951f9cb2310866e677$153 -- should we change it somehow?

@Yurik: https://phabricator.wikimedia.org/T148650 might provide some insights on milestones and subprojects. I see no (-.*)? in https://phabricator.wikimedia.org/diffusion/TWBT/browse/master/channels.yaml;80355c5fb0b870ea70cae0951f9cb2310866e677$153

@Aklapper uploaded https://gerrit.wikimedia.org/r/#/c/326496/ - please +2, thx!

@debt : For now, the focus is on the maps feature, thus excluding graphs and tabular data. Later, we might want a team-centric backlog board (rather than a feature-centric board), and that would be where those would fit in.

Let's revisit this in January and see what adjustments might make sense.

And thanks to those who helped solve the herald and IRC notification issues.

@ksmith, I think we should also remove the auto-appending of the Discovery-ARCHIVED tag - I think it has almost zero value, and simply clutters the screen with an extra tag for all tasks.

@Deskana : You're the main stakeholder for the Discovery-ARCHIVED tag. Do you find value in having all the maps stuff tagged with it?

In T137816#2878896, @ksmith wrote:

@Deskana : You're the main stakeholder for the Discovery-ARCHIVED tag. Do you find value in having all the maps stuff tagged with it?

Yes. Phabricator search is so bad that I sometimes I run searches with the query and the Discovery-ARCHIVED tag as a catch-all since I can't remember what project it's in. It's very useful for this.

@Deskana, what kind of searches are you making? Are there any other ways to search for the maps, graphs, or structured data initiatives that do not involve tagging every task with a Discovery-ARCHIVED tag?

If we keep Discovery-ARCHIVED as a tag that is auto-added to everything with Maps, we should do the same with Commons-Datasets, MediaWiki-extensions-Graph, Graphoid, since those are also discovery-handled projects. This also implies that we should make those boards as sub-boards under Maps, and rename it into #interactive - because then we are using those boards as organizational, rather than feature-oriented.

(For the records, Herald rule H33 currently adds Discovery-ARCHIVED to { CirrusSearch | Elasticsearch | Maps | MediaWiki-Search | Wikidata-Query-Service | Wikimedia-Portals } as requested in T95932.)

@Yurik: Does the Discovery-ARCHIVED tag cause you any specific problems, or do you just consider it "clutter"?

The thinking so far has been that Maps is a feature, not a group (and thus probably shouldn't have the purple/group icon). If we want to shift it to representing the Interactive team, we should think through that more deeply. Other things might need to change.

I'm not seeing how the Discovery-ARCHIVED conversation relates to the "should Maps really become #interactive" conversation.

@ksmith, significant clutter - for example, looking at Maps board, all one sees is a multitude of tags, mostly the Discovery-ARCHIVED tag, making it hard to actually see the tasks. Tags are great to organize tasks, but on that board they are a hindrance. Would it be possible to perhaps make it hidden?

My second point is that if Maps is a feature, and we require all Discovery-managed features to be marked with Discovery-ARCHIVED, we should add all other features we work on, such as Commons-Datasets, structured-map-data (doesn't exist yet), MediaWiki-extensions-Graph Graphoid and possibly a few more tags to the above rule. Since Discovery-ARCHIVED shows up as a prominent purple box and draws attention, it would only add further to the clutter.

P.S. I just looked around, and I couldn't find tasks tagged with the department tag, rather than product/team. For example, VisualEditor tasks are not marked with the Contributors-Team tag, as that would clearly be an overkill.

In T137816#2885376, @Yurik wrote:

@Deskana, what kind of searches are you making? Are there any other ways to search for the maps, graphs, or structured data initiatives that do not involve tagging every task with a Discovery-ARCHIVED tag?

As I explained above, they are searches for things in Discovery when I don't know the project. In the case of Interactive projects, the tags that are in use are so confused that I often have no idea where something might live. In the case of Search projects, there are a couple of different boards tasks could live on. I find it useful to not have to try to remember every possible tag that could be on the task in order to find it.

In T137816#2887743, @Yurik wrote:

P.S. I just looked around, and I couldn't find tasks tagged with the department tag, rather than product/team. For example, VisualEditor tasks are not marked with the Contributors-Team tag, as that would clearly be an overkill.

It's to each their own. If a team wants to have a team project be added to all of the tasks in some list of projects that's probably a good thing for them (they may use it to triage incoming requests, for instance). Analytics did the same. Operations is doing similarly. (to be clear: adding a team project when certain project projects are added to a task.)

@Deskana I understand that you are searching for discovery-related tasks. We now have this Maps board, which automatically contains all maps-related tasks, regardless of what other sub-board it also appears on. Would that help?
My other question is about consistency - the other, non-maps tasks that interactive team is working on are not marked with Discovery-ARCHIVED, so it clearly does not solve your goal of being searchable. I would propose to create a saved query that lists all discovery-related projects, and we all can use it. I think it will be much more thorough, and will catch all such tasks automatically.

In T137816#2887777, @Yurik wrote:

@Deskana I understand that you are searching for discovery-related tasks. We now have this Maps board, which automatically contains all maps-related tasks, regardless of what other sub-board it also appears on. Would that help?
My other question is about consistency - the other, non-maps tasks that interactive team is working on are not marked with Discovery-ARCHIVED, so it clearly does not solve your goal of being searchable. I would propose to create a saved query that lists all discovery-related projects, and we all can use it. I think it will be much more thorough, and will catch all such tasks automatically.

For users who are not familiar with Phabricator, that would mean that the Discovery-ARCHIVED tag does not really do what they would expect it to. A saved query might be fine for us, but the behaviour for other users would be counterintuitive. I do not believe reducing clutter is worth that tradeoff.

It seems you intend to proceed with your solution no matter what I say. If that is the case, I would prefer you do me the courtesy of being clear about that, and save us both the time of the back-and-forth.

MediaWiki-extensions-Graph and Graphoid have never officially been part of the Discovery-ARCHIVED mandate, so I would prefer to leave them out of this conversation, at least for now. It's not clear to me whether Commons-Datasets falls into the same category, or whether it is a Discovery project that should be added to the herald rules.

It looks like there are a lot of tasks now in Maps that haven't gotten the herald treatment. I could do some batch edits to add Discovery-ARCHIVED to those, for consistency. And moving forward, any newly added tasks should get it automatically.

It's possible that nested milestones could help, but phab doesn't support those.

To me, this whole discussion is a matter of opinions, not facts. @Deskana finds it useful to be able to quickly see everything in Discovery-ARCHIVED. @Yurik finds the visual clutter annoying. I doubt either will convince the other to change their mind, which leads me to three options, none of which would please everyone:

1. Clean up the tagging and heralds to be consistent, so all Discovery tasks have Discovery-ARCHIVED
2. Delete Discovery-ARCHIVED and find alternatives, such as saved queries
3. Keep Discovery-ARCHIVED for the projects that Deskana cares about (search, portal), but remove it from the ones that Yurik works with directly (maps)

I don't use the Discovery-ARCHIVED tag myself, but I also don't find it visually intrusive. So personally I don't have a preference. Generally the primary customer of workboards is the product manager, which would lead me toward deferring to Deskana. If the Maps product manager felt that the Discovery-ARCHIVED tag was horrible, that might lean me toward the third option. Yurik has traditionally been doing product management work for maps, but that has been changing.

After two months of silence: What's left in this task?
Can I help with anything (if yes: summarizing in the task description highly welcome)?