@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?
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.
@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.
@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.
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.
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:
@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)?
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
I will be working with Yuri on this. Once we iron it out, we'll reach out for help implementing the decisions. Most likely they will closely resemble what's already in the task description.
@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: 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
@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.
If we keep Discovery 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.
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.
@ksmith, significant clutter - for example, looking at Maps board, all one sees is a multitude of tags, mostly the Discovery 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, 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 shows up as a prominent purple box and draws attention, it would only add further to the clutter.
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.
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, 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 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 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 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. @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:
- Clean up the tagging and heralds to be consistent, so all Discovery tasks have Discovery
- Delete Discovery and find alternatives, such as saved queries
- Keep Discovery 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 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 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.