Page MenuHomePhabricator

Common definition of a roadmap for WMF teams?
Closed, DeclinedPublic


We are succeeding implementing a common process to define and document quarterly goals across Wikimedia Foundation teams. However, we are still missing a common way to define and document longer term intentions. There is a WMF Annual Plan, there will be a WMF Strategy, but these are generic artifacts that cannot be used at a team level (or can they?).

Roadmaps are important in software projects, and very important in free software projects, because they provide a direction and some predictability of mid term activities. There is no guideline on how teams should define and document their roadmaps.

As part of T114137: Document how the Developer Relations team works, today I have documented how the Developer Relations roadmap works. Basically, we are improvising seeking short term benefit, but I would welcome a well informed guideline that all teams would use. I think it would help our discussions between teams, with the communities, and with the users of MediaWiki out there.

Event Timeline

Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil subscribed.

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: 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:

We further define these milestones each quarter here:

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.

Closing this open #WMF-Product-Development-Process task as that project seems dead for years (see T253629). Feel free to reopen this task either if someone will take responsibility, or if this task should remain open and (!) tagged with some other active (!) project tag. Thanks a lot!