Talk:Roadmap

Where should we put the goal of "review all Bugzilla patches within a week" or similar? Sumanah 16:33, 16 September 2011 (UTC)


 * What are the activities that will drive that goal, and when will they take place?--Eloquence 01:03, 29 September 2011 (UTC)
 * We have ~40 in the past six weeks. I'm emailing the patch submitters today. to let them know we're haven't forgotten them.

Epub Export
When will be this bug fixed, so Extension:EPubExport can be deployed on Wikisource? --Micru 17:13, 18 December 2011 (UTC)
 * Sorry for the delay in response, Micru! I'm asking Tomasz Finc to take the lead on judging whether the replacement extension makes sense from a technical perspective (as mentioned in a recent bug comment).  I hope to get a response from him later this month; he's currently traveling. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 16:08, 8 February 2012 (UTC)

Gadgets 2.0
From Roan & Timo just now in IRC: "Gadgets 2.0", which is related to the Gadgets-extension -- this will only affect gadgets developers when we deploy the new Gadgets extension, which will be a while yet. Gadgets 2.0 won't be ready before 1.19 is branched, but probably ready before 1.20 and can be updated on wmf any random time after 1.19 is deployed.

Is there any estimated month for Gadgets 2.0? Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 21:39, 1 February 2012 (UTC)
 * possibly related.
 * Talked to Alolita, added to "July 2012 and later, or unscheduled". -Sumana

Request: more details on Labs
Volunteers have been asking for more details on the Labs timeline. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator 16:04, 8 February 2012 (UTC)

don't plan just do
especially looking on LQT there should be done something and not just talked about. Since month there is noting happening around LQT. And then I read something about renaming. Create something that can be named and don't talk and discuss about things and are really unimportant like the name. DO SOMETHING! --DaSch (talk) 12:17, 9 July 2012 (UTC)

Monthly roadmaps?
Those links to monthly roadmaps are confusing and distracting... for what reason? Why not just having THE roadmap, and update on a monthly basis, or whenever it's needed. If anybody wants to check (for some weird reason) 7 months ago they can just check the history of the page.--Qgil (talk) 23:06, 27 December 2012 (UTC)
 * What's confusing? It's just the standard way of archiving wiki pages, permalinks are used by a minority and are not searchable so they're definitely bad in this case. I've moved the links to an Archive section, is this enough? --Nemo 07:17, 28 December 2012 (UTC)
 * What is confusing is the very concept of monthly roadmaps. A roadmap is a document that evolves continuously over time. Knowing what was the snapshot at a certain point of the past has little value, but if someone really needs to know they can look back at the history - just like with any regular wiki page. Those links so prominently featured at the top of the page are confusing, and they just grow every month.--Qgil (talk) 00:43, 29 December 2012 (UTC)
 * They're not called monthly roadmaps anywhere as far as I can see. Did you look at the page? They're no longer at the top. --Nemo 07:59, 29 December 2012 (UTC)

Update
The page header says it is automatically generated, but the last update was in August. Could we has another sync? Or, is the automation software online? John Vandenberg (talk) 01:09, 3 November 2013 (UTC)


 * We're shifting to a new format, a combination between the reworked Deployments page and the fiscal year goals. Pinging Greg to make sure we refactor pages on mediawiki.org consistent with that approach.--Eloquence (talk) 02:46, 3 November 2013 (UTC)

