Talk:Wikimedia Foundation Annual Plan/2023-2024/Product & Technology

Draft feedback

Thanks for sharing the early draft! Here's a bunch of feedback to consider. Don't feel the need to respond line by line please, just treat it as food for thought.

• Overall, the unified buckets of planning are much simpler to understand and present clearly aligned themes of work. I love it. It's also very helpful to see what % of resources/time are allocated to each bucket.
• Examining the “dance partner” model between editor outputs, volunteer technical contributors and moderator workloads If I'm understanding this correctly, are you saying that you want to measure whether there is a healthy balance between the workload of moderators and editors? That's an awesome goal, but maybe would be clearer to just say that more directly. Having good data is a solid first step, and a big challenge since the queues are not structured data, they're just wiki pages cobbled together with a variety of templates.
• A slightly more ambitious bar for moderator plans would be to create at least one working beta of a product change to help moderators allocate their time to critical problems on the wiki needing their attention. For instance, notifications (potentially opt in via a beta?) about severe backlogs in admin queues. Or a prototype dashboard that shows realtime data about the health of moderation systems across a wiki (how many unreviewed pending changes are there? how long does it take to resolve pending changes?) As an administrator, I've often wished that I could get more proactive notifications about which areas of work have backlogs that need my attention. Basically right now I have to go bounce between a bunch of tabs to check this, and in practice I just kind of stick to whatever I find easiest to do.
• Continuing to explore, improve and prioritize mobile experiences for this audience in an increasingly mobile-first world I remain totally unconvinced that focusing on mobile web admin tools is the right focus. It defies logic when literally every other software product—from Reddit to Slack—doesn't build for mobile as the primary admin tools platform. What makes us believe Wikipedia, where admin tasks are even more complex to do, is different? It feels like the team picked the platform that was easiest to build and ship on, rather than the one with the highest impact. Even if small wiki moderators simply don't have access to desktop web devices at all, even Android app improvements would make more sense for intensive, high frequency use like moderating a wiki than the painfully slow mobile web.
• Continue work on SEO and enabling incremental reader improvements why is improving SEO a goal when Wikipedia already has the best SEO of any website that isn't directly owned and operated by Google? This seems like a solved problem.
• Explore ML-enabled natural language search experience yes please! would love to see the Foundation show the world what a more reliable natural language search experience can be that doesn't hallucinate and has references to the source. Not trying to crawl and deliver the entire web, but just facts from Wikipedia, would not only be more reliable but computationally less expensive. This is an initiative that I think could also merit a dedicated, time-limited grant or partnership, similar to Abstract Wikipedia.
• The Future Audiences goals seem to boil down to "we're going to try some stuff", but it's so vague and open ended it is not meaningful as a scope of work or set of goals. Some of it even overlaps with other areas, like AI and audio ideas for readers in Wiki Experiences. Why not get more specific about example bets we will make this year? The team must have at least some high confidence examples in mind of experiments to try, and realistically with 5% of the budget we're talking 1-2 substantial bets, right? If we really don't know what the work will look like, instead we need to formulate what the measurable outcome/impact is. Pursue global youth audiences is a lot closer to the mark here, for instance, but could get more measurable.
• The section currently in Sub-buckets could maybe be elevated to a single "foundational engineering" bucket? If it's 15% and larger than say, future audiences, that seems to make more sense. Even data center and traffic ops could and perhaps should have measurable goals around things like uptime or costs.
• Do Wikimedia Enterprise and Abstract Wikipedia fall completely outside of the planning scope here? They're both technology and product initiatives, so that feels odd. Even if they're resourced separately, having a unified strategy is still important.

Steven Walling • talk 23:26, 10 February 2023 (UTC)

Thank you for taking the time to read and comment on this document Steven. [Also - long time, no see! How've you been old friend?] I'll be sure to bring your notes to the relevant people responsible for writing and "wrangling" each section, to incorporate into subsequent planning. They may also add their own replies/additions on some of the bullet points here. LWyatt (WMF) (talk) 10:49, 11 February 2023 (UTC)

Thanks Liam! Good to see you thriving at the Foundation too Like I said no need to reply to everything, just whatever the team thinks merits further discussion. Steven Walling • talk 02:13, 13 February 2023 (UTC)

@Steven Walling I'm the Product Manager on the Moderator Tools team and wanted to jump in with some thoughts on your questions about mobile web moderator tools. Our team did some research last year as a result of which we started working on improvements to content moderation on mobile web. We didn't make this decision because the platform was easy to build and ship on, in fact the way our mobile site works has turned out to be a lot more complicated and frustrating than we anticipated - it seems to me like it would have actually been easier to prioritise desktop and forget about mobile altogether. That aside, I wanted to elaborate on how we decided to work on this project.

When we talk about content moderation we've been thinking about moderation generally, not just administrator tasks. Really, editors are doing content moderation all the time on Wikimedia projects - looking at your watchlist, checking out someone else's edit, building on it with some additional information, or reverting it to an earlier state. I would argue that's all fundamental content moderation, and doesn't require the admin toolset. So when we set out to look at the state of content moderation, particularly outside of our largest projects, we were quite taken aback by how frustrating the mobile web experience was for these basic building blocks of the editing experience. Special:MobileDiff hasn't included an Undo button in over a decade, mobile users can't access their account preferences, and basic administrator tools like the Delete and Protect buttons were hidden behind the Advanced mobile setting. We decided to work on these fundamental wiki features to support the increasing number of mobile-first editors. In some large projects, particularly Indic languages, the percentage of mobile editors is often more than 30 or 40%, and the data shows that these editors are far less likely to do things more complicated than reading and making basic edits. In my opinion these communities are being held back from growing and thriving by the state of mobile web with respect to functionality beyond making individual edits.

All that said, I do agree with you that many administrator tasks aren't well suited to mobile. We're currently interviewing English Wikipedia patrollers for our upcoming project on new page patrolling and it's become clear to me that this is a workflow that simply would not work on mobile. Patrollers are opening up multiple tabs, using a wide array of desktop-only gadgets and scripts, and bouncing back and forth between different pages. It seems unlikely to me that solving these patrollers problems would be a mobile-first solution.

I also wanted to note that the Android team actually is planning some work on moderation tools for the Android app! Pinging @JTanner (WMF) in case she has links or further information to share.

I'd love to know if any of the above resonates or opens up more questions or thoughts! Samwalton9 (WMF) (talk) 11:20, 16 February 2023 (UTC)

Sam thanks for the thoughtful reply. As you can tell, by moderators I assumed the focus was more on admins. It does make more sense that if you think of the scope of work as including all the moderation tasks like revert edits, etc. that nearly any editor can do, mobile web definitely makes sense as a place with gaps to target. I use the iOS app a lot myself for reading and light editing, and the lack of a revert button there has long frustrated me as well. I do think that because mobile web is fundamentally limited technologically by mobile OS makers and the apps provide tools to re-engage editors and readers, we should be making a concerted effort to swim with the tide and use our limited resources effectively by focusing on the apps, but that's a different conversation perhaps 😉 God speed, and thanks again Steven Walling • talk 16:31, 16 February 2023 (UTC)

Hi there @Steven Walling, nice to e-meet you, and thanks @Samwalton9 (WMF)for the ping!

I agree with your sentiment that moderation actions are a good fit for apps, and that it is frustrating there isn't a revert function on iOS yet. Up until January of this year, I was the Product Manager (PM) for the Android app where we added the revert function on the diff screen. Recently (January 2023), my responsibilities expanded and I now PM both the iOS and Android app. As the PM for those teams I set the roadmap (within the constraints of the organization's annual plan). With that in mind, the first thing on the iOS roadmap for this calendar year is adding and improving edit notices, blocked messages and messaging related to the Abuse Filter (T319347). It was really important that we prioritized those items as the iOS team finishes up on-wiki communications work. The team will release initial updates related to edit notices and blocked messages within the next two weeks. I expect this body of work to finish sometime in March, should things continue as planned.

The next big project for the iOS team will be building a native watchlist. I expect development to start sometime between mid-March to Early April. This body of work will include adding the ability to revert on the diff screen. I will be creating a project page with the iOS roadmap very soon. The roadmap page will give you a window into the features we plan to add in the future. For now feel free to add the iOS project page to your watchlist, which includes monthly updates.

While the iOS team works on native watchlist, one of the projects the Android team will continue work on is Anti-Vandalism tools. Due to there being more editors with Sysops and Rollback rights on the Android app we will build it there first and take our learnings and apply it to iOS. We are still in the early stages of that body of work and are about to start doing outreach to get input on how to build the first version of the feature. I would deeply appreciate you having a read of our project page, and sharing any initial thoughts you may have. Although the first version will be on Android, we are getting input from experienced editors that use the apps across OS. If you'd like to be involved in our upcoming moderated feedback sessions, please do not hesitate to let me know and we will share there sign up link with you sometime next week. JTanner (WMF) (talk) 17:09, 17 February 2023 (UTC)

Hey Jazmin nice to e-meet you too and thanks for the details. I love the quality focus on cleaning up the edit notices / related messaging in the apps. It's also truly awesome to hear mobile watchlist is coming, and can't wait to try it! Putting that in a flow where I can take simple actions like reverts (thanks is already there) from the app too, and you'll have made it way easier for me to quickly check up on my watchlist more frequently. Checking a feed of edits and quickly reacting is 100% what I want to do in the app as a Wikipedian, instead of doomscrolling Instagram or whatever. Steven Walling • talk 20:30, 17 February 2023 (UTC)

Generally we’ve used the words curators and curation quite a bit for those in between tasks, maybe include that into the text ? —TheDJ (talk • contribs) 19:08, 16 February 2023 (UTC)

Good suggestion, curation has zero confusion with administrative tasks to me, and focuses clearly on content, whereas "moderation" is more about policy enforcement and implies admin-type actions like blocking/banning/page protection etc. Steven Walling • talk 20:30, 17 February 2023 (UTC)

@Steven Walling -- thank you for the detailed reflections! I just want to add on to what Sam and Jazmin said about moderation. You mentioned the "dance partner model", and I think I can add some substance there. The thinking is that there are initiatives that we work on that generate edits, like tools for newcomers that suggest easy edits for them to make. It's great if those features increase editing, but the "dance partner" there is the curation/moderation/patrolling side of the equation: if we succeed in generating lots of edits, that also generate work for curators/moderators/patrollers, and so we should think about what commensurate investments we could make in that other side of the equation so we can keep the workload on the wikis in a healthy balance. Does that make sense?

I also really like your idea about investing in ways for curators/moderators/patrollers to monitor their own backlogs. That's a "meta" idea that I hadn't thought as much about, rather than just working on tools for improved curation. MMiller (WMF) (talk) 03:52, 22 February 2023 (UTC)

Yeah to expand, I would say the Foundation can help by making tools that increase the productivity of admins and other curators doing things like reviewing new pages, but you're building highly specialized tools for each of those workflows so it's a significant investment. One thing that will help universally across curation queues would simply be something to help people allocate their time more effectively to urgent problems. Building that product requires data pipelines and metrics, so it might even help you prioritize which moderation problems really do require better tools too. Personally I don't really buy that new page patrol is that severe of a problem for instance, given that English Wikipedia has followed German and others by locking down who can create new pages in mainspace. I'm way more worried about future increases in subtle vandalism and disinformation that linger for days/weeks/months because they are generated by high velocity plausible bullshit machines. Choosing whether to address one curation problem or another could easily be solved by measuring "time to review" on new pages vs. "time to revert" on undone edits, for example. Steven Walling • talk 21:10, 22 February 2023 (UTC)

@Steven Walling I just wanted to follow up in this thread to say that our team has published information and open questions about the project we're exploring for next year at Moderator Tools/Automoderator. Our hope is that we can reduce the overall burden of patrolling new edits, freeing up moderator time. I'd really appreciate your thoughts and input on that talk page. Samwalton9 (WMF) (talk) 12:05, 1 June 2023 (UTC)

Hi @Steven Walling. In reference to your question about whether Wikimedia Enterprise is included in the scope here, we have included a representative from their engineering team in our planning group for Signals and Data Services, and we believe the objectives we have laid out in that bucket will serve them as well, but they are indeed managed from a separate pool of resources, so that is why they have not been included here.

TTaylor (WMF) (talk) 21:22, 21 February 2023 (UTC)

Languages

First of all, I appreciate a lot that (part of) Wikimedia Foundation is resuming a process where some kind of annual planning is drafted and discussed. For the longest time it looked like Wikimedia Foundation activities proceeded totally at random, with barely some slogan approved at the top in some annual slides.

What is Wikimedia Foundation going to do for the billions of people who don't speak English as their first language? I'm extremely disappointed to see that the only mention of the word languages is in "Explore ML-enabled natural language search experience", although there's also "tools and workflows that enable ML-assisted content creation, machine-assisted translation and other tooling".

ML-based search sounds a lot like "rubbish factory". There's absolutely zero need to follow this fad. Instead we need to continue the work on the basics for which CirrusSearch work has done a lot, such as making sure that the language analysers make the internal search engine work well in languages other than English, even in agglutinative languages. There are already several languages where the MediaWiki search engine does a lot better than Google; we need to let people know about it so that they search the wikis directly more often (for example by encouraging people to use Wikipedia as their default search engine in their browser, as we used to back in the day with Firefox extensions).

Content translation is important whether it's machine-assisted or not. ML-assisted content creation has invariably failed in all projects Wikimedia Foundation has explored. (If we're talking about statistically programmed prose generation. If you use "ML" to mean even basic templating and scripting, which is unfortunately the case in a lot of this industry especially for news media, then it's different.) Why restrict the focus on this area?

MediaWiki localisation and internationalisation remains one of the biggest contributions Wikimedia Foundation can provide to the diversity of our communities. Nobody is serving software for 400 locales as we do. Nobody else is managing 200 different language versions of their content project. A lot of improvement is still possible, just based on the current state of neglect from many areas of WMF (for example the recent skin work has barely considered the impact on different languages and on multilingual users).

On this vein, I'm slightly troubled by the claim that different "buckets" need to be able to proceed without blocking each other. That's simply not possible unless each bucket contains the cross-cutting work and experience which is necessary for everyone. For example, no matter the bucket it's nominally part of, a MediaWiki extension will always need to get checked for principles, L10n/i18n, security, performance and other SRE concerns. Pretending that such blockers don't exist will only make them hit harder later.

Looking at the 2030 strategy in light of past experience, broader language support is a primary innovation, it's necessary for coordination in a multilingual movement, it's a requirement for equity in decision-making (there's no equity if language minorities are excluded or if English speakers have by default privileged), it helps with safety and inclusion (people are not comfortable using languages they barely know; poor language support increases chances of misunderstandings and assorted trouble), it's the most obvious channel for increased impact (by scaling to new languages and countries where Wikimedia wikis are currently underused) and it's a way to iterate and adapt because different language communities provide a diversity of experiments which can learn from each other.

In other words, there's zero chance for Wikimedia Foundation and the Wikimedia movement to succeed in their strategic goals unless language support is treated as a major priority. The current arrangement of this plan gives little reassurance that this is being considered. Nemo 21:10, 11 February 2023 (UTC)

Thanks Nemo - I'll make the staff who are drafting the texts for these 'buckets' are aware of your multidisciplinary comments on aspects of language. -- LWyatt (WMF) (talk) 22:09, 11 February 2023 (UTC)

"I'm slightly troubled by the claim that different "buckets" need to be able to proceed without blocking each other" This is the exact opposite of troubling. All effective software development teams try to plan to identify and reduce cross-team dependencies to the bare minimum. Yes, the entire set of initiatives should be pushing in the same direction, to make MediaWiki better for the projects, but having plans blocked by a giant dependency matrix is a recipe for disaster. Steven Walling • talk 02:12, 13 February 2023 (UTC)

What makes you think that the sentence I commented refers to a plan to eliminate "a giant dependency matrix"? Nemo 06:45, 13 February 2023 (UTC)

Hi @Nemo! Good to see you. I will try to provide some inputs in my response which I hope will be helpful in this conversation. I very much appreciate your thoughtfully put together observations. The WMF Language team and our language initiatives are possibly one of the most competent and inclusive for any globally available tech platform, and thank you for calling that out. There is no question of compromising on that offering, and in our future expansion possibilities as we bring more languages along. Equity of knowledge and of a community engaged in knowledge sharing rides on the power of language diversity and stable i18n and l10n initiatives. As you rightly pointed out, the strategic recommendations that will guide us to the year 2030 vision will have to be strongly connected our language based initiatives to be relevant, practical, and successful.

What you see reflected in the initial draft are very high level objectives that include the inputs from the Language team and from others in the Product and Technology departments who are associated with the operations for language support. In the many years that we have been supporting our language services, we have been observing and getting feedback that point to the diverse ways that the various communities have been using these tools. With wider visibility into the needs and challenges from the smaller communities in regions of recent digital growth there is more perspective for us to consider and explore. ML, LLM and related innovation have over the years weaved their way into the online behaviour and expectations of many users. The Future Audiences bucket in a way will explore further on this area as it can determine some of our future connection points with users as everyone grows with the changes happening around us.

The buckets structure and the objectives are intended to help us determine larger spaces within which our work will intersect and be guided by each other. The buckets will be self contained in their own way to not hinder each other while at the same time provide the necessary space for more granular operations to be conducted per necessary protocol and adherence to dependencies. Hope this information is somewhat helpful and as we proceed on the planning process we will be able to help clarify the vision further. Runa Bhattacharjee (WMF) (talk) 04:25, 23 February 2023 (UTC)

Technical debt and diversity

There are dead extensions and unmaintained extensions, most of which are under the stewardship project that is seemingly in the freezer currently. Many of those extensions that are dead serve the same purpose as other more successful extensions and should simply be undeployed and scrapped. Likewise there are extensions in the unmaintained category which are keeping WMF on older extensions with legacy software from third parties which is sometimes not even supported anymore. This was also pointed out in the last annual plan.

I like the plan of using metrics for decisions, but consider using existing research (see the research namespace on meta), to filter out bad ideas early on.

Develop not only for the largest projects, like Wikipedia, but have the development open for the smaller projects. A lot of tech that is useful to Wikipedia is also useful as-is to Wikibooks, Wikiquote and to an lesser degree Wiktionary, yet some development stops short of those projects without an clear reason why. Sometimes it is just a matter of deploying that tech to these minor projects. The effort needed to include these projects is so miniscule in comparision to the whole deployment effort of an extension that it baffles my mind why it is not on the table. Snævar (talk) 14:53, 16 February 2023 (UTC)

“Many of those extensions that are dead serve the same purpose as other more successful extensions“ care to elaborate? The only one i can sort of think of is EasyTimeline vs Graph, but id argue both are unmaintained ;)

”but have the development open for the smaller projects” I agree with this. I think it would be very healthy to work on non-Wikipedia projects and I think well see that this will even unblock or deal with technical debt that is holding back Wikipedia and MediaWiki overall. Cleaning out the dark corners might light up the entire room. —TheDJ (talk • contribs) 19:13, 16 February 2023 (UTC)

Dead extensions are mainly EasyTimeline, yes, but also to an lesser degree Flow and Liquid Threads vs. DiscussionTools. There still are some bits laying around in those talk extensions, although there is some undeployment that has happened. I am trying to have an distinction there between extensions that are remotely helpful vs. extensions that have better alternatives, but sure, they are all unmaintained. To be fair, there is some work that has been done, like with Kaltura to Video.js, and then the current upgrade to Thumbor, but I do not see a reason to stop there.

On the non-Wikipedia front there is also Wikisource, but the technology it uses is more different than the other ones, so it is probably an harder sell to WMF. Snævar (talk) 15:50, 23 February 2023 (UTC)

Feedback by User:Dušan Kreheľ on 2023-02-18

Support the growth of high quality and relevant content within the world’s most linguistically diverse, trusted and comprehensive free knowledge ecosystem by enabling and supporting high quality and accessible experiences

• I tried.

Support the funding of Wikimedia projects by making sustainable the technology behind our largest and emerging revenue sources

• Wikimedia Technology Fund of Grants:Programs/Wikimedia Research & Technology Fund is not done.

Question

• What is the relationship between Community Wishlist Survey 2023 and Wikimedia Foundation Annual Plan/2023-2024/Draft/Product & Technology?

Dušan Kreheľ (talk) 19:24, 18 February 2023 (UTC), --Dušan Kreheľ (talk) 19:26, 18 February 2023 (UTC)

Hello @Dušan Kreheľ. Thank you for your question. I am Runa and I support the Community Tech, Inuka and Language teams in the WMF Product department. As you may already be aware, the Community Wishlist Survey is a yearly process that is run by the Community Tech team of the Wikimedia Foundation. Through this process the team gathers a list of suggestions from volunteers that can mitigate issues that they have been facing while doing various activities on wiki. After a community voting period, the team prioritizes from the top few wishes that they can meaningfully work to deliver results. The Annual Plan on the other hand is the yearly planning process for the Wikimedia Foundation and the article here offers the preliminary draft of objectives for the entire Product and Technology department for the FY23-23 period i.e. from 1st July 2023 to 30th June 2024 that is the Financial year followed by the WMF. Since Community Tech is a team within the Product department, its work will align with the overall plans of the department. Hope this is helpful. Runa Bhattacharjee (WMF) (talk) 17:11, 22 February 2023 (UTC)

Novem's two cents

Howdy. I came across this page via the wikimedia-l mailing list. I have a vague idea that the Annual Plan is very important to the Foundation and that it determines what gets worked on, so I gave this a read. Here are some thoughts.

• Summary section: I'm surprised to see machine learning mentioned as an area of innovation and as one of the main parts of the ecosystem. Do we do much in this area?
• Budget Planning section: You have a nice breakdown by percent of each area for FY23-24. Consider adding the FY22-23 percentages/buckets too, for comparison.
• Wiki Experiences section: I found the first 4 paragraphs unclear and difficult to understand. They mention a lot of ideas. But what's the takeaway? Can this concept be slimmed down to its essence? "Wiki experiences are anything related to A, B, and C. These are very important to us because of X, Y, and Z. Therefore we have allocated them a large bucket of 30%."
• Wiki Experiences section: what's a contributor/consumer/content flywheel? Consider adding a layman's explanation and maybe even a graphic.
• Machine learning is mentioned 3 times. Is it possible this is just a fad that isn't worth much of our time? w:User:ClueBot NG is the one example of impactful ML/AI I can think of, and that was volunteer-developed. This area may be over-hyped.
• Signals and Data Services seems to boil down to gathering statistics. Does this deserve 30% of our attention?
• A search for the words "community" and "technical" doesn't yield much about community tech, unless I am missing it. I'd suggest making some kind of community tech goal very prominent in the Annual Plan. You might even want to make this a bucket, and call it something like "Community-Requested Software Work". Community tech is probably the easiest way to get community relations wins. Power users on the various wikis expect the Foundation to do way more to support community tech.
• This document and style of writing was a tough read for me. It could benefit from less abstractions and more examples.

Thanks for listening. –Novem Linguae (talk) 21:20, 19 February 2023 (UTC)

Thanks User:Novem Linguae. I've forwarded your comments to the group working on this planning [which is - as you noted, still at a relatively abstract layer] for their consideration. I've also make sure to link "the flywheel" concept to where it is documented: Wikimedia_Foundation_Medium-term_plan_2019#The_model_for_engagement. LWyatt (WMF) (talk) 17:31, 20 February 2023 (UTC)

Hi @Novem Linguae. I'm a Foundation employee and the VP of Data Science and Engineering. On the topic of machine learning, the Machine Learning team has been supporting hundreds of machine learning models that are used to help with page triage, to provide newcomers a list of tasks they can tackle to help them get comfortable, support for translation of languages that are underserved by the broader internet, and plenty of other uses. The major effort they have been working on is modernizing their infrastructure as we've outgrown the ORES system and there are some serious stumbling blocks for scaling and access.

As for the label "Signals and Data Services".... well, Martin Fowler said that naming is hard [1]https://martinfowler.com/bliki/TwoHardThings.html This bucket does include data analysis that we do to understand the impact of our projects and the tools and features we build, and many more things we might call "services" here: a 3 petabyte data lake managed by our Data Engineering team, our Search Platform work, operation of the Wikidata Query Service, research done or supported by our Research team, releasing our data for public access both as direct download and as replicated mirrors for use in Cloud VPS... but also less technical and more organizational work such as harmonizing the definitions of the data elements we use to ensure we mean then same thing across our work when we use the same words. We clearly need to do a better job of explaining all of the work we do in this space.

TTaylor (WMF) (talk) 17:07, 21 February 2023 (UTC)

Hi Tajh. It's nice to meet you. Thanks for the explanation. Your list is a bit more readable than what is currently in the Signals and Data Services section of this draft Annual Plan. Perhaps your list would be a good foundation for a rewrite of that section. However even your list is a bit hard to read for the non-initiated. I've heard of a data lake but I don't know what it is or what the WMF data lake stores and supports. I don't know what Wikidata Query Service is (is it like Quarry but for Wikidata?). etc. etc. Hopefully we can all work together to educate folks about what Data Science and Engineering does, and to improve the clarity of this Annual Plan draft.

I still think 30% for Signals and Data Services is a bit high.

As mentioned above, I think volunteers are quite interested in increasing the output of and supporting Community Tech. Does anybody know approximately how much Community Tech will receive in this buckets system? Is Community Tech part of the Wiki Experiences bucket? Do we know if it will it be staying the same or increasing relative to last year? cc @DannyH (WMF) and NRodriguez (WMF): Thanks all. –Novem Linguae (talk) 17:41, 21 February 2023 (UTC)

Hello @Novem Linguae. Thank you for your thoughtful input. I am Runa and support the Community Tech, Inuka and Language teams in the WMF Product department. As you are already aware (and please pardon me if I am assuming incorrectly here), the Community Tech team prioritizes their deliverables based on the Wishlist requests received during the year. We are aware that there has been support and criticism of this process, and yet this is a process that has sustained over years and the team has been much appreciated for taking on some of the long waiting tasks. Going by the assumption that most Community Wishlist requests are based on filling in the gap in existing on-wiki workflows, it is most likely that much of the work for Community Tech will fall squarely within the Wiki Experiences bucket. How much of the budget and resource allocation will that interpret to will depend on work to be done in the later stages of the planning process as indicated in the Budget Planning section in the main article. Hope this is helpful at this time. Runa Bhattacharjee (WMF) (talk) 17:15, 22 February 2023 (UTC)

Hi Runa. It's nice to meet you. Thanks for the response, and the confirmation that Community Tech is in the Wiki Experiences bucket. I am aware of the connection between Community Tech and the wishlist and I support it. I think if CT had more devs, then more wishes could be worked on, and that we could even shorten the cycle between when the community requests software and the community receives software. I hope to see us move towards empowering this important team. I'm a bit surprised that "Community Requested Software" isn't a movement strategy or a bucket, and would like to see us move towards prioritizing it to that level. –Novem Linguae (talk) 17:46, 22 February 2023 (UTC)

Hi @Novem Linguae -- thanks for reading over the plan! I think I can speak to a couple other of your points beyond what Tajh addressed. I apologize if you already understand these things and were suggesting only that we elucidate them more clearly in the text. We will try to do so for the next draft!

• Wiki Experiences: I think a simple way to think about this bucket is that it's all about the experiences that we're currently offering to external users through our websites and apps, including the APIs and systems that back those things. It includes most things affecting readers and editors. This makes it quite a large bucket!
• Flywheel: I understand why this is hard to understand intuitively. The "flywheel" is a model that we think may describe the way the Wikimedia projects function in terms of their marketplace dynamics. In the draft plan, we linked to this explanation from 2019 which may help. The idea is that we hypothesize that a larger editing community leads to more content, more content attracts more readers, a portion of whom join and grow the editing community editors, and the cycle continues virtuously. Using this model, we sometimes think about where in the flywheel investment is needed most at any given time in our history. And so the draft plan is talking about a focus on the "content" part of the flywheel, and also on the "community" part. Does this make sense? What do you think of this model for the wikis?

MMiller (WMF) (talk) 04:07, 22 February 2023 (UTC)

Hey Marshall. I think you were in a couple of the zoom calls I attended. Good to see you again. Thanks for this very succinct summary of the flywheel. Makes perfect sense when stated that way. I hope they assign you to write some documents on meta because you explained this crystal clear :) Sounds like the Wiki Experiences bucket is quite large. May make sense to sub-divide it. –Novem Linguae (talk) 17:50, 22 February 2023 (UTC)

Why not expand access to Visual Editor?

Thinking through the Wiki Experiences and related themes more, two big gaps in the new contributor experience jump out at me.

1. VisualEditor isn’t available on mobile
2. VisualEditor is still an “opt in” experience for anonymous editors (at least on English Wikipedia). Even when I do opt in, the preference isn't sticky.

The second thing seems trivial to fix. The first is a heavy lift probably, but it’s super frustrating how limited the mobile editor is. For instance, there are no good tools for creating references from a template or quickly reusing existing ones in an article, so I have to copy/paste wiki text. That’s only annoying to an advanced editor like me, but the difficulty of editing on mobile is likely to create headwinds for investments like growing new editors in developing countries who are mobile-first.

I know everything is a trade off and I like the mobile roadmap items like in-app watchlist a lot, but consider this food for thought. Steven Walling • talk 03:08, 3 March 2023 (UTC)

hi @Steven Walling – I appreciate you naming the relationship between offering people who are new editing interfaces that feel familiar to them and the likelihood that they come back to edit again in the future.

As the Product Manager for the team that is responsible for the visual editor, a few responses to what you shared above…

VisualEditor isn’t available on mobile

Hmm. The visual editor should be available on mobile.^[i][ii] Although, by default, people are still shown the mobile wikitext editor.^[iii]

Are you able to do the following and let me know whether you experience what  "Step 5." describes?

1. On a mobile device, visit a page like https://en.m.wikipedia.org/wiki/Lemon
2. Tap any edit pencil "✏" you see on the page
3. Once the mobile source editor loads, tap the " ✏️▿" icon that appears just to the left of the publish ">" button
4. Tap/select the "Visual editing" item that appears within the dropdown
5. ✅ Notice you're now using the mobile visual editor

VisualEditor is still an “opt in” experience for anonymous editors (at least on English Wikipedia).

What you described above is accurate: at en.wiki on desktop (which is the platform I assume you to be alluding to), the visual editor is an opt-in experience for people who are logged out.

Although, volunteers are actively discussing whether this ought to be changed.

Even when I do opt in, the preference isn't sticky.

Can you please tell me if the below accurate describes what you're reporting here?

1. On desktop, while logged out, visit a page like: https://en.wikipedia.org/wiki/California
2. Tap any "[ edit ]" link you see on the page
3. Notice a dialog that asks you to decide whether you'd like to continue editing or switch to the visual editor
4. Elect to switch to the visual editor
5. Close the tab you opened in "1." or otherwise end this edit session
6. Attempt to another page (also on desktop while logged out)
7. Notice you land in the source editor as opposed to the visual editor which you would've expected the interface to have remembered

... it’s super frustrating how limited the mobile editor is. For instance, there are no good tools for creating references from a template or quickly reusing existing ones in an article, so I have to copy/paste wiki text.

I assume the comment above was written assuming the visual editor was NOT available on mobile and thus may no longer apply. Of course, if this is not the case, and the frustration(s) you're describing still stand, we'd value hearing from you what you consider them to be…

***

i. In case you'd value some additional context about the mobile visual editor, between 2018 and mid-2019, the Foundation prioritized a series of improvements  to it. See mw:VisualEditor_on_mobile.

ii. The Editing Team is also in the midst of developing further improvements to the mobile editing experience in the form of prompting people to add sources when they forget to do so on their own. See more Edit check#3 March 2023

iii. As the comment you made here suggests, we think there is a significant population of people who are not discovering the mobile visual editor thereby blunting its potential impact. With this in mind, the Editing Team is planning to propose this be changed in the coming months. PPelberg (WMF) (talk) 01:31, 7 March 2023 (UTC)

Hey! Thanks for the detailed reply Peter, much appreciated. By mobile editing, I was referring to the iOS and Android apps. Steven Walling • talk 21:11, 7 March 2023 (UTC)

Hello again @Steven Walling!

While we do have a native wikitext editor in the apps, you are right we do not presently have VisualEditor. There are three possible ways of exposing VisualEditor in the apps. I will write it in order of complexity:

1. When a user enters the native wikitext editor, provide an icon akin to what is available on Mobile Web that allows a user to switch to VisualEdtor. Once a user clicks the drop down option for Visual Editor, alert them that they will lose any changes they have made, and send them to Visual Editor on Mobile Web.

2. Use the Visual Editor library or a mobile web view layer (T307923) to essentially nest a web app within the native app.

3. Build a WSYWIG editor natively

-The pros of the first option is that we can likely achieve this within a few short months. The down side is you will have to leave the app in order to use visual editor and return to the app for reading and other features. Any theming you have like dark mode will also be lost when switching over.

- The pros for option 2 is users would not need to leave the app to use the VisualEditor. The cons are, it would take at least a year (probably more like two years) of multiple engineers development time to implement integrating something that already exists on Mobile Web. It would literally just be us wrapping the mobile web editor into the app. This would also mean we wouldn't be able to work on other highly requested features in the mean time. Additionally, should anything break, the apps team wouldn't be able to fix it we would need to rely on the Editing team for those fixes.

- The pros of option 3 is users would not need to leave the app to use a native "VisualEditor" like option (to be clear this wouldn't be exactly like VisualEditor) and the team would not have to rely on another team should things break. The cons are, it would take roughly take the same amount of time it took the Editing team to create VisualEditor (times two since it would be native on Android and iOS). For context it took the Editing team several years to create VisualEditor, so we are talking upwards of 5 years.

What does this mean for our roadmap?

We are certainly open to implementing option number 1 as a temporary solution and have talked about it within the team. I am even happy to push this up in our roadmap for next year, so if you have opinions on making it easier to switch to mobile web please do share them!

As it relates to options 2 and 3, our apps engineers are researching option 2 and option 3 in their 10% time. In the meantime, there is no shortage of highly requested features that we can deliver a lot quicker, which is why we are prioritizing features like patroller tools and watchlist until we are more confident in an approach for improving the editor systematically. Once that approach is nailed down we would then need to get the sign off to take on such a multi-year effort. Additionally, we are squeezing in enhancements to our native wikitext editor along the way (e.g. full page editing and syntax highlighting). JTanner (WMF) (talk) 18:46, 8 March 2023 (UTC)

For option 3 it's worth noting that an extra con would be that it'd add an ongoing maintenance burden to the apps team. The Editing and Parsing teams currently work together to keep VE up to date supporting the markup that Parsoid generates from wikitext (which any in-app WYSIWYG editor would probably also need to be based on to avoid even more work), and the apps teams would need to keep an eye on this as well. It'd also make deployments of that sort of change a bit more complicated by adding a need to keep multiple mobile apps that need to go through app store release processes up to date.

(There's also a bunch of pre-existing extension-specific things that'd need to be reimplemented and then kept in sync with any changes which it'd be nice if the existing work for VE could just be reused. E.g. last year WMDE made a fair number of changes to editing templates + templatedata, and it'd have been more of a pain for them if they'd needed to worry about app compatibility at the same time.)

In fairness, 2 kind of has some of these same deployment headaches depending on exactly how it's implemented -- if it's not loading all of VE in a webview every time then we have to worry about cached old code. DLynch (WMF) (talk) 21:25, 8 March 2023 (UTC)

Thanks to you both! Totally logical approach and conclusions. I definitely appreciate that anything to do with a new editor surface inside the apps is a heavy lift basically no matter what, and that no one actually wants the "easy" version which takes you out of the app into web just to use VE (option 1).

The reason I bring up the idea of tackling it now and breaking it down though is precisely because doing it in any reasonable way is probably a multi-year project. It's the type of foundational work that makes it obvious to me the mobile teams are still not being resourced enough. (Separately we can argue about the technical and resource challenges of fully native vs. web wrapper, but either way doing it right is a big effort.)

A corollary in my mind is a feature you may be familiar with, huddles in Slack. Most people don't know this, but we actually spent an entire year rolling out a wholesale rewrite of the audio/video stack inside Slack before we even started prototyping internally what huddles would look like. WYSIWYG editors are at least as difficult as realtime streaming audio/video products, if not harder.

Some of the other things you're already prioritizing like mobile watchlist and patroller tools will contribute to getting closer to a world where we can acquire and retain massive new cohorts of editors who work primarily (or at least frequently) on mobile. That's the world we should be in, so I love that you're doing those. There is zero doubt that if we really want Wikipedias outside English to grow like they should be, we have to think mobile-first. But to really get a fully mobile contributor flywheel kicked off, we have to tackle the end to end experience, one of the core components of which is a modern editor. So I think it's worth pushing Selena hard with the question: why aren't we able to resource a big bet in the mobile apps like VE, when mobile is the primary platform for Wikipedia readers or any other modern global consumer Internet product? Steven Walling • talk 23:21, 8 March 2023 (UTC)

Hi @Steven Walling! Thanks for your engagement on our draft plans. A couple things: I don't think we've hit the point of diminishing returns on feature improvements that aren’t VE on mobile apps. Given that, I feel ok about a roadmap that doesn't focus on VE immediately. That said, we are starting to figure out how we might do this -- but have no timeline yet. Meanwhile, we are considering a big investment in a different priority related to MediaWiki itself for the next fiscal year. As to why it’s hard to make really big investments, it’s a great question and worth taking some time to talk about at another time because it’s also a question about multi year commitments, which is outside to scope of APP. Once we are through APP I will begin to tackle this question, along with others who are thinking about multi year strategy. SDeckelmann-WMF (talk) 12:50, 10 March 2023 (UTC)

Gotcha! Completely makes sense, thanks for explaining. Steven Walling • talk 18:29, 10 March 2023 (UTC)

Mobile editing

At the moment, there exists iOS/Android and a desktop/mobile website. The mobile version is hopeless incompatible for editing purposes. Why not focus on making the desktop website mobile responsive? With the new skin, the desktop and mobile interfaces don’t differ so much and the desktop largely works already even on mobile devices. Shushugah (talk) 12:55, 4 March 2023 (UTC)

Hi @Shushugah - thank you for your question!

My name is Olga and I’m the product manager of the Web team, who are responsible for the new skin. We’ve made some changes to the new skin that make it easier to use the desktop site on mobile, including introducing breakpoints of width based on which certain functionality appears open or collapsed, various changes for tools, and more. One of the considerations we had with the new skin was to make it easier to adapt new features and functionality to either the desktop or mobile site, yet we still have certain workflows and tools which are better suited for desktop-only or mobile-only use. Due to these, we have not explicitly planned combining the two sites into one, although we have had some conversations about whether that would possible in the future (potentially by having some features or tools being available only at certain resolutions).

Hope this is helpful! I believe @PPelberg (WMF) from the Editing team can add a bit more context and detail in terms of the variables considered in mobile-only versus desktop-only workflows for editing. OVasileva (WMF) (talk) 22:18, 8 March 2023 (UTC)

Thank you, @OVasileva (WMF) and hi @Shushugah.

I appreciate you drawing attention to mobile editing.

Reason being: like you^[i], we see offering mobile editing experiences that lead people to feel the joy/satisfaction/fulfillment/etc. that comes with making a useful contribution to Wikipedias as being core to:

1. Increasing the likelihood that people who start editing, continue editing (retention)
2. Increasing the diversity of the people who are actively contributing to Wikipedia and the types of contributions they are making
3. Causing people who are new, particularly people who are younger and living in places where mobile is the platform they predominantly use to access the internet, to try contributing

With the above in mind, can you please say more about what you mean when you say, The mobile version is hopeless incompatible for editing purposes.? Asked in other ways: what are you expecting to be able to do on mobile that you're not currently able to? What do you expect editing mobile to feel and be like? How does the experience you've had with the current tooling compare to this expectation?

And for a bit of context: my name is Peter 👋 I work as the product manager for the team that is responsible for the core mobile and desktop editing experiences on the web.

---

i. https://meta.wikimedia.org/wiki/User:Shushugah: "I strongly believe that Wikimedia needs to improve its user retention, diversity of contributors and contributions and be more welcoming to new users." PPelberg (WMF) (talk) 01:16, 9 March 2023 (UTC)

@OVasileva (WMF) @PPelberg (WMF) thank you both for responding. I was grumpier in my initial post than I would have liked to be. One long standing bug that has been marked (incorrectly imo) as low priority since 2016 is the ability to see navigation templates on mobile. With time and no roadmap in sight, navigation templates becoming increasingly complex and desktop centric, while on other hand, technological advances potentially make the initial blockers obsolete.

A similar issue remains with talk page banners, they're nearly impossible to find/use on mobile as a reader. For other changes, you likely already know about en:Wikipedia:Mobile communication bugs.

I was pleasantly surprised to see major improvements in some areas, for example editing talk pages on both mobile/desktop have gotten much friendly with subscription to specific sections, visual editor/replies and specifically seeing when latest/last post was made. Huge kuddos on those! Notifications for logged in users also seem to work consistently.

Some other basic pain points when editing on mobile mode

• No ability to edit short descriptions in visual edit mode
• No ability to edit multiple sections (e.g to rotate the order section 1 and section 2) in either visual or wiki edit mode

I know there are a lot of technical challenges when it comes to introducing visual editing on both desktop/mobile and competing priorities, so I appreciate you taking the time. I'm happy to be contacted again for feedback on mobile editing/questions and just hope that enough focus is given on tuning the core, before expanding new features. Shushugah (talk) 12:35, 11 March 2023 (UTC)

Thank you for following up with this additional context, @Shushugah. You doing so is helping me to more clearly see and understand the gaps in the mobile experience that you were referring to above.

I'm going to respond to each of the points you raised below...

One long standing bug that has been marked (incorrectly imo) as low priority since 2016 is the ability to see navigation templates on mobile. With time and no roadmap in sight, navigation templates becoming increasingly complex and desktop centric, while on other hand, technological advances potentially make the initial blockers obsolete.

I think @OVasileva (WMF) can best speak to what – if anything – stands in the way of making navigation templates visible on mobile.

In the meantime, I do agree with the broader point I understand you to be making that by limiting the availability of templates on mobile we could be eliminating an opportunity for us to evolve these templates in ways that more effectively serve the needs of people using Wikipedia on mobile devices.

A similar issue remains with talk page banners, they're nearly impossible to find/use on mobile as a reader.

Considering the mention you made of the new ability to subscribe to specific sections, I assume you have tried out/seen the new mobile talk page design that moves the link that leads people to these banners to a more prominent location.

With the above in mind: can you share what concerns you about how talk pages banners are currently being made available on mobile? Asked another way: what disruptive behavior are you seeing that you think the talk page banners being made more visible/prominent could help curb?

was pleasantly surprised to see major improvements in some areas...Huge kuddos on those!

The rest of the Editing Team will be glad to know you appreciate them...thank you for letting us know as much!

Some other basic pain points when editing on mobile mode: * No ability to edit short descriptions in visual edit mode;

Great spot and thank you for saying something. You should be able to edit short descriptions on mobile this Thursday, once the patch to fix this issue is rolled out to all wikis.

*No ability to edit multiple sections (e.g to rotate the order section 1 and section 2) in either visual or wiki edit mode.

At a minimum, it sounds like you're seeking a way to be able to edit an entire article on mobile as you are able to do on desktop.

Does the above accurately capture what you were describing above? PPelberg (WMF) (talk) 23:13, 20 March 2023 (UTC)

@PPelberg (WMF) Looking forward to the patch on Thursday for small descriptions in mobile! @OVasileva (WMF) happy to hear about some of the challenges/visions of non-mobile templates!

Yes, the ability to edit the entire article like on desktop would be a sufficient solution. I can appreciate that this may overwhelm some users, especially in a large article, but on the other hand, for small articles, splitting it up isn't necessarily an improvement. Regardless of what's a nicer flow, being able to sort the ordering of sections needs to be done in some way, whether in source edit mode (as would be done on desktop), or a future more advanced sticky drag/drop interface.

I glossed over the "Learn more about this page", perhaps because I am so used to the loud desktop banners, that I expected it to be loud on mobile. Perhaps this is an improved UX solution, I'm sure you've done your tests on whether users have easily been able to find/want to find the banners.

My uninformed hunch would be, making it a slightly different color, even the same shade of brown as the banners could make it more prominent/harder to miss. Once I found/clicked on it, I was very satisfied with the UX flow. The banners themselves need to be revamped (combined ratings for example), but that's not a mobile/desktop issue altogether.

Another major topic I completely forgot to mention is, rollback/undoing edits is a complete mystery for me. Have a nice start of Monday/Tuesday depending where you are! Shushugah (talk) 23:52, 20 March 2023 (UTC)

@Shushugah On the topic of undo/rollback on mobile, my team recently published some new designs for diffs on mobile at Moderator Tools/Content moderation on mobile web/Diff. We'd love to hear your input on these designs - they include both Undo and Rollback buttons, alongside other features we think are missing from mobile web! Samwalton9 (WMF) (talk) 13:53, 22 March 2023 (UTC)

There's some long-running debate about how to handle full-article editing, which you can see on task T203151 if you're interested (there's performance concerns, mostly, though we're wondering about how relevant they are now compared to when the choice was initially made 7-ish years ago).

We've actually had a way to trigger full-article editing for a while via a URL parameter (#/editor/all), it's just not linked to anywhere. I have several patches up there at the moment which expose it in some way -- either by just changing the behavior of the topmost edit-pencil or by adding something to the more-menu on those pages... DLynch (WMF) (talk) 15:25, 3 April 2023 (UTC)

General question: Is there a centralised place to track all mobile discrepancies? I understand from a technical/behavioural pov why these are separated but it’s hard to keep track.

Categories are not editable in mobile visual studio mode, which makes usage of wizards/validating the category is spelled correctly (or has more precise difficult) difficult.

@PPelberg (WMF) Question for editing team, Draft talk page seems uneditable?

I hope everyone is doing well, and that no one here is impacted by involuntary layoffs. Recently went thru similar thing with my employer. Cheers and speak soon! Shushugah (talk) 18:43, 10 April 2023 (UTC)

@Shushugah Hi, Peter (PPelberg) is on vacation and might not see this message soon, so I'll try to reply.

I'm afraid we don't have a central list of all the disrepancies between mobile and desktop editors. The closest thing is probably this Phabricator search, which should list all of the known mobile-related visual editor issues: [2].

Based on that search (and a few other queries I tried), it looks like no one has filed a task about the lack of categories in the mobile editor. If I remember correctly, that feature was deprioritized when the mobile visual editor was originally being developed (I think that, at the time, the mobile reading mode did not display categories either).

I replied in that thread about "Draft talk" pages; it seems to be a problem affecting just that one person (hopefully).

-- Bartosz Dziewoński (WMF) / Matma Rex (talk) 20:40, 10 April 2023 (UTC)

Created phabricator:T334449 here Shushugah (talk) 07:56, 11 April 2023 (UTC)

The draft Objectives and Key Results are now published

Dear all, If you have commented on THIS page, then you're probably interested in "part 2" of this Annual Planning work from the product and technology departments: The draft Objectives and Key Results (OKRs). This was published today and represents a more complete, tabular, draft version of all the priorities for the work of these departments' teams for the 2023-24 annual plan. Please bring your comments and feedback to the relevant subsections on the talkpage.

Tagging everyone who already commented on this page: @Shushugah, @Matma Rex, @Steven Walling, @Novem Linguae, @Dušan Kreheľ, @TheDJ, @Snævar, @Nemo_bis.

Also, if you've any recommendations for where I can promote the fact of the new document being published, please tell me.

Thank you, LWyatt (WMF) (talk) 14:26, 12 April 2023 (UTC)

en:Wikipedia:Village pump (WMF) would be my recommendation of where to post this. Although WMF staffers seem to avoid there and post to en:Wikipedia:Village pump (miscellaneous) instead, but I don't think that's as good a place to post it because then it gets mixed in with all the non-WMF stuff. Hope this helps. –Novem Linguae (talk) 14:35, 12 April 2023 (UTC)

Replacing Proprietary Software used in the Wikimedia Projects

I wish that there will be work on replacing software without access to the source code with free or open source software in the next fiscal year. There is for example the Wikimedia Statuspage which is based on Atlassian Statuspage and also maybe other closed source software. I think one goal could be reducing software license fees by about x percent. Can you please offer a list of closed source software used at the Wikimedia Foundation. This goal could also include working on extending BigBlueButton or Jitsi or another Video conferencing solution to better support transcription to make it possible to host sessions in such an solution instead of using Zoom or Google Meet. Hogü-456 (talk) 20:34, 13 April 2023 (UTC)

Create a virtual space for Meetups

I wish a virtual space for Meetups based on Free and Open Source Software open for all community members and if possible without further registration with single sign with the Wikimedia User Account. This should include additional to the Wikimedia Meet Jitsi instance a audio chat with Mumble or something similiar and a virtual map to meet people. I really like WorkAdventure for that purpose. Regarding the moderation of such an platform I think it is possible to find enough people who can look after the platform and help avoiding violations of the Friendly Space Policy. Hogü-456 (talk) 20:44, 13 April 2023 (UTC)