Wikimedia Foundation Annual Plan/2026-2027/Product & Technology OKRs

Wikimedia Foundation
Annual Plan 2026–2027

Wikimedia Foundation Annual Plan 2026–2027

• Summary
• Global Trends
• Progress
• Goals
• Financial Model
• Budget
• Collaboration

Introduction

The Annual Plan is the Wikimedia Foundation’s description of what we hope to achieve in the coming year. This is a time of urgency and focus for the Wikimedia projects: as we have seen with global trends, the Internet and information ecosystem continues to change rapidly. AI is a transformative force on the internet, along with new ways that young generations consume information, and increasing scrutiny from governments and regulations. Recently, we noted that Wikipedia pageviews have been declining.

As these trends have taken shape, we have executed annual plans meant to address them. In our next annual plan, from July 2026 to June 2027, we aim to continue to evolve our technology and experiences to meet this moment. We want to do so at an energetic pace, while preserving and enhancing those things that have made the wikis so valuable. The goal continues to be a multi-generational project where future generations will access and contribute knowledge for free, in ways that work for them.

As with every year, we ask you to shape this plan together with us. We’d like to hear your hopes, concerns, bold ideas, and specific requests, which will then help the Foundation make choices about how to use our time and resources.

For the work of our Product & Technology department, annual planning begins by sharing an early list of “big picture” questions. These questions are by design similar to those we shared last year; many of our challenges remain relevant and require work over multiple years. Beyond this, we will continue to listen and engage through specific product team or topic area conversations, surveys and research interviews, the Community Wishlist, live calls, at conferences, and on our annual plan talk page.

Last time around, this process helped us to prioritize work in the current plan that has benefited our communities and projects. For instance, we heard from both the community and the Product and Technology Advisory Council that mobile editing continues to be a major challenge, so we decided to continue building Structured Tasks, Edit Checks, which we know improve outcomes on mobile, and did additional research. We also used community feedback and the Product and Technology Advisory Council’s guidelines to reshape how we collaboratively develop and communicate our work on readers, bringing communities in earlier to set shared expectations and guardrails that enable responsible product experimentation and ensure our work meets the needs of current and future generations of readers and editors.

We also held a series of listening and discussion sessions focused on Commons about issues that have been raised over the years, which led to prioritizing a number of infrastructure improvements for the Commons databases, some software components, and specific unsupported tools work for video2commons. And we unified the mobile and desktop domains which improves the loading time and search engine visibility of pages, especially for Commons.

Additionally, after years of community concerns with the accessibility of our CAPTCHA, and requests from users with extended rights to step up our detection of automated editing, we deployed a real-world trial of a new bot detection service for both account creation and higher-risk editing, to English Wikipedia and several other wikis.

Looking ahead, the world needs the Wikimedia projects – and a plan to support them – now more than ever. We are doing our best to share all the questions on our minds as we enter the next planning cycle. We don’t expect each of you to answer them all, but we hope that you’ll share what’s most important to you. Thank you for taking the time to reflect and imagine with us. We’ll have more information about next steps in the process in January.

Questions

Global Trends

Global trends have continued to shape not only the Wikimedia projects, but the broader internet. We want to hear more about how those trends are affecting you and how you think we should respond.

• What are the most important changes you’re noticing in the world outside Wikimedia this year? These might be trends in technology, education, or how people learn.
• Outside of the Wikimedia movement, what other online communities do you participate in? What lessons can we take away from tools and processes on other community platforms?
• Has your relationship to AI changed in the last year? E.g., do you see or use AI-powered features and tools (like AI summaries when you use web search, or AI-powered features to summarize or write text in emails or documents) about the same, more often, or less often now than you did a year ago? Do you think or worry about the impact of AI on Wikipedia more, less, or about the same as a year ago?

Experimentation

In order to meet the current moment with urgency and focus, we need to experiment and try new things rapidly, in ways that are healthy for our communities. We are striving to find new ways to experiment alongside our communities.

• What ideas or changes have you wanted to test on your wiki? Are there things you wish you could measure but can't? Do you have specific questions about impact or causality that we should consider – for example, whether a feature or a bug is causing something that you are observing on the wikis?
• A key part of our experimentation with new tools and features is communication and collaboration with our communities. Do you have ideas about how we can deliver improvements quickly while working together with communities?

Newcomers

Research has shown that newcomers struggle to edit and continue editing Wikipedia. We have built a set of features that have been shown to increase engagement by newcomers, and Edit Checks to help them follow some of the policies and guidelines necessary to make constructive edits. How else can we help newcomers become effective contributors?

• What helped you build confidence and understand how to contribute, and how might we build something helpful for today’s newcomers?
• If you have experience in training, teaching or mentoring newcomers, what have you learned about how newcomers can gain the skills to contribute?

Users with Extended Rights

The rise in dis- and misinformation, vandalism, and security threats means that the work of users with extended rights has never been more important, yet their numbers are shrinking on the largest Wikipedias. At Wikimania this year, we brought users with extended rights together to share best practices and come up with ideas for the future. How else can we strengthen and grow our community of editors and users with extended rights?

• How do you prioritise what needs your attention on your wiki? What pages, categories, processes, or tools has your community developed to surface requests or manage backlogs?
• What volunteer-built tool or gadget is most important to your workflow, and why?
• What types of improvements would help more editors get involved with patrolling?

Collaboration

We want to make it easier for contributors to find one another and work on projects together, strengthening overall collaboration and connection on the Wikis.

• Do you ever set editing goals or challenges for yourself or for a group that you’re a part of? How do you set and share these goals? Would you be interested in having ways to do this and share your work with others?
• If you organize events (like edit-a-thons, workshops, or meetups), what is your biggest challenge? What technology could the Foundation provide that would have the most impact on your success?
• How do you show recognition for the work of others on the wikis today? What could help make it easier for editors to express appreciation for each other?

Reading