Anything like an overall MW roadmap today?
Not necessarily something like the parallel detail that was on this page in 2013, but things on that spectrum: medium-term product and engineering goals? Sj (talk) 03:37, 20 January 2023 (UTC)
 * Thanks for the question. I'll poke around and see what I can learn. --Elitre (WMF) (talk) 12:31, 23 January 2023 (UTC)
 * (In the meantime I do want to highlight that Wikimedia Product was recently updated and features a list of what's being worked on. --Elitre (WMF) (talk) 12:39, 23 January 2023 (UTC))
 * Sj, I don't want to keep you waiting - I don't think we have anything like that for the current work we're doing. I will, though, discuss with staff involved in Annual Planning writing to explore whether that's an option for how we want to deliver information about what's coming next. --Elitre (WMF) (talk) 15:43, 24 January 2023 (UTC)


 * Thank you kindly for the quick reply!  That answers my question and the one I didn't think to ask.
 * The Product page is a great overview of ~42 projects and the teams building/maintaining them. I can't tell from this overview where it comes from, where it's heading, where it sits in the broader universe.
 * I would welcome a roadmap that explicitly addresses things like a) its scope, prioritization within that scope; b) what subsets of Wikimedia + related work are included; c) issues of time, lifecycle, and ownership. Sj (talk) 07:32, 26 January 2023 (UTC)
 * Scope, priority:
 * User scope: is MediaWiki (for non-WM wikis) a product? Who handles its planning? Some things (search, codex) appear on this list.
 * Content scope: Multimedia / video / audio / 3d / maos audiences or interfaces?
 * Priority: I can't tell what the top priorities are, what we would be focused on with 10% or 200% the resources. Is there a long tail that this draws from that is similarly maintained? (like a synthetic catalog across all wishlists + brainstorming, or curations of subsets of Phab) This exists for individual projects / within individual teams but is needed across them for synchrony + synergy.
 * What subset of Wikimedia work is included
 * Which project-areas: this does not seem to include Enterprise / ORES / spam + quality tags; cloud / toolforge / dev services; Commons / Wikidata / other cross-project services (x-project talk, gadgets, template/modules); ML + bot tools...,
 * Which developers: This is by design WM staff product teams, leaving out non-WM staff teams, community teams, major gadgets + bots, downstreams, whatever others use Codex + apis for. (e.g. it includes our homegrown KaiOS app but not the many other W apps which extend audience). No mention of partners or integration (maps, external editors, large wikifarms, &c)
 * Time, lifecycle, ownership:
 * Owners + maintainers: how are different pieces and products meant to be maintained next year, 5y from now?
 * Temperature: these seem to be mostly "maintain + improve" projects, no "wind down / merge / integrate", not many "build something new"
 * Vision: who is responsible for high-level vision for each named project; which are part of something larger? A wishlist item for instance might have a vision defined by people who are not at all in the owner / maintainer / developer groups at first
 * Release cycles: We no longer have a 'lead dev' for MW, but it has a clear release cycle. The non-MW stack does not, and there's less explicit coordination + joint testing.  E.g. it's easy to possible the skin w/o updating intro and onboarding docs and w/o updating high-use templates that are impacted, b/c there's no overall "reader-and-editor experience release cycle".
 * @User:MPaul (WMF), FYI about the above (I think your team may be the one managing APP comms, and everything above is kinda related). --Elitre (WMF) (talk) 11:36, 26 January 2023 (UTC)
 * Thank you @Elitre (WMF). @Sj this is very helpful and I'll share with others. We may not have exactly what's described but as Maryana noted in her brief message yesterday this year's annual plan will be led by the needs of product and tech departments. Hopefully, we can surface more of this kind of information. MPaul (WMF) (talk) 16:21, 26 January 2023 (UTC)
 * Release cycles: We no longer have a 'lead dev' for MW, but it has a clear release cycle. The non-MW stack does not, and there's less explicit coordination + joint testing.  E.g. it's easy to possible the skin w/o updating intro and onboarding docs and w/o updating high-use templates that are impacted, b/c there's no overall "reader-and-editor experience release cycle".
 * @User:MPaul (WMF), FYI about the above (I think your team may be the one managing APP comms, and everything above is kinda related). --Elitre (WMF) (talk) 11:36, 26 January 2023 (UTC)
 * Thank you @Elitre (WMF). @Sj this is very helpful and I'll share with others. We may not have exactly what's described but as Maryana noted in her brief message yesterday this year's annual plan will be led by the needs of product and tech departments. Hopefully, we can surface more of this kind of information. MPaul (WMF) (talk) 16:21, 26 January 2023 (UTC)
 * Thank you @Elitre (WMF). @Sj this is very helpful and I'll share with others. We may not have exactly what's described but as Maryana noted in her brief message yesterday this year's annual plan will be led by the needs of product and tech departments. Hopefully, we can surface more of this kind of information. MPaul (WMF) (talk) 16:21, 26 January 2023 (UTC)


 * Thank you both🌼 Some user stories to clarify who roadmaps are useful for -- often it's much more than just the internal teams running product + tech:
 * As someone interested in helping expand our scope + reach, it doesn't help me figure out whether ideas not explicitly listed are in progress / intended to be supported + looking for help / popular but not on any roadmap... or what an existing proposal or idea (like Shared Citations or a Blazegraph migration) lacks to become real.
 * For someone interested in helping reduce the cost of maintaining our tools + risk of them going away, it doesn't help identify open problems looking for creative new solutions; or opportunities for integration / acquisition / delegation / spinning out components.
 * To the extent that Wikimedia aims to be/come a pillar of support for a free knowledge ecosystem, other parts of that ecosystem need to know what this means for partner support, integration, simplification. In some sectors, a commitment of adoption by WM/MW, or modest bounties, is transformative – more than backing into an eventual investment without that pre-commitment. Similarly, an affirmation that certain work will not be supported can unblock partners or fellow-travellers who would be glad to own + run with + independently fund projects that they imagine WM is already planning or doing. Sj (talk) 17:41, 26 January 2023 (UTC)
 * To the extent that Wikimedia's decisions inform what the global community sees as possible or likely to have a future as free software implementations of essential tools and interfaces, clear commitments help focus and align other work. Where there are competing standards or approaches, what role does WM see itself playing in reducing fragmentation and settling on a path forward? Ex: in choosing a new graph db for wikidata, this is much more than a simple technical decision on its merits as though that decision has no influence in the future arc of free graph database software. Ditto for our choices re: editable tables, spreadsheets, maps, media, &c.