I think this would be very premature at this time.

I think the reason "roadmap" isn't in the TPG glossary is because TPG's work has traditionally focused on the day-to-day development. That is, given the existence of a prioritized product backlog, how does that get turned into released code. TPG has recently started to extend our vision farther upstream in the process, with initiatives like the SPDPP, and helping with the MPL (Master Project List). Adding Roadmap to the glossary sounds like a good idea.

The Software Development Concepts page does talk about milestones, which are somewhat related to roadmaps.

Tracking roadmaps is a challenge at many organizations, because it can be awkward to mix high-level visionary aspirations into the same bug-tracking tool where you track typos that need to be fixed. Having roadmaps in a separate doc (or wiki page) is a common solution, but of course that creates a disconnect and potentially some duplication of information.

My personal concern about roadmaps is that they are often perceived as more rigid than they really or (or at least more than they should be). One quarter out, you should have some idea what is likely to be worked on. Three quarters from now, so much is likely to change that anything on the roadmap should be considered extremely tentative. A lot of people trust roadmaps, and get frustrated when they change. Some people become unwilling to deviate from a roadmap even when it no longer makes sense.

I support having a common understanding of what "roadmap" means in our organization.

I recommend looping @Wwes into this conversation as he's been leading the effort to document and standardize the WMF roadmap, which I think satisfies some of the concerns raised here. I do not believe it's been publicly published, though my understanding is that it is on the to-do list.

thanks @Awjrichards and +1 @ksmith. I do think milestones could play a role for sure. The initial roadmap with the teams was a basic effort to just illustrate the need. We all have goals already and they are essentially the building blocks. Just need a clean way to show them that does not require extra work or a new process. Need to investigate if you can take a table cell from one page and essentially pass that to another and we'd be on a quick path to having a public roadmap. We posted the previous and I'm going to at least update that for the moment as we discus.

Given the age and inactivity of this task, I am removing the 'Team-Practices' tag in an effort to tidy up TPG backlogs/boards.

If this begins moving forward at some point in the future and you'd like to loop us in again, feel free to re-add the 'Team-Practices' tag.

But... shouldn't TPG be the owner pushing this task? And if not TPG, then who?

I'm not sure why TPG would own this, @Qgil curious to hear your perspective, but I think 'Product' in general would own product roadmap-related stuff.

This task is about a common definition of roadmap, so different Product teams would maintain their roadmaps based on this common definition. TPG cares about definitions and common practices in project management, and this is why I thought TPG was a natural owner of this task.

That is my explanation, but I am not trying to convince you. I agree that ultimately it is Product and Technology who own their roadmaps and the problems related to them.

We will post a roadmap based on milestones defined in the Annual Plan process. Presently we have a draft of those here:
https://office.wikimedia.org/wiki/Product/Roadmap_for_2016-17 and the plan is to add those to the public wiki soon. This was built from efforts as we planned them for the Annual plan here:
https://office.wikimedia.org/wiki/2016-17_WMF_Annual_Plan

We further define these milestones each quarter here: https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Goals

Converting those to phab tasks in a quarterly manner based on milestone and tied to objective epics seems logical.

@Qgil thanks - I think what you mentioned strikes at the heart of a TPG-related polarity: TPG should own WMF processes vs TPG should support teams in owning their own processes. TPG currently tends toward the latter, in part because the org has generally strongly resisted standard processes and (at the risk of speaking for all of the TPG ) the TPG maintains efficacy by not having ownership but rather staying in a coaching role. So in this case, if Product would like support in road mapping activities, standardizing roadmaps, etc that is a conversation we can certainly have - but ownership of the roadmap and decisions about standardization should come from Product.

Thank you Wes and Arthur for the explanations. Both make total sense.