New user trends show that people are accessing Wikimedia content all over the internet, even if they don’t visit wikipedia.org. But with fewer visits to Wikipedia, fewer volunteers may grow and enrich the content, and fewer individual donors may support this work. We are currently running experiments that focus on both enhancing familiar ways of learning for active readers, and building new ways of learning for new readers. What do you think would be most impactful in bringing and retaining readers on Wikipedia?

• What might keep new generations from finding Wikipedia content interesting and engaging? How might we overcome that using our existing content?
• Chatbots and AI-driven search are increasingly popular as ways to seek information. With this trend unfolding, what might we do to encourage more people to use Wikipedia as their go-to place for knowledge?
• What have been effective ways you have seen others learn and explore knowledge outside of Wikipedia? Can any of these ways be used as inspiration for Wikipedia?

Discuss

Product and Technology Objectives

The objectives presented here are in draft form and are open for comments and discussion.

• The Objectives represent a high level direction.
• The "Key Results" (KRs) represent a measurable way to track the success of their objectives.
• The underlying "Hypotheses" for each KR represent the actual work we are doing to try to achieve the associated key results. They will be updated in this document and on the relevant project or team's wiki pages as insights are gained throughout the year.
• is for work the Foundation is prioritizing under the Community Wishlist.

Reach

Audience Growth

• Objective: People who search for encyclopedic information online and outside of Wikimedia projects get relevant and valuable results from Wikimedia projects that make them want to read more on our projects. Discuss
  • Context: Google search, our main traffic source for readers, editors and donors, has fundamentally shifted due to Google AI overviews. Traffic, new editors, and donors declined last year and are expected to continue dropping as AI adoption accelerates, posing an existential risk. We also face new competition in search from AI-generated content. These challenges necessitate finding new ways to proactively ensure that our content gets in front of audiences via legacy and new online search experiences and continues to bring new readers and donors to our projects.
  • Objective Owner: Maryana Pinchuk
    • Key Result: By end of Q2, 50M pageviews projected to be gained by the end of the fiscal year from interventions in Q1-2.
      • Context: Work in this objective will start in Q3 FY25-6. The work of this KR is: (1) audit 3rd party Search Engine Optimization data/insights (e.g., Google Search Console, Bing Web Tools) (2) identify sources of reader demand data (e.g. Google Trends, TikTok creator insights) (3)identify and prioritize opportunities to increase content visibility in these experiences (via possible factors such as sitemap accuracy, content indexing, search-engine-specific annotations, etc.) (4) surface gaps in content coverage relative to reader demand (5) work with Wikimedia teams, communities, and partners to implement changes that increase search-referred traffic to Wikimedia projects.
      • KR Owner: Maryana Pinchuk
    • Key Result: Partnerships, Fundraising, and Product & Technology have reliable traffic health metrics reporting that allow them to make strategic decisions on readers, contributors, and revenue.
      • Context: This is working towards a unified/reconciled page view traffic for consistent modelling across reader, donor, and editor acquisition. This is a continuation of this year’s WE5 work to define traffic health metrics, understand downstream impact on contribution from external traffic sources, and measure impact of sharp visibility declines/increases.
      • KR Owner: Maryana Pinchuk

Grow Distribution and Recognition

• Objective: Grow our content distribution and brand presence in other places on the internet – both bringing Wikipedia to new audiences in other places and new attribution practices with reusers so that more people encountering our content off-wiki recognise it as coming from Wikimedia projects, and more of them participate onwiki. Discuss
  • Context: The majority of people encounter Wikimedia content off our platforms, with many not realising Wikimedia is the source of their content. As AI/LLMs, search, and social platforms increase zero-click behaviours, fewer people are aware of Wikipedia, and we see a decline in those who come to Wikipedia to read, edit, and donate. This Objective is about growing the Wikimedia ecosystem by reaching people beyond Wikipedia and turning that exposure into meaningful engagement. The work falls into two connected areas. One area focuses on off-platform reuse. As Wikipedia content is reused in AI answers, search results, and social posts, we aim to ensure people recognize Wikipedia as the source and have clear ways to engage further. Improved attribution helps convert off-platform encounters into readers, donors, and editors.The second area focuses on extending Wikipedia’s presence to new surfaces. Through experiments with future audiences, we test how Wikipedia content and identity can live in places like social video, games, and other platforms where new audiences already spend time.
  • Objective Owner: Rita Ho
    • Key Result: By the end of Q4, more users are exposed to Wikimedia projects monthly across external products using the attribution framework. Improving attribution in external products from none/limited to effective (based on the attribution framework) will increase referral traffic (page views not coming via search). Targeting an increase of 25-30 million page views generated through our interventions (i.e., contributing to 25-30% of the objective target).
      • Context: This will be a follow up to the FY25-26 WE5.3 Attribution framework KR work. The idea is to apply and evolve the Attribution framework in more contexts. In particular: (1) Evolve the Attribution framework, expanding it to more usecases and facilitate its internal and external adoption. (2) Develop materials to pitch the initiative and outreach to high impact adoption partners. (3) Implementing attribution adoption proposals for key partners. To get a better perspective, we want to improve observability of non-search referral traffic from partners applying the attribution framework. Criteria for evaluation will be informed by referrer experiments.
      • KR Owner: Pau Giner
    • Key Result: Develop novel re-uses of Wikimedia content off-wiki applied by four prioritised partners that result in increased referral traffic (page views not coming via search). Targeting an increase of 70-75 million page views generated through our interventions (i.e., contributing to 70-75% of the objective target).
      • Context: Establish a collaboration with partners on strategic areas where better content reuse has potential high impact, and engage with them in experiments to apply new approaches to reuse Wikimedia content in the context of the external partner. Coordinate with internal and external teams to implement proof-of-concepts and run experiments that allow learning the impact of each approach on traffic. Measurement of third-party analytics of audience data to inform strategies to deepen engagement on our platforms.
      • Note: A previous "Future Audience experiments" KR will form a part of this KR.
      • KR Owner: Pau Giner

---

Engage

Abstract Wikipedia

• Objective: Demonstrate Abstract Wikipedia's viability as a scalable, human-centered way to create multilingual encyclopedic content. Discuss
  • Context: The Internet is increasingly shaped by automatically produced text that is often opaque and unverifiable. At the same time, manually created knowledge alone cannot adequately fill multilingual content gaps. Can Wikipedia’s human-led model of knowledge creation scale across languages without sacrificing trust, transparency, or community control? By making one contribution reusable across many languages, Abstract Wikipedia seeks to answer that question.
  • Objective Owner: Amy Tsay
    • Key Result: By the end of Q1, ensure that fragment rendering performance of the integration into Wikipedias is maintained without regression as deployment expands from the first demonstration into the initial target language Wikipedias, so that the system remains responsive and welcoming to editors as they draft changes.
      • Context: Deepen multilingual viability for Abstract Wikipedia by ensuring that expansion of availability and usage does not impair performance. To make sure that Abstract Wikipedia is viable as a platform for users and sustainable for the Foundation, we will rebuild our prototype integration into Wikipedias, expanding from the work done in FY26Q4 into one that supports and scales successfully to our envisioned 5–10 additional early adopter Wikipedias, in a way that keeps down the operational cost for Wikimedia in terms of server time and so production load/scale.
      • KR Owner: James Forrester
    • Key Result: By the end of Q1, increase the number of sentences and core elements in Abstract Wikipedia articles, with more articles receiving follow-up edits.
      • Context: This KR builds on our current focus on supporting the core community by strengthening the building blocks that enable richer, longer articles. It shifts the emphasis from simply increasing article volume to fostering meaningful article development that aligns with community expectations around quality. At the same time, it deepens editor engagement while keeping flexibility to adapt based on evolving community needs.
      • KR Owner: Laura Morgantini
    • Key Result: By the end of Q2, one proof of concept article is created on Abstract Wikipedia and integrated in three Wikipedias
      • Context: This KR area defines measures for content growth and maintenance rates for the different relevant contents of Abstract Wikipedia, and based on these, measures that indicate that contributor communities will be able to to create and maintain Abstract Wikipedia articles, Wikifunctions language functions, relevant Wikidata Lexemes, and/or integration into Wikipedia at a rate that can meet the threshold for scalable content viability. We also develop an understanding of second-order effects on the development of existing Wikipedia language communities.
      • KR Owner: Satdeep Gill
    • Key Result: By the end of Q1, 100% of pilot cohort users have migrated away from Blazegraph endpoints.
      • Context: The Wikidata Platform backend replacement will be ready to serve production traffic by end of FY25/26. The new system will offer capacity improvements for Wikidata, Wikidata Query Service (WDQS), and all systems integrated with either tool. We are beginning our migration with a small group of pilot users to baseline migration efforts and user impact of the new backend. The learnings we collect during Q1 will be used to support the Abstract Wikipedia use case in Q2.
      • KR Owner: Brandon Tracy

Deepen Reader Engagement

• Objective: As pageviews decline, readers from multiple generations will experience more value from every visit and become more engaged over time, leading to measurable increases in retention Discuss
  • Context: Even as overall pageviews may decline, we want who remain to engage more frequently and deeply, sustaining Wikipedia’s brand as the most important and most trustworthy repository of knowledge in the world’s collective consciousness. We plan on doing this through presenting our existing content in ways that make every first visit helpful and memorable so that new readers return, and active readers can easily find opportunities to go deeper and grow into the active readers, donors, and contributors of the future.
  • Objective Owner: Olga Vasileva
    • Key Result: By the end of Q2, achieve a 0.5pp increase in logged-out 21-day retention on mobile web and a 1pp increase in logged-out 14-day retention on apps, for readers presented with updated mobile experiences compared to readers in the control group
      • Context: On web, we have seen from FY25-26 tests that we can move logged-out reader retention via feature changes, and the Y/Y decline we see in pageviews gives us urgency for acting to improve casual readers' experiences so that they will come back to the wiki projects. We are continuing to learn about how precisely we can measure the cumulative impact of feature changes with our tools, and expect to set an updated goal for H2 FY26-27 based on what we learn in H1. On apps, second week retention among returning app readers is already high and improving YoY. The primary area of concern is new app readers returning after their first session, which is why the app portion of the KR explicitly focuses on establishing the first return by following first open cohorts to avoid conflating results with composition effects.
      • KR Owner: Sherry Yang
    • Key Result: Increase 2nd-week logged-in reader retention on web by 0.5% pp and 2nd-day user retention on apps by 1.5% pp by the end of Q2.
      • Context: As part of the Readers Strategy’s focus on encouraging consumers to engage more deeply with Wikipedia’s content on-site, this KR aims to drive improvements in the retention of active readers across all platforms. Because apps and web have different metric baselines, we will set separate goals for these platforms. The baseline for Logged-In reader retention is WIP in Q3/Q4 of FY25-26. We do not have this figure yet, and once we do, we may adjust the goal.
        • KR Owner: Hsuanwei Fan
    • Key Result: Increase by 50% the number of monthly active reader accounts created in 2026-26 Q1 and Q2 compared to that period in the previous fiscal year
      • Context: We plan to cultivate readers’ personal connection to Wikipedia by encouraging readers to progress from passively reading into actively learning. We will do this through encouraging readers to curate their own experience, personalization, and exclusive features for logged-in readers. A major tool for this will be encouraging readers and donors to create accounts, so they can have features that persist from session to session. We want frequent readers to see their usage of Wikipedia as part of their core identity. With more accounts being created we will need clearance from SRE on DB & Performance Capacity.
      • KR Owner: Jan Drewniak
    • Key Result: Achieve 4 million new installs of the Wikipedia app across Android and iOS via on-platform marketing and interventions
      • Context: Wikipedia's app users read 6x more pages per month than mobile web visitors, while mobile web sees billions of visits each year — making web-to-app migration the highest-leverage growth mechanism available to the apps team. Organic installs (app store discovery, word of mouth) currently run at ~3.1M per year combined and are projected to grow ~15% annually. But organic growth alone cannot close the gap to the 5x Active Reader target by 2028: our projections require approximately 11.6M non-organic installs annually by the end of 2027, meaning FY26-27 must establish channel infrastructure, feature handoff strategies, prove conversion rates at scale, and begin meaningful volume. The 3M non-organic target represents approximately 26% of the full annual Lever 3 gap — a credible first-year foundation that allows the team to build measurement infrastructure, validate conversion rates across platforms, and scale from the May 25th Birthday Campaign into an always-on capability. Reaching 3M non-organic requires showing banners on only ~3–4% of annual mobile web PV, a light footprint compared to the ~12% of December PV used by the fundraising campaign. The May campaign will provide a real-world conversion rate baseline, however for now we are estimating a rate of ~0.077% (derived from the December fundraising banner benchmark with a friction adjustment for app install vs. donation click). The FY26-27 conversion rate target of ≥0.09% reflects improvement through creative optimization and better placement — approaching but not yet matching the fundraising banner rate of 0.103%. Web-to-app banners and feature integrated handoffs on Wikipedia's own mobile web inventory are the primary channel (8.3B monthly mobile PVs represent a large addressable surface with qualified leads and no media cost). Paid media is a secondary channel for platform-specific targeting and markets where web traffic alone is insufficient. At 75% 30-day retention, the 3M non-organic installs are projected to yield approximately 2.25M active readers — a meaningful contribution toward the 2028 goal that no other single lever can replicate at this scale
      • KR Owner: Nazneen Nawaz
    • Key Result: Increase recurring donor signups on-platform by 8%, while maintaining 2nd month recurring donor retention
      • Context: Our Reader-Donor Progression strategy aims to build sustained, relationship-based support by meeting readers where they experience Wikipedia’s value—on-platform. This KR focuses on implementing donor experiences across web and apps that evolve as readers deepen their engagement, from reading to giving to ongoing support, in ways that strengthen long-term funding beyond traffic alone. Work under this KR will prioritize contextual giving experiences, donor recognition, and impact communication within the on-platform reading experience.
      • KR Owner: Jazmin Tanner
    • Key Result: By end of Q4, account-holding, on-platform donors will have a higher average gift than the rest of the on-platform donor population
      • Context: We plan to cultivate donor personal connection to Wikipedia by encouraging donors to delve deeper into Wikipedia through account creation. A major tool for this will be encouraging donors to create accounts, so they can have features that persist from session to session.
      • KR Owner: Jan Drewniak

Contributors

• Objective: We increase the number of retained editors by 20% by delivering a structured, progression-driven, and more meaningful mobile-first editor experience. This is a milestone on our way to doubling retained editors within two years. Discuss
  • Context: To respond to the reader team’s focus on active readers, we need to create clear pathways for those ready to become editors, then help them contribute constructively, stay engaged, and progress quickly without inflating moderation backlogs. For that we will: 1) Lower the barrier to entry through a more structured editing experience while equipping experienced editors to keep up 2) Connect the dots for volunteers to help them grow via a personalized dashboard powered by recommendations as well as other interventions aimed at re-engagement and progression 3) Make contributing more meaningful by offering motivational moments and helping them understand their value through recognition and more visibility into their impact.
  • Objective Owner: Sonja Perry
    • Key Result: By the end of Q2, achieve an x% increase in the proportion of distinct registered users with ≤100 cumulative edits who publish at least one constructive edit on mobile web through controlled experiments, compared to editors in the control group.
      • Context: Contributing constructively to Wikipedia using a mobile device involves too much toil and patience. DE1.1 will broaden the availability and increase the number of structured contribution opportunities that align with what people using relatively small touch screens are motivated and equipped to offer.
      • KR Owner: Peter Pelberg
    • Key Result: By the end of Q2, achieve an x% increase in the weekly edit rate for editors who are presented with new motivational moments through controlled experiments, compared to editors in the control group.
      • Context: For this KR, we’re focused on the "why" of the contributor experience—in other words, giving people compelling reasons to edit. We want to provide new, inspiring moments to editors, so they continue to feel motivated to edit in 2026 and beyond. We plan to measure our success by looking at the weekly edit rates of those targeted by our experiments, i.e. the count of edits per user per week. The weekly edit rate applies to all namespaces, since we're interested in both the production of encyclopedic content and the nurturing of a dynamic online community (e.g., editing articles, talk pages, user pages, WikiProject pages). Some of our experimentation ideas include: creating a way for editors to track and share their editing goals, weekly personalized editing impact reports, improved ways to recognize the good work of other editors, improved ways to generate worklists or "to-do" lists, and incentivizing notifications (e.g., “If you do 10 more edits, you can gain access to Wikipedia Library”). All of these experiments will be under the goal of creating more moments that may motivate and inspire people to keep on editing.
      • KR Owner: Ilana Fried
    • Key Result: By the end of Q2, achieve an x% increase in second-week retention for editors who are presented with interventions focused on editor progression through controlled experiments, compared to editors in the control group.
      • Context: We will advance a unified personal Dashboard that supports the full reader to new editor to new moderator journey. This KR will integrate the Newcomer Homepage and Dashboard MVP into a cohesive experience with a clear progression system that helps contributors move beyond their first edits and continue developing their skills. In parallel, we will strengthen onboarding pathways for structured patrolling and cleanup work, enabling interested contributors to take on greater responsibility, contribute productively, and help reduce patroller backlogs over time.
      • KR Owner: Kirsten Stoller
    • Key Result: By the end of Q2, achieve an x% relative increase in the 30-day survival rate of articles created by editors with <100 edits who were presented with a guided article creation flow through controlled experiments, compared to editors in the control group, while maintaining or increasing the total volume of surviving articles across the experiment.
      • Context: Creating an article is a high-intent milestone that currently lacks guardrails, leading to high deletion rates and editor frustration. Building on the Q4 FY25/26 experiment testing the first version of pre-VE article guidance, results will be available at the start of Q1. The first month of Q1 will be used for analysis and decisions based on a pre-defined decision matrix. Depending on results, Q1 months 2-3 will focus on iteration or early rollout. Q2 will focus on scaling. The KR is shaped by three tracks: (1) Primary: iterating and scaling pre-VE guidance based on Q4 learnings. (2) Secondary: in-VE guidance, research-dependent and not a build commitment without validation. (3) Pivot option: article expansion if new article creation proves too challenging. Success is measured primarily by 30-day survival rate increase for articles created by junior editors in the treatment group vs control. Secondary metrics include total surviving articles, abandonment rate, and funnel drop-off. A pre-defined experiment decision matrix will guide Q1 decisions, including segmentation by platform and editor experience level.
      • KR Owner: Gerard Galofré

Safety & Security

• Objective: We protect our trusted volunteers and expand their capacity to deal with bad-faith activity, through signals and tools that make those volunteers more efficient, and platform-level automation that can help detect and contain bad-faith activity from the start. Discuss
  • Context: Our safety and security strategy in FY26-27 is to invest in two complementary areas where WMF intervention can make volunteers work go further and enable quick handling of bad-faith content. We will provide high-certainty signal information and focused tooling which will accelerate and empower volunteers, and we will detect and contain bad-faith activity from the get-go through centrally managed automated systems that can precisely and usefully implement community policies. At the same time, we will work on reducing the risk of compromising UWERs’ accounts and the platform by applying the account security foundation we built last FY and adding smart, manageable constraints on how UWER (and other) user accounts could be compromised or misused.
  • Objective Owner: Eric Mill
    • Key Result: By the end of Q2, introduce automated systems that, by detecting and acting on bad-faith activity, reduce by 20% the median time from attempt to mitigation within a 7-day window.
      • Context: Platform interventions based on centrally managed automation, that precisely and usefully implements community policies, to detect and contain bad-faith activity earlier in the process.
      • KR Owner: Kosta Harlan
    • Key Result: By the end of Q2, introduce high-certainty signaling information and tools which enable UWERs to more quickly limit impact of bad-faith activity, reduce by 10% the median time from attempt to mitigation within a 7-day window.
      • Context: Product interventions that directly empower trusted volunteers to detect, investigate and make decisions about bad-faith activity. Our UWER are the backbone of combatting vandalism and abuse, in every wiki and at every level. They are already expert in a mix of automated systems (such as AbuseFilter, or community-blessed bots) and manual systems (their own investigation and blocking/reversions/etc) to deal with this behavior. There are relatively few of these users compared to our platform size, and their lived experience with user behavior and our platform is precious. They can discern the difference between likely good-faith and bad-faith behavior, and can thoughtfully compare gray-area situations in a nuanced way, in a way that we cannot and most end users cannot. UWER should be spending their time in the most high-value way possible – for efficiency, as well as for morale and retention.
      • KR Owner: Ollie Kryva
    • Key Result: By the end of Q2, reduce the time from occurrence to resolution of potential account compromise incidents by 50% year-over-year, while adding at least one account-specific signal and one signal based on attempted privilege use to our incident detection.
      • Context: Protecting user accounts, especially UWER, from being misused or compromised, by enforcing security criteria at the time that sensitive actions take place and improving our ability to detect and combat compromise attempts, by the end of Q4. We currently monitor the total number of login attempts, and when there's a spike we manually investigate to find out if any accounts were likely compromised. We need to automate more of this work so that it will take less human effort and compromises are detected more quickly. We also need to detect potential account compromises using other signals so that we're more likely to find out about compromised accounts, but we need automation for that to be sustainable. When account compromise does happen, the impact is highest if the compromised account is a UWER who can take privileged actions that affect the security or privacy of themselves or others. UWERs also tend to use more user scripts and gadgets, making them more vulnerable to compromise. We now enforce 2FA requirements for these accounts, which helps prevent password-based compromise, but we need to defend against other types of compromise and mitigate the impact of the ones we don't manage to prevent.
      • KR Owner: Roan Kattouw

---

Protect

Scalable System for Responsible Reuse

• Objective: Our knowledge infrastructure scales for the demands of a changing web, becoming more resilient to scaled scraping and offering clear pathways for developers and reusers to access and use content responsibly. Discuss
  • Context: As bot behavior evolves constantly and rapidly, we aim to strengthen our ability to respond to new threats, while investing in discoverability and support for pathways that enable responsible reuse, content and ecosystem growth. This work builds on last year’s efforts under WE5:Responsible Use of Infrastructure, focusing on scaling our approach and further building out the system for responsible reuse. This includes improving our bot detection and defense mechanisms to scale for rapidly changing bot behavior; investing in our API offering and discovery of “golden, supported paths” for access, and making our media infrastructure more resilient, aiming to support both our human users and sustainable reuse of media content. We aim to focus on what we can reasonably support and scale, fostering growth opportunities in areas most beneficial for the Wikimedia mission. This means working towards a scalable system where routine or automated processes for detection, triage and remedy of abuse will handle the majority of issues. Providing clear and sustainable pathways will empower technical contributors and reusers to access data, encourage contribution, and help sustain the Wikimedia projects.
  • Objective Owner: Birgit Müller
    • Key Result: Reduce Site Reliability Engineering (SRE) staff FTE-hours consumed by reactive scraper defense by 50% by end of Q4.
      • Context: The big, unexpected story of the past fiscal year was an intensifying battle of attrition against scaled scraping of our content, particularly scraping of images and other multimedia. The complexity of defending against scraping has increased considerably because of the rise of residential proxy networks – millions of personal home & mobile Internet connections that are questionably leased out to commercial re-users so they can harvest data surreptitiously. These proxy networks are more than large enough to totally obsolete many kinds of traditional bot defenses, like per-IP address rate limits. The result of this has been not just lots of Site Reliability Engineering time spent doing purely reactive firefighting work in response to aggressive scraping, but also delays of important project work, and even worse, non-trivial reductions in our projects' reliability and speed for real human readers and editors. Last fiscal year’s baseline shows ~600–700 SRE FTE-hours annually spent on reactive scraping response, with high variability (typically 30–50 hours/month, peaking at 200+). This year, we aim to reduce that by 50%. We face the largest and most well-distributed botnets in probably the entire history of the Internet. Content scraping using those botnets is persistent, with repeated attempts to bypass traffic filtering rules Site Reliability Engineering has manually put in place. We expect to find the highest community impact and lowest initial difficulty (best signal-to-noise) by focusing on infrastructure- and user-impacting scraper incidents, which is part of the rationale for the metric.
      • KR Owner: Chris Danis
    • Key Result: 50% reduction in video content served from core data centers by the end of Q1.
      • Context: Our current approach to video means that only short-form video can be cached in our Content Delivery Network (CDN), meaning all requests for long-form video must be served from our core data centers. During traffic spikes caused by exceptional real world events, this can saturate inter-data center network links and place our ability to serve other requests at serious risk. We have seen this happen when as few as several hundred users simultaneously request a long-form video during periods of heavy traffic. By moving video delivery from HTTP range requests to adaptive bitrate streaming, videos will be transcoded into a series of chunks that are individually small enough to cache in the CDN. This will provide readers with a smoother, higher-quality video playback experience, whilst making our infrastructure more resilient by ensuring that popular videos can be served from geographically close edge locations. Using request data for April 2026, our baseline is 14.9–15.9TB/day of video served from core data centers, with a target to reduce this by 50% to 7.4–7.9TB/day.
      • KR Owner: Jonathan Tweed
    • Key Result: By the end of Q4, reduce number of remaining known out-of-policy dependencies from commercial users by 95%.
      • Context: As part of ensuring fair infrastructure usage, we're requesting commercial companies accessing our data at scale to use our Wikimedia Enterprise services, designed for high-volume and commercial use cases, rather than scraping pages or overusing community resources. Commercial companies using our public infrastructure must choose to migrate or face a block or reduction in services. Work under this KR focuses on accelerating migration for the remaining 20 highest-volume bots by commercial users to Enterprise-level APIs, further reducing infrastructure load. While we've successfully moved a number of high-volume commercial reusers to Enterprise, work remains to develop the core features that commercial entities need in order to complete those remaining migrations.
      • KR Owner: Chris Petrillo
    • Key Result: A relaunched developer portal offering a unified experience for technical contributors and third party content reusers results in a 2x increase in human views within 4 weeks of a Q3 release.
      • Context: This work focuses on creating a modernized portal experience, where we will promote our preferred API pathways for community and commercial use. Wikimedia APIs are utilized by a wide variety of developers, including commercial reusers, technical volunteers, researchers, and WMF staff, but developers consistently struggle to discover what APIs are available or identify the right one for their persona or use cases. Both topics rank lowest on the developer satisfaction survey, with only 54% and 43% agreeing that documentation is easy to find and that it is clear which API to use, respectively. The unified developer front door addresses this by creating a single, authoritative entry point that guides key developer personas toward well-supported, and clearly differentiated API solutions. Additional resources for responsible use such as API policy and best practice documentation enables developers to quickly understand what is expected and empowers them to self-select into the most appropriate pathway when first building, instead of needing to be redirected later. The target metric encapsulates the initial spike in interest upon relaunch, relative to the existing baseline. The baseline for measurement is likely human traffic to the existing developer portal, which averaged around 1k page views per day prior to the spike in bot traffic in 2024. An updated baseline will be established in Q1 following the initiative focused on adding the ‘bot likeliness’ metric to all webrequest traffic. Once the portal and preferred APIs are live, we will continue to measure ongoing new user adoption and transition of existing applications towards the preferred pathways.
      • KR Owner: Halley Coplin
    • Key Result: By the end of Q4, 50% of community API traffic is redirected through preferred, next generation APIs.
      • Context: Wikimedia's current API landscape is fragmented, resulting in inconsistent structures, overlapping functionality, and uneven quality that makes it difficult for developers to build reliable tools and for Wikimedia to sustainably support what it offers. Expanding on work delivered in FY25/26 through WE5.1 and WE5.2, we will enforce a golden path of API development to deliver a suite of next generation APIs across four key areas: fair access, to ensure reliable and equitable usage through universal rate limiting and improved developer identification; performance, to make APIs more sustainable at scale; consistency, to simplify and clarify our API offerings through common structures; and documentation, to ensure every API meets a high quality standard through expanded OpenAPI support. By systemically embedding these standards into how APIs are built and delivered, we ease the burden of compliance from individual teams and give existing APIs a clear path to elevation. These next generation APIs will then be promoted through the unified front door, replacing or supplementing existing offerings with options that are more reliable, better documented, and easier to use. At the start of this fiscal year, no existing APIs fully meet the criteria to be considered preferred next-generation APIs. Success will be measured by the share of community API requests flowing through preferred next generation APIs as they are introduced, alongside secondary internal conformance metrics for each thematic area. In this case, ‘community’ traffic focuses on API usage that primarily serves mission-supporting features, tools, bots, and external applications that are not associated with external commercial companies or use cases.
      • KR Owner: Halley Coplin
    • Key Result: Create an architecture for thumbnails that can support growth of 50M images over the next five years by the end of Q1.
      • Context: Our current approach to image thumbnailing is placing unsustainable pressure on the service (Swift) used to store uploaded files. Previous work to standardize thumbnail sizes has created some headroom, but this is not sufficient to support a continued growth in uploads. We currently generate and store thumbnails indefinitely, which is causing Swift’s index of stored files to grow at an order of magnitude faster than uploads. Before committing to a significant change in how we generate and serve thumbnails to users, we need to better understand what options are actually feasible, so that we can determine what the right path forward looks like. By the end of Q1, we will have completed an assessment of alternative approaches to generating and storing thumbnails, proposing a new architecture for thumbnails that supports continued organic growth of 10M images a year, over the next five years.
      • KR Owner: Jonathan Tweed

---

Enable

Strengthening & Risk Mitigation of the Platform

• Objective: Our platform is more capable of supporting change, and is less vulnerable to structural risks, in a fast evolving internet and geopolitical landscape. Discuss
  • Context: The internet, and the cultural landscape of the world are evolving quickly around us. As a consequence, we need to reevaluate what are the biggest risks that our platform is facing, and at the same time understand what opportunities we have to support more radical changes to the way we serve our users. Some risks have always been present, but become more critical given the shifting internet landscape; we cannot ignore them anymore. In other cases, we might want to make changes to how we serve our users to respond to the decline in page views, but these changes are hindered by the axioms that have been the foundations of our platform for a long time. We need to evaluate and address both these risks and opportunities to sustain our long-term growth
  • Objective Owner: Giuseppe Lavagetto
    • Key Result: By the end of FY26-27 Q4 develop a process and tooling to scan 100% of container images deployed from the container registry to the Wikikube cluster for a pre-defined set of security vulnerabilities and scan 100% of the images deployed from the container registry to the Wikikube cluster periodically and on demand.
      • Our container registry is at the core of most of our operations, hosting container images used both for serving the website and for running our data lake and machine learning alike. We build images for a lot of the services we use in our production environment by downloading artifacts at build-time from the internet; checking them for vulnerabilities is a first step in ensuring the security of our supply chain. In addition, periodically scanning images that are running on our production kubernetes clusters for known vulnerabilities will ensure we don’t run software with long-known high or critical vulnerabilities in production for a prolonged period of time. In addition, the current setup of the container registry, which was built mostly as an MVP, poses limitations that are increasingly risky and require increasing amounts of maintenance time.
      • KR Owner: Lukasz Sobanski
    • Key Result: By the end of Q4, onboarding, ownership, and SLOs are clear to teams who want to store, process, and serve MediaWiki data, evidenced by at least two product experiences being built on well-supported and curated architectures.
      • The ability to easily iterate on product features and rich experiences will be critical for us to adapt to a changing landscape of user behaviors and expectations, but we’re currently held back by a fragmented and complex ecosystem for storage, computation and serving. It is very difficult for Product and Infrastructure teams to develop robust features that depend on more than basic computation done from within MediaWiki itself, with recent and upcoming use cases including Year In Review, Structured Tasks, and data-driven anti-abuse workflows. We call this kind of data (and, often, the capabilities needed to work with it) “derived data”. This is an inherent risk: the absence of streamlined solutions has resulted in complex and heterogeneous architectures with unclear support status or reliability guarantees, as the ecosystem effectively imposes a fixed cost to every new feature. We need to build and curate solutions and processes that allow teams to compute derived data, store it offline, transfer it to online storage for live consumption, and serve it in production, with well-understood onboarding and support stories.
      • KR Owner: Guilherme Gonçalves
    • Key Result: By the end of Q3, we have tested the ability to restore some of our projects data from external backups that cannot be compromised by an unauthorized actor
      • The Wikimedia Foundation (WMF) currently has geographically redundant backups implemented in its two core datacenters. These backups are self-hosted and will be subject to the same amount of risk that may be faced by the rest of the devices hosted in WMF datacenters. These risks include but are not limited to compromise and other destructive attacks, malicious insiders, increased sophistication of malicious actors, a complete loss or corruption of the data in our core datacenters and other types of attacks. To safeguard the mission and future of free knowledge we will work on a plan to identify a suitable location to host offline backups of our important data including all the text from Wikipedia and our other projects, all the media files on Commons, all the code and configurations on Gerrit and Gitlab and all the files on our server hosts at a suitable, third-party vendor and work out adequate security measures related to access and authorization.
      • KR Owner: Kwaku Ofori
    • Key Result: By the end of Q3, our platform is able to sustain 20% of page views from logged-in users
      • To respond to the decline in human page views, part of our strategy for On Wiki users is to enhance their experience by making it more appealing when logged in, see OW3.1. Right now, serving a page view to a logged-in user costs our infrastructure hundreds of times as much as serving one to a logged-out user. In fact, less than 1% of all of our page views come from logged-in users, and we depend on this number to be low; if 10% of anonymous readers decided to create an account, it would be hard to sustain for our infrastructure, and moreover, these users would get much worse performance from the website. While the risk lies first of all in increasing the bucket of logged-in users, with previously cached anonymous users now missing caches, thus creating an infrastructure sustainability risk, that is only part of the story. There is a second factor that is relevant: logged in users nowadays pay a severe performance penalty compared to logged out users, and given we know that latency is inversely correlated to user retention, the current UX for logged-in users might not drive the numbers we are aiming for in OW3.1. The logged-in UX experience is a real problem now that needs to be addressed if we want to achieve the strategic goals for On Wiki logged-in users. In summary, given the goals of our readers' strategy, we want to change the assumptions we make and make logged-in readership as close to logged-out readership, in terms of performance and infrastructure costs, as possible, thus improving both our product flexibility and the logged-in user experience. This KR will explore how we can improve cache fragility for logged-in users' requests, enhance their UX with performance gains, and mitigate risks associated with content virality that can strain our infrastructure.
      • KR Owner: Mateus Santos
    • Key Result: By end of Q3, all WMF wikis use Parsoid for desktop & mobile readviews and metadata
      • Context: Wikitext processing is one of the core and critical pieces of MediaWiki’s content platform. Since early 2013, MediaWiki has had two wikitext processing engines which model wikitext and process wikitext very differently. This not only adds maintenance burdens and complexity to MediaWiki, but also forces product teams to account for the two engines and potential differences / edge cases. So, in the interest of MediaWiki and platform maintenance and complexity considerations, it is prudent to continue the Parser Unification and take it to completion to fully deprecate the usage of the legacy parser for the content pipeline. Given the ongoing work in FY 25/26, we should strategically build on the momentum and do this work now rather than postpone it for later. In terms of specifics, by the end of FY25/26, Parsoid will likely be used to render ~60% of WMF production wikis. The remaining 350+ wikis are on several projects (wikiversity, wikibooks, wikiquote, wikinews, commons, wikidata, metawiki, mediawiki, wikispecies, WM chapter wikis and any other undeployed wikis on wikisource, wiktionary, and wikipedia projects). Hypotheses will be proposed as part of this KR to convert all these remaining wikis to use Parsoid. In addition, the metadata pipeline for all wikis is currently fed exclusively from the legacy parser. We expect to convert all wikis to use Parsoid for this pipeline.
      • KR Owner: C. Scott Ananian

Developer Productivity

• Objective: Wikimedia developers quickly and confidently get their products out to end users. Discuss
  • Context: Meeting the moment means WMF development teams and volunteer contributors will need to take bigger bets and iterate on new ideas faster than ever before. This is a shift to being able to learn in a matter of days and weeks, rather than in months and years. Crucially though, this cannot come at the cost of degraded quality (of both content and software) or loss of trust in the Wikipedia brand. Moving with this increased sense of urgency therefore requires the capability to ship features quicker and more frequently alongside the tooling to confidently test, monitor, and fix issues as they arise. Moving faster is also achieved through greater focus. This will be delivered by giving developers time back through increased automation and standardization of manual processes, and decreased fragmentation of tools.
  • Objective Owner: Chris Ciufo
    • Key Result: By the end of Q4, MediaWiki developers can get their code to all users within 1 day of it being merged.
      • Context: We want MediaWiki developers to get feedback about their code faster. Tools like SpiderPig have made MediaWiki deployment more accessible, with more individual deployers and more total changes self-deployed in 2025 (up 58% YoY) than ever before. At the same time, feedback from the developer satisfaction surveys indicates that aspects of the deployment train like backport windows remain a point of friction—especially for volunteers—with WMF staff required to consistently be available during specific hours throughout the week. New code can also take upwards of a week to reach end users, and teams rely on deploying configuration changes to control the launch of new product features. Meanwhile, the number of train-blocking issues discovered after rolling out to major wikis decreased 14.5% YoY in 2025, giving confidence that deploying more hasn’t resulted in more bugs reaching our largest audiences. Efforts this year to improve the performance and reliability of automated browser tests is expected to further increase confidence in issues being caught earlier in CI. These insights indicate demand for increased frequency and autonomy of deployment among staff and volunteers. With work already underway to automatically deploy to testwiki daily, there’s an opportunity to explore how we could reduce the need for backport windows and other manual deployment workflows entirely through frequent automatic deployment of MediaWiki releases.
      • KR Owner: Tyler Turley Cipriani
    • Key Result: By the end of Q2, 80% of pilot user group members will choose to use the unified deployment experience for all of their Kubernetes service deployments over a period of 2 months.
      • Context: The deployment experience for production services running on Kubernetes at WMF is heavily manual, and while the underlying tooling is common across services, details of the workflows themselves vary widely (e.g., environment update order and speed, supervision procedure). Building on the success of SpiderPig in reducing friction of MediaWiki deployments, we will extend the same deployment experience to production services on Kubernetes. This will save developers time by automating otherwise-manual deployment workflows in a predictable, consistent way across services, while providing safe defaults for update sequencing and clear integration points for automated validation / monitoring (e.g., passive error rate monitoring, smoke tests) that will increase deployer confidence. Reducing the cost, complexity, and cognitive burden of service deployment is critical to encouraging faster iteration through more frequent deployments, narrowing the scope of change and reducing risk. An Early Adopter Program engaged with a cohort of “frequent deployer” teams will be used to evaluate and refine the new deployment experience, before expanding availability to the wider production-service ecosystem.
      • KR Owner: Scott French
    • Key Result: By the end of Q2, 80% of active tool maintainers have taken action on at least one Toolforge health status automated alert.
      • Context: The growth and health of Wikimedia projects depend on volunteers who build tools and bots that augment editing and support moderator workflows on the wikis: 30% of edits come from tools hosted in Wikimedia Cloud Services, primarily on the Toolforge platform. In a world where a decreasing number of volunteers need to scale to do increasingly more work on the wikis, it’s even more critical that key tools that communities depend on and the developers who create them are well supported. Tool developers and users frequently express the need for simpler development and deployment workflows and want better visibility into the health and status of the tools they care about. Creating a web interface for Toolforge will make it easier to configure, build, deploy, and monitor tools. Strengthening and reducing the operational complexity of the underlying infrastructure powering Toolforge will help make it more resilient to failure and provide visibility across the platform.
      • KR Owner: Arthur Puthin

Product & Engineering Support

• Objective: WMF Product and Engineering teams are more effective due to improved processes, fostering a positive shift in our culture. Discuss
  • Context: Product and Engineering Support is about making the Product and Tech organization more efficient and effective. This new fiscal year we are centering our work around the Product Audience Funnel. We will have one KR only (for now) that keeps our focus narrow and specific: to deliver consistent, reliable weekly reporting on these funnel metrics. With trust and consistent visibility into these metrics, we can track progress in weekly timeframes, identify trends early, and make sharper decisions more quickly.
  • Objective Owner: Marzanne Collins
    • Key Result: By the end of Q2, we have published weekly Audience Funnel Metrics that leaders engage with on a weekly basis.
      • Context: Every week, we want to publish the top X metrics important for P&T to see. The goal is to consistently show metrics every week (to create awareness of what's important), and to reliabilly show these metrics week on week.) We'll know we're successful if we have good engagement and satisfaction with this report - as measured by feedback received.
      • KR Owner: TBD

---