Perambu Genap Taun Yayasan Wikimedia/2025-2026/Produk & Teknologi OKR

This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 5% complete.

The Year Ahead

Even as the world changes, the Wikimedia Foundation remains certain that we want our mission – to make and keep useful information from Wikimedia projects available on the internet free of charge – to be a multi-generational endeavor: we want free knowledge to continue to be available to many generations to come.

The internet is changing quickly. New generations are getting information through social video and AI experiences, and, compared to older generations, fewer of them are aware of Wikipedia. We are seeing related declines in the number of people coming to our sites and the number of people editing. Meanwhile, platforms across the internet are depending on Wikimedia content to underpin their AI and search offerings. These dynamics are major challenges, but they make it clear why the reliable free knowledge that we create together is so important. The world needs a source of trustworthy, human-reviewed knowledge more than ever before, and Wikimedia projects are continuing to show that they can provide it.

To rise to these challenges in the coming year, we will build pathways for drawing upon Wikimedia content sustainably, and we’ll bring Wikimedia content to online social spaces where newer generations are spending their time. We’ll improve our own sites so that readers want to come back, engage deeply, and contribute in ways that are meaningful to them. And we’ll invest in our ability to experiment quickly with new technology, so that our pace of development can match the pace at which the world changes.

The infrastructure goal is how the platform and user experience will support addressing these challenges and reaching the majority of the participants in the movement. It is not a list of projects, but instead, a set of directions to fuel volunteer growth, enable volunteers to build trustworthy encyclopedic content, fund our mission, and evolve our offering to shape the changing internet. You can read more about those four strategic pillars.

Fuel volunteer growth

The community of volunteers is the unique engine behind the success of the Wikimedia projects, and we need it to be healthy and growing. But in this past year, we’ve seen continued declines in the number of new and returning editors to the projects. To better understand and more effectively respond to the needs of our current volunteers, the Foundation revamped the Community Wishlist from a once-a-year survey into an always-open intake process where user needs and project ideas can feed into the work of multiple teams at the Foundation. We grouped wishes into "Focus Areas" and have integrated three of those Focus Areas under key results in the annual plan. We also started a pilot Product and Technology Advisory Council to supplement the numerous conversations Foundation teams have with community members on- and off-wiki throughout the year. In addition, we have identified opportunities to bring new generations into our projects, such as the fact that younger people are eagerly participating in other online social spaces where they have easy, mobile-friendly ways to connect over shared topics of interest.

In the coming year, we will fuel volunteer growth by making contribution easier and more appealing to new generations through expanding mobile-first, new ways to edit (“structured tasks”), and adding intelligent workflows that make constructive mobile editing easy for newer contributors (“edit checks”). To more deeply engage and retain existing volunteers, we will offer recommended actions and tasks and surface them in a central hub that makes it easy to organize on-wiki activity. We will thoughtfully use AI to strengthen volunteers in their work, always keeping humans in the loop and prioritizing transparency. For both new and experienced volunteers, we will build avenues to connect and work together on our sites – inspired by successful campaigns and WikiProjects – allowing them to find liked-minded editors and improve content related to their interests (aligned with this Wishlist focus area).

Deliver trustworthy encyclopedic content

As AI-generated material multiplies on the internet, the world needs trustworthy encyclopedic content more than ever. We want to increase the abilities of volunteers to both create new content, ensure that existing content stays trustworthy, and deliver trustworthy content to a new generation of readers with new needs and preferences.

To help volunteers create new content, we'll build on existing guided tools and workflows (such as the Content Translation Tool), so that large and smaller communities alike can cover vital content. To ensure that existing content stays trustworthy, we will help experienced volunteers better manage their growing workloads by extending the tools they use to find tasks that need their attention – making it easier for them to update articles and revert unhelpful edits (aligned with this Wishlist focus area).

We'll also help functionaries defend our content by surfacing new signals (beyond IP addresses) that identify bad actors, allowing users to be blocked in ways that minimize erroneous blocking of good-faith editors.

To deliver encyclopedic content to a new generation, we will build features that help new kinds of readers understand articles easily, help them find information they're interested in, and allow them to participate actively as they read. These changes are meant to encourage new Wikipedia readers to become dedicated Wikipedia readers, and some of them to become donors (aligned with this Wishlist focus area).

Delivering trustworthy content also means supporting a “knowledge as a service” model, where the whole internet draws on Wikimedia content. In this model, our infrastructure is not just a valuable resource for humans coming to our website, but also for search and AI companies, which access our content automatically as a foundational input to and output from their products. These kinds of companies represent just one of many uses that increasingly place an unsustainable load on our infrastructure. In the last year, a significant increase in request volume coming from scraper tools and bots has made it more urgent for us to course-correct this trend. We need to establish sustainable pathways for developers and reusers to access knowledge content so that humans are prioritized over bots.

Fund the future of 'free'

The Product & Technology department plays an important role in ensuring that our movement is sustainable. In the coming year, we will partner closely with the Fundraising team so that our donors have an increasingly clear and rewarding experience. On our sites and mobile apps, we will build opportunities for readers to express their appreciation for Wikipedia through donating, and we will build new ways for donors to feel recognized so that they continue their donations year after year.

Shape a changing internet

In order to bring free knowledge to everyone in the world, we need to meet them where they are, with the experiences that help them learn. People aged 18-24 have lower awareness and usage of Wikipedia than the generations that came before them. They largely learn from and interact with shortform video platforms, trusted online personalities, social gaming experiences, and, increasingly, AI applications. This year, we will be making Wikipedia available for those audiences in the places they spend time online, so that they know Wikipedia as a source of trustworthy and human-created knowledge. We will grow our presence in popular video platforms, spreading Wikipedia content and generating community in those spaces. And we'll explore ideas for bringing Wikipedia knowledge to gaming and social platforms.

Within Infrastructure, this is divided into three work portfolios (called "buckets"): Wiki Experiences, Signals and Data Services, and Future Audiences. These buckets are the same as last year and the year before.

Taken together, we believe that this plan meets a crucial moment in the history of the internet, setting us up to ensure that free knowledge content continues to be accessible to and shaped by all generations. Our objectives and key results show the structure and contents of this plan in more detail, and we look forward to hearing questions and ideas from the broader community.

Building, improving and sustaining the infrastructure for Wikimedia projects and volunteers, rooted in our values

"The Foundation will make and keep useful information from its projects available on the internet free of charge, in perpetuity."

The Product and Technology teams dedicate a permanent, year-round priority to build, improve and maintain the infrastructure that serves the Wikimedia projects. We invest in hosting the Wikimedia projects, developing open-source software and design systems, and maintaining and improving the infrastructure for data products and AI models.

Part of our essential work is focused on the fundamentals of developing and hosting a large popular website. We host our Wikimedia projects in data centers, on servers and hardware we purchase, install and maintain, connected to each other and the rest of the Internet over a high speed network. We monitor and add capacity where needed, and refresh equipment when it gets too old. For example, this year, we anticipate expanding our capacity and refreshing our hardware in our datacenters in Ashburn, Virginia and Carrollton, Texas.

We design and develop open-source software (most notably MediaWiki). We also use and deploy many existing third-party open-source applications, libraries and frameworks. Important bugs in our software get prioritized and fixed. Maintaining open source software requires highly skilled work from people with special expertise in open source software development, site reliability engineering (SRE), product management, program management, design, and more. Our staff work to ensure our software and systems are up to date and adapt to an ever-changing environment. This includes modernizing our code to continue to benefit from security fixes and to work well with new third-party software. For example, MediaWiki is written in PHP, and in the past year we migrated from PHP 7.4 to 8.1, which required changes to both the code and the infrastructure where we host our sites and services. This year, we will build on that effort and migrate to 8.3, using lessons learned and tools developed in the 8.1 upgrade. Updating will make our systems faster for readers, easier to use for staff and volunteers, and more secure for everyone. It will also save future development time thanks to security, performance and support improvements that come with language updates.

To ensure our projects and content remain available on the Internet, both today and in perpetuity, our teams dedicate a significant amount of effort to ensuring high availability of our sites and services. One aspect of this work focuses on disaster recovery from catastrophic or malicious events. For example, we ensure we have backups of important data, and are able to recover from them. Similarly, twice a year we test our ability to switch our sites between our data centers in automated fashion, and fix any issues we find. Another aspect of this work focuses on identifying and adapting to evolving trends in the types and volumes of traffic we receive. For example, with unprecedented growth in automated scrapers, we are prioritizing work to ensure that our sites and services remain accessible for human users, taking a systematic approach to establishing norms around responsible use of our infrastructure.

Not all work is planned far in advance. We also respond to unexpected emerging events and incidents, like site outages, security reports or security incidents, or large scale vandalism attacks on our projects. We monitor our performance and barriers to reachability across the globe (including Internet connectivity problems, or censorship blocks), and investigate any anomalies we find. Some of these unexpected events or repeating patterns of problems result in staff prioritizing short-term follow-up projects that aim to mitigate or completely prevent further negative impact. For example, these kinds of efforts were crucial to enabling our Wikimedia projects to withstand global traffic spikes due to major news events (e.g., high-profile celebrity deaths), through a combination of performance optimization, architectural redesign of bottlenecked areas, and capacity increases. Similarly, recent improvements to the usability of our tools and systems for managing the traffic we receive have enabled us to react more quickly and effectively to changing conditions. This kind of adaptive work is integral to our ability to respond to emerging events, often on short time scales, and ensure our projects and content remain available.

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.

Wiki Experiences (WE)

Contributor Experiences (WE1)

Objective: Contributions increase because volunteers are offered compelling opportunities and understand their impact. Discuss
- Context: This objective will be the foundation for delivering on the new contributor strategy with its 3 pillars: 1) offering volunteers a centralized way to organize their on-wiki activity, 2) providing smaller, discrete tasks to create more clarity and help volunteers achieve their potential, and 3) making contribution more meaningful. In FY25/26, we plan to deliver the basic infrastructure to help volunteers organize their on-wiki activity in a centralized way, starting with interventions specifically focused on experienced editors and moderators. In subsequent years we'll add interventions across all contributor roles and include more problem spaces. Additionally, we'll continue to invest in Edit Check and Structured Tasks, building a foundation for how to use AI in a scalable way, both as guidance during the editing process and as a way to point volunteers towards compelling opportunities. And lastly, we will invest in making the impact volunteers have more visible to create a more meaningful experience for them.
  - Key result WE1.1: Increase the rate at which editors with ≤100 cumulative edits publish constructive edits on mobile web [i] by 4% [ii], as measured by controlled experiments (by the end of Q2).
    - i. "Constructive edits" = edits to pages in any Wikipedia main namespace that are not reverted within 48 hours of being published.
    - ii. T389403#10960480
    - New(er) volunteers struggle to start editing successfully. Particularly, people using mobile devices where screen space is limited and attention is often fragmented.
    - Some grow tired of the context, patience, and trial and error required to contribute constructively. Others have yet to encounter a compelling opportunity to try.
    - WE 1.1 will address these issues by:
      - Surfacing edit suggestions
      - Offering actionable in-edit guidance
      - Building more task-specific editing workflows
    - At the core of these efforts is the need for scalable ways to detect how in-progress edits and existing content could be improved. To grow this capacity, we will continue to experiment with machine learning to learn how it can best serve editors, across roles and experience levels.
    - Proposed KR scoring methodology: On a per platform basis, we will calculate the proportion of interventions we deployed and evaluated through controlled experiments that met and/or exceeded the constructive edit target we set at the outset of this year. See phab:T379285#10782051 for thinking.
      - Note: as June 30, 2025, WE 1.1 has two controlled experiments planned.

Key result WE1.2: Increase in the number of collaborations on the wikis by 55% YoY by the end of Q4.
- Contributors often struggle to find opportunities to collaborate with one another, especially around the topics and tasks that they care about. This can lead to a feeling of being alone on the wikis for newcomers, and it can lead to burnout for experienced editors. Additionally, the impact of collaborative activities is often unclear, which can lead to less people wanting to join, organize, or support collaboration on the wikis.
- We want to make the value of collaboration more clear by doing the following:
  1. Create new ways to share the impact of collaborative activities on the wikis
  2. Begin collecting movement-wide data on the impact of collaborative activities
  3. Set up the basic infrastructure to track collaborative contributions, so we can provide innovative new ways to recognize and reward contributions in the future
- Collaborations will be measured by new activities created via Event Registration in the CampaignEvents extension. The goal is that, by the end of this KR, we will have more users of the extension tools and new ways of surfacing collaboration impact. This will put us in a good place to connect our existing infrastructure to other ways of recognizing and rewarding work on the wikis (such as the impact module, thanks, etc).
- Wishlist focus area: Community Wishlist/Focus areas/Connecting Contributors
Key result WE1.3: By the end of Q3, 10% of contributors who were presented with a homepage aimed towards new moderators visited it two weeks in a row.
- We believe that we can do a better job of surfacing contribution opportunities to volunteers. Long-term we believe a homepage can be helpful for any editor to organize their work, find new opportunities, and understand their impact. Our goal in FY25/26 is to surface new opportunities to experienced editors to take on moderation tasks they otherwise wouldn't necessarily have been exposed to.
  - We will test this theory first by understanding how much experienced editors would engage with a homepage, similar to what newcomers have access to.
  - We will then surface specific moderation activities (details to be determined) to contributors who are new to that type of moderation action, with the goal to help reduce the burden on experienced editors through reduced backlogs (under a new KR).
  - If successful with the homepage concept, we plan to make this page modular to cater to the needs of communities. These modules could include things such as making it easier for editors to understand their impact.
- Notes about the methodology:
  - We will have a hypothesis to define our audience, which will be part of WE1.3.1.
  - "Moderators" will follow the definition started in Research:Develop a working definition for moderation activity and moderators, though followup work would be needed to narrow down the quantitative definition.
  - Second week will be defined relative to the timing of each user's first visit. In this case, we'd review all new moderators who visited the homepage during a specified timeframe and then made at least one more repeat visit (7 to 14 days) later.
- Wishlist focus area: Community Wishlist/Focus areas/Task prioritization
Key result WE1.4: Improve the % of unique visitors to watchlist and/or recent changes that click to view an edit.
- Our goal is to help editors with 100+ edits to more efficiently find and open edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces. We can measure success by improving the efficacy of each page at "finding work", defined by the indicator metric of click-though rates.
Key result WE1.5: Define and operationalize seven high priority metrics [1] needed for tracking progress towards achieving the goals outlined in the contributor strategy by the end of Q4, by creating a dashboard and operationalizing Monthly Active Moderator metrics.
[1] Retained editors, constructive activation, constructive edits, account registrations retained newcomers, active editors by tenure, active editors by experience level.
- The contributor experience strategy envisions a 3-5 year effort to “fuel volunteer growth” and “increase retention and activation” of both new and existing contributors through three main areas of activities:
1. Streamlining how volunteers can receive recommendations, manage their tasks and interests, see what’s happening on the wikis, and understand their impact
2. Offering appropriately structured tasks to create more clarity and help volunteers achieve their potential by optimizing the workflows we send them to, including a continued investment in providing structured guidance and automating repetitive tasks, with a special focus on the mobile web experience
3. Making contribution meaningful by showing volunteers their impact and by investing in avenues for human connection and an environment based on positive feedback
- A measurement strategy project then sketched out an extensive network of metrics for tracking this theory of change. It concluded that the primary measure of success (“core metric”) should be a count of retained editors, complemented by narrower indicator metrics like the constructive activation and contributors’ intention to return and broader “downstream” metrics like active editors and quality content. We need to ensure that we have these metrics operationalized and visible in a dashboard, so that we can track our progress towards delivering on the strategy.

Vital Knowledge (WE2)

Objective: Make more vital knowledge available and well illustrated across languages and topics. Discuss
- Objective context: This objective will drive content growth that is responsive to both contributors’ interests in particular topics and languages, and reader demand for vital knowledge that is well illustrated. Vital knowledge is a set of articles that delivers the breadth and depth of topics needed for a usable Wikipedia language project. It is defined by communities with reference to notability, relevance, predicted readership, and connections between articles.
- We will take a socio-technical approach, improving the effectiveness of features, tools, and social processes. We will build on high-impact product features like suggested tasks, media search, and content translation but also facilitate the onboarding and development of smaller language Wikipedias. We will support the Wikimedia organizers who recruit, train, and support contributors to work on shared content goals through collaborative setups like WikiProjects and campaigns. (We estimate that at least 300 organizers are active each quarter.) We will also develop relationships with the most relevant publishers to remove barriers to source materials. (We currently have partnerships with more than 100 of the world’s top subscription-only databases.)
- To ensure our interventions have a positive impact on vital knowledge, we will measure both the increase of community-prioritized content and the quality of that content, looking at factors like reversion rates and the number of citations and images.
  - Key result WE2.1: By the end of Q2, experiment and evaluate 3 interventions that help contributors improve the state of vital content on their Wikipedias.
    - This KR will highlight content gaps within editing mechanisms, such as the discovery of images on Wikipedia, content translation, and guided creation of new articles. We will also implement and test a socio-technical intervention to support content creation activity for small language communities. Success will be measured within each hypothesis.
  - Key result WE2.2: By end of Q4, build the platform capabilities needed to validate that we can support the Abstract Wikipedia vision at scale. We’ll know we’re successful if we show the system outputs rich, multi-lingual encyclopedic content using Wikidata and natural language generation, is controlled by the Wikimedia community, and remains performant in broad rollouts.
    - Now that we can use Wikidata to output basic, plain text content on Wikipedias, the next step is to continue building platform capabilities that can support Abstract Wikipedia at scale. The platform will need to support rich, multilingual content that can be controlled by the community and stay performant at scale. This is a milestone KR as we are going from 0-1.
  - Key result WE2.3: By the end of Q4, deploy an initial form of the new wiki for early community creation of Abstract articles.
    - This KR sets us up to test the platform capabilities of an Abstract wiki next year. The new, standalone wiki will host the library of abstract articles built on Wikifunctions, and provide the platform capabilities necessary to later integrate abstract articles into Wikipedia in the future.
  - Key result WE2.4: Align WMF and WMDE on the definition of success for the improvements to the technical infrastructure supporting a Wikidata critical use case by the end of Q2, including metrics and goals through 25-26 FY.
    - The WMF Wikidata Platform (WDP) team was established and staffed - one Product Lead and one Tech Lead - in August 2025. As a new addition to a program with years of development by technical and product owners in WMF and WMDE, respectively, this goal reflects our intention of transitioning ownership through alignment on use cases, dependencies, and key success criteria. This KR will build the foundation of mutual understanding of the problem space, which we will build off of through the rest of the fiscal year (May 2026).

Consumer Experiences (WE3)

Objective: Readers from multiple generations engage, and stay engaged, with Wikipedia, leading to measurable increases in retention and donation activity. Discuss
- Objective context: This objective will focus on retaining new readers through innovative content formats, core audiences through strengthening familiar reading experiences, and ensuring long-term sustainability by deepening reader connections and diversifying donations. It will include a continuation of our work into making content easier to discover through new and more experimental features such as AI summaries or personalized rabbit holes. It will also include work on retaining and improving the quality of the reading experience deeper in the reading funnel and on exploring reading curation through reading lists and other non-editing participation. For donors, this work will continue focusing on diversifying revenue sources from within the platform.
  - Key result WE3.1: By the end of Q2, demonstrate a practically significant increase in logged-out reader retention, as measured through A/B testing of one feature per platform
    - This KR will focus on continuing to invest in experiences that optimize for new ways of browsing and learning content, often through the use of new technologies and formats - presenting existing content in new and engaging ways. In this FY, we would like to continue experimenting with new features while also focusing on scaling successful experiments across wikis and platforms. The work in the KR will span across the mobile and desktop website, as well as the iOS and Android apps and focus on content discovery (browsing entry points and recommendations) and adaptable learning formats (machine-assisted summaries, content remixing).
    - Wishlist focus area: New consumer experiences
  - Key result WE3.2: Increase number of donations through non-banner or email methods by 5% Year over Year per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q2
    - This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team
  - Key result WE3.3: By the end of Q2, demonstrate a practically significant increase in logged-in reader retention, as measured through A/B testing of one feature per platform
    - This KR will focus on improving the reading and learning experience for existing and experienced readers, with the goal of retaining our current audience and deepening their connection to the site so they can learn more, as well as be ready and open to take paths towards donation and editing. Work here will focus on improving the reading experience on the web and apps (readability improvements, better navigation and discovery), as well as building out and iterating on our curation and personalization offerings (Reading lists, personalized suggestions, user and article history, etc)
  - Key result WE3.4: By the end of Q4, remove all identified blockers for small-scale cache site deployments (PoPs) that meets our current quality of service and security standards as per our current cache site deployments
    - This KR will focus on proving the concept that we can improve website performance and reduce latency for our readers by simplifying our caching infrastructure and improving the processes for a caching site deployment by reducing the baseline deployment time from about one year on average to a quarter at most. The focus here will be to complete the simplification, deploy a PoC, conduct a security review and complete a decision brief on whether to proceed with deploying our edge caches in public clouds. Decreasing latency can lead to a proven increase in pageviews and a more geographically diverse reader base.
  - Key result WE3.5: Improve donor identification —ensuring that all consenting logged-in readers can be identified by donor status for a personalized experience—by the end of Q4.
    - We will implement donor identification strategies to ensure that all consenting logged-in readers can be identified by donor status, enabling a more tailored and engaging experience. Donor identification efforts will be prioritized through Q4 to support more effective personalization and activation initiatives in the future.
  - Key result WE3.6: Finalize, publish, and communicate a strategy for the Wikipedia reader and consumer experience across platforms by end of Q4, with defined goals and baseline metrics, developed in collaboration with stakeholders and the community, to guide our work through 2030.
    - Work on the consumer strategy will continue, with a focus on building and communicating the strategy internally as well as with the community and defining and establishing core metrics for consumers, and their respective baselines.

Safety and Security (WE4)

Objective: Our systems better protect our editors’ accounts and private information by default, while offering more pathways for editors and users with extended rights to prevent and respond to abusive activity. Discuss
Key result WE4.1: Deploy a viable and working incident reporting system across all of our wikis, that is used and accepted by their communities, by the end of Q2.
- Ensuring user safety and well-being is a fundamental responsibility of our platform. Many jurisdictions have regulations that require online platforms like ours to monitor and take action against harassment, cyberbullying and other harmful content on their platform. Failing to address these may expose platforms to legal liability and regulatory sanctions.
- We want to empower our users to be able to report immediate threats of harm through an easily discoverable and intuitive reporting mechanism to ensure we are able to learn about such incidents and take prompt action where necessary. This is a step towards making our users feel safe when contributing to our platform. We are doing this by implementing an Incident Reporting System on our wikis.
Key result WE4.2: Strengthen the precision and efficacy of anti-abuse tooling, by deploying 2 improvements by the end of Q2.
- We and our community need to better detect and prevent inauthentic and malicious activity on the wikis. We will do this by increasing the number and quality of signals that are available to the platform, combining these signals into tools we make available to users with extended rights, and identify where we can safely make automated restrictions on suspicious activity.
- We also see opportunities to improve the accessibility of Wikipedia and our other projects at the same time. For example, one project is to replace the wikis’ very conventional self-managed CAPTCHA, which stops the user from logging in until they solve a puzzle, with a risk scoring service that rarely ever challenges the user. Instead, it would silently tag accounts with a level of suspiciousness that we can use to disable functionality, and make this status visible to highly privileged moderators to assist in their work.
- More generally, Wikimedia projects rely heavily on IP address blocking to mitigate abuse from bad actors. This is increasingly ineffective at stopping abuse and negatively impacts good faith users who are impacted by IP and IP range blocks. In this KR, we aim to improve existing capabilities and deliver new tools that enable more precise and effective blocking of bad actors, and decrease the collateral damage caused by IP and IP range blocks.
- To gauge our effectiveness, we will look at qualitative feedback from volunteers engaged in anti-abuse work, and quantitative indicators like the rate of IP blocks being deployed, the adoption of IP reputation and browser signal based mitigations, the rate of likely-human interactions when a user is blocked, and the adoption of new signals in anti-abuse tooling.
- Work in this KR involves improved sockpuppet and ban evasion detection and mitigation, surfacing information about the potential for collateral damage, strengthening bot detection, surfacing signals to anti-abuse volunteers, improved efficiency in anti-abuse tooling interfaces, improving metrics related to abuse, and providing suspicious account activity suggestions for investigation to CheckUsers.
Key result WE4.3: Reduce the number of large-scale attacks that require SRE human intervention by 50% (compared FY-over-FY), by the end of Q4.
- The evolution of the landscape of the internet, including the rise of large-scale botnets and more frequent attacks have made our traditional methods of limiting large-scale abuse obsolete. Such attacks can make our sites unavailable by flooding our infrastructure with requests, or overwhelm the ability of our community to combat large-scale vandalism. This also puts an unreasonable strain on our high privilege editors and our technical community.
- We urgently need to improve our ability to automatically detect, withstand, and mitigate or stop such attacks.
- This year we will focus mostly on automating detection of IP addresses and networks that regularly engage in attacks against us, and reduce the amount of load those persistently-harmful entities are allowed to place on our systems.
Key result WE4.4: Deploy temporary accounts to 100% of our projects, such that exposure of personally identifiable information of our unregistered editors is available to less than 0.1% of users, by the end of Q2.
- Temporary accounts aim to improve the privacy and thereby, safety of our unregistered editors by shielding their personally identifiable information (IP address) from public view and limiting access to only those who need it for patrolling purposes. Besides being a major improvement to user safety, this project is also important to comply with various regulatory requirements.
Key result WE4.5: Evaluate the impact of generative AI on trust and safety, and determine product interventions to leverage opportunities and prevent threats for Wikimedia projects, by the end of Q3.
- AI usage and in particular generative AI is rapidly increasing across the internet. There are trust and safety opportunities as well as threats that emerge with AI becoming ubiquitous. For example, content is easier and cheaper to generate, but moderation is more strenuous. Similarly, research can be carried out with much less effort but AI hallucinations are harder to identify.
- This project aims to build on the Human Rights Impact Assessment of ML/AI, by assessing AI’s impact on trust and safety aspects of Wikimedia’s ecosystem. This includes:
  - Consulting with users with extended rights.
  - Identifying examples of generative AI assisted abuse and potential mitigations.
  - Identifying ML opportunities to decrease the burden on users with extended rights.
  - Running experiments to understand what we should focus on, in order to make the most impact.
Key result WE4.6: Technically enforce that 100% of privileges that enable users to take security- or privacy-sensitive actions can only be performed by accounts that have enabled two-factor authentication, by the end of Q4.
- We need to strengthen the security of the user accounts on our wikis, particularly for users with sensitive permissions. A key focus is requiring that any sensitive action can only be taken by users who have enabled two-factor authentication (2FA). We will build a more extensible system for privilege enforcement that will bypass the need for audits and manual enforcement of 2FA, and expand which privileges require 2FA to be enabled on the platform.
- As part of this, we will be improving our authentication and recovery systems so that we (WMF) and our users can more easily support a more strict posture toward 2FA. We will be expanding the general availability of two-factor authentication across the platform, so that every user can enable it as desired and to ensure it is enabled before sensitive privileges are granted. We will also focus our attention on reducing the operational load borne by our account recovery and support systems, helping to streamline our reset and recovery processes surrounding account login. We further intend to improve the usability of our 2FA implementation, offering users more options to secure their accounts and avoid accidental lockout.

Responsible Use of Infrastructure (WE5)

Objective: Developers and reusers access knowledge content in curated pathways, ensuring the sustainability of our infrastructure and responsible content reuse. Discuss
- Objective context: This objective will focus on establishing pathways for responsible content reuse.
- Wikimedia hosts the largest collection of human-curated knowledge on the web. This has made our knowledge infrastructure an invaluable destination not just for humans, but also for automatic data consumers. Our content feeds into search engines, social media platforms, ecommerce, and ever since the rise of AI, is used to train large machine learning models. Consumers source data by scraping pages, using the APIs, and downloading content – commonly without attribution. In the world of unauthenticated traffic we can’t reliably differentiate one user from another, which greatly limits our ability to enable and enforce responsible use of our infrastructure: How can we continue to enable our community, while also putting boundaries around automatic content consumption? How might we funnel users into preferred, supported channels? What guidance do we need to incentivise responsible content reuse? How can we drive towards a cohesive developer experience, and build products that meet the needs of volunteer developers, staff and reusers alike? While these questions are not all new, the urgency of addressing these has grown exponentially: Since 2024 we’re observing a dramatic rise in request volume, with most of the increase coming from scraping bots collecting training data for AI-powered workflows and products. The load on our infrastructure is not sustainable and puts human access to knowledge at risk: We need to act now to re-establish a healthy balance, so we can effectively support the Wikimedia projects and enable the sustained success of our mission.
  - Key result WE5.1: By the end of Q4, 50% of requests to programmatic access channels can be attributed to a known developer or application.
    - We currently have limited ways to identify who is responsible for automated traffic and, unlike on-wiki, limited ways to contact users or regulate their access. We have seen a significant increase in the volume of external automated traffic, which is not sustainable for us and puts human access to knowledge at risk. We aim to increase the percentage of automated traffic that is attributed to a known account, by requiring authentication and authorization based on tiered levels of access for high volume scraping and API use. This will help us to identify who is reusing content at scale, enabling us to protect our infrastructure and improve governance around fair use, whilst more effectively meeting their needs. We will also explore how to better support the technical community with a more cohesive developer experience that protects preferential access for community members and enables new functionality for developers.
  - Key result WE5.2: By the end of Q4, 70% of Wikimedia web API endpoints will be supported by common infrastructure.
    - We aim to improve the experience and sustainability of our developer pathways by offering more consistent, stable, and discoverable web APIs for all Wikimedia developers. We will simplify our API offerings by introducing more centralized infrastructure for core API capabilities, allowing us to have consistent pathways and governance for: OpenAPI specs and documentation, developer identification and access controls, API policy enforcement, routing, versioning, and error handling. By streamlining our API offerings, we will make it faster, easier, and more delightful to build tools, bots, research projects, and features that serve the Wikimedia mission. This approach supports the multi-generational future of the mission by reducing API infrastructure maintenance costs, increasing visibility and access control for combating bad actors, and fostering a stronger developer community.
  - Key result WE5.3: By the end of Q4, new attribution framework for web, apps, voice assistants, and LLMs will be published and linked across Wikimedia sites, with two reuse demos deployed that drive measurable engagement, and one external reuse partner adopting best-practice attribution.
    - To increase proper attribution of Wikimedia content, we will provide clear best-practice guidance that promotes responsible reuse. This includes creating attribution framework for key platforms (web, apps, voice, multimedia) and showcasing at least two practical examples highlighting exemplary applications of Wikimedia content. Examples of outputs include encouraging media organisations to credit Wikimedia Commons images, search engines to surface relevant Wikimedia data more effectively, or AI assistants to integrate Wikipedia knowledge in transparent and responsible ways that increases trust in their reliability. Strengthening attribution practices not only increases public awareness and drives engagement back to Wikimedia projects, but also helps establish responsible and novel ways of remixing knowledge, and deterring misuse.
  - Key result WE5.4: Reduce the amount of traffic generated by scrapers by 20% when measured in terms of request rate, and by 30% in terms of bandwidth
    - Scraping has always been here: the search engines have relied on Wikipedia to provide information to their users for decades; however lately there’s another big motivation to scrape our data: it’s the largest curated, multilingual set of knowledge content you can find on the internet and it’s a fundamental tool to train large language models. This is true both for our encyclopedic content and our multimedia repository, Wikimedia Commons, which is invaluable for machine learning models that generate images.
    - As a consequence, over the past year, we saw a significant increase in the amount of scraper traffic, and also of related site-stability incidents: Site Reliability Engineers have had to enforce on a case-by-case basis rate limiting or banning of crawlers repeatedly to protect our infrastructure. Scraping has become so prominent that our outgoing bandwidth has increased by 50% in 2024. What's more, a recent analysis showed that at least 65% of our most expensive requests (the ones that we can’t serve from our caching servers and which are served from the main databases instead) are performed by bots.
    - Our computing resources are extremely limited compared to the amount of traffic we make, so we have to prioritize who we serve with those resources, and we want to favour human consumption, and prioritize supporting the Wikimedia projects and contributors with our scarce resources.

Accelerate Path to Product Outcomes (WE6)

Objective: Wikimedia developers quickly and confidently get their products out to end users. Discuss
- Objective context: To be effective in achieving the 4 strategic pillars, Wikimedia developers need to be spending their time and effort on high-leverage activities that result in delivering quality products as early as possible. Overly complicated workflows, lack of standard tooling, and unsustainable system components get in the way of those outcomes.
- This work builds on the momentum we've picked up the last 2 annual plans evolving MediaWiki as a platform and the software supporting its development and deployment. The work for this year will focus on providing more reliable developer environments, simplifying pre-production workflows, and reducing platform and infrastructure risks.
  - Key result WE6.1: By the end of Q4, the number of train-blocking bugs that make it beyond test wikis is reduced by 10%
    - In 2024, there were 144 times developers had to revisit work because there was an emergency preventing the deployment of MediaWiki. In many of those cases, the bugs were caught after deploying to testwikis, meaning the issue reached a potential audience of billions of users. We can't control the fact that bugs will exist, but catching them earlier would mean less hero work is needed. It would also build up confidence in developers that when something goes to real production, there won't be a fire.
    - We will catch these bugs earlier by providing environments needed by developers to confidently deliver and test their code throughout the development and deployment lifecycle. We also need to ensure that these improvements do not come at the cost of developer velocity.
  - Key result WE6.2: By end of Q4, 4 steps from the production readiness review checklist can be executed without SRE intervention
    - Getting a new service or feature deployed in production currently depends on a list of 24 steps for which each step typically needs support from SREs. We established the SRE ambassador program to intervene earlier in the development cycle and build up capacity within the development teams themselves, but many of the tasks should be entirely self-serviceable. Currently, this amounts to work that is manual, repetitive, automatable, and that scales linearly with the number of development teams. This is not sustainable for the SRE team in the long run.
    - In the past, much of this work was abstracted from development teams by maintaining a set of shared common libraries and best practices to interact with our platform. These were abandoned when we moved to our new Kubernetes infrastructure and do not have a direct replacement. By providing similar libraries, documentation, and training that apply to the way we build and deploy things today, we believe we can reduce the amount of involvement needed from SRE before deploying a new service or feature to production.
  - Key result WE6.3: By end of Q4, 100% of Wikipedia page views are served through Parsoid
    - Parsoid offers enhanced capabilities for wikitext evolution and future-proofing the platform. Maintaining two parsers concurrently is not sustainable in the long term, as it increases technical debt and complexity. Additionally, the success of some new projects like Wikifunctions depends on Parsoid being widely available.
    - We have been scaling up the rollout to smaller projects and this year we will be ready for the Wikipedias. Serving all Wikipedia page view reads through Parsoid is the most important next milestone. In addition to the rollout itself, this work also includes resolving performance issues and communicating effectively about the impact to readers and editors.
  - Key result WE6.4: By end of Q2, at least two identified risks that threaten our ability to continue deploying or scaling the wikis have been mitigated or reduced to an acceptable level
    - Through a few targeted initiatives, we will reduce or mitigate several scalability, reliability, or security risks that we have identified as a likely potential threat to the growth and sustainability of our platform and our public projects.
    - For example, we will be refactoring the structure of the core databases of Commons to ensure its growth will not be limited by the capacity of available server hardware within the next few years. We will also be upgrading PHP, the programming language powering MediaWiki and related services, to a more modern version. Other risks identified will likely require implementing additional security measures to protect and harden of our infrastructure.

Signals and Data Services (SDS)

Metrics (SDS1)

Objective: Decision makers use more trustable and timely metrics to inform product and strategic decisions. Discuss
- Objective context: We use metrics to inform the Foundation’s decisions about where to focus our efforts in order to best serve the Movement. However, some of our data pipelines are prone to break, causing delays in delivery. When data issues emerge, our time-to-identification and resolution are too high. In addition, many of our datasets are not optimized for easy exploration of trends and are missing dimensions that have emerged as being important for interpreting the data. These issues slow down and limit our ability to evaluate metrics.
- In FY25-26, we will focus on specific annual plan use cases for resolving the data quality gaps in our current pipelines, setting up infrastructure and processes for monitoring and resolving data quality issues, and delivering tools that enable decision makers to understand trends.
- One use case is about how we measure human and bot traffic. The rise of automated traffic in the past couple of years has made it harder to understand the extent to which humans are interacting with and contributing to Wikimedia projects. We aim to improve our ability to evaluate human and bot traffic patterns, which are critical inputs for planning and product decisions.
  - Key result SDS1.1: By the end of Q1, analysts who use pageview metrics have access to baseline measures of data quality and measures of the performance of automated traffic detection heuristics.
    - Through the hypotheses explored in this KR, we aim to identify gaps in our current automated traffic detection heuristics and understand where they fail to properly categorize pageview traffic. These insights will inform improvements to the pipelines that generate and classify pageview metrics. Additionally, we will define data quality metrics to monitor and measure improvements in data accuracy.
    - This KR will lay the groundwork for a follow-up KR focused on implementing the necessary pipeline improvements identified here. The data quality metrics established in this phase will serve as benchmarks to assess the effectiveness of those future enhancements.
  - Key result SDS1.2: By the end of Q1, the content of the mediawiki content history data set will be available via a file export with weekly delivery guarantees (SLOs). The exported file data will have parity compared to the legacy XML Dumps 1 export pipeline.
    - The goal of FY24/25 KR 1.4 has been to remove the dependency on the monthly updated mediawiki_wikitext_history and mediawiki_wikitext_history_current data sets for the 3 most relevant downstream pipelines and to provide an alternative data set with guaranteed weekly SLOs.
    - While FY24/25 KR 1.4 helped mitigate the reliability issues for the most relevant dependent pipelines, there are remaining pipelines left with the unreliable legacy input source. These should be migrated too as well as the file based input source to the wikitext history data set itself.
  - Key result SDS1.3: By the end of Q2, bot detection incorporates 1 additional signal and generates automated alerts for anomalies.
    - Across the Foundation, teams are making product and funding decisions based on being able to determine the difference between human readership and automated traffic. The Data Platform is the central repository for bot detection signals and batch analysis. Through the hypotheses we've scoped through Q1/Q2, we plan to begin introducing new bot detection signals to sharpen our analysis of automated traffic, and to begin making the process of introducing new signals both efficient and repeatable.
  - Key result SDS1.4: By the end of Q2, decision makers have a clear understanding of the current state of insights provided by our organizational metrics. We’ll know we’re successful if we provide a board meeting ready presentation deck that situates analysis of our metrics within both the Wikimedia ecosystem, as well as within broader internet trends and challenges in the market.
    - Insights from our organizational metrics are used to make a myriad of decisions across the foundation, including decisions around how we build our product, how we allocate infrastructure resources, and how we fundraise. At the same time, the landscape of the internet is evolving, with automated traffic in particular affecting our metrics. The goal is for Foundation leadership to enter the December board meeting with a clear narrative about threats to, and opportunities within, the Wikimedia ecosystem supported by confident analysis of internal metrics and external trends. We can tell this story by gathering insights, metrics, and data points that tell us with confidence about:
      - Trends in our internal measures of readership (pageviews)
      - Trends in our contributor ecosystem
      - Trends from external data and competitor benchmarks
      - Insights from internal and external studies and trusted research

Experimentation Platform (SDS2)

Objective: Product managers can quickly, easily, and confidently evaluate the impacts of product feature changes in Wikipedia. Discuss
- Objective context: To enable and accelerate data informed decision making about product feature development, product managers need an experimentation platform in which they can define features, select treatment audiences of users, and see measurements of impact. Speeding the time from launch to analysis is critical, as shortening the timeline for learning will accelerate experimentation, and ultimately, innovation. Manual tasks and bespoke approaches to measurement have been identified as barriers to speed. The ideal scenario is that product managers can get from experiment launch to discovery with little or no manual intervention from engineers and analysts.
- We are focused on Wikipedia for the next fiscal year because that is where Core Experiences is interested in experimentation (the organizational strategy has us doubling down on Wikipedia), and because it allows us to focus and signal more clearly which teams and projects we are engaging with. Other teams have used the experiment platform components and may continue to do so, but that use won’t be the focus of this objective.
  - Key result SDS2.1: By the end of Q2, enable the completion of at least 2 full experiment cycles using the experimentation platform.
    - As the organization increasingly emphasizes data-informed product decisions, we must make experimentation accessible to all product teams, not just those with specialized skills. Product Teams need shared standards, tools and infrastructure that enables them to:
      - Quickly test ideas across our global user base
      - Measure impact of product changes with standardized metrics
      - Share results transparently with our Movement stakeholders
    - Why we’re pivoting from focusing on number of “teams enabled” to “experiments completed”:
    1. Strategic alignment: It is the primary success metric of the platform.
    2. Data-informed approach: Our user research (in progress) suggests variable team readiness across the organization, while we know the Web team has confirmed interest in two specific experiments.
    3. Resource optimization: Our MVP platform rollout will require high-touch onboarding, making it more efficient in the near term to focus on experiment opportunities rather than casting a wide net across multiple teams. We plan to advance towards a general release and do not want to reinvest in training teams again, if we can avoid it.
    4. Future focused: Feedback from the complete experiment cycles will inform our platform improvements more effectively than learnings from partial or incomplete adoption. As we advance toward general release, focusing on experiment completion avoids investing in temporary approaches that would need to be redeveloped.
    - We have user research in process to pull the cross team needs and requirements: survey and interviews being scheduled to add clarity to the product team’s needs in the second half of May 2025. Once that research is completed, we will make an experimentation calendar that can be used to set our next KR targets and prioritization.

Future Audiences (FA)

Future Audiences (FA1)

Objective: The Wikimedia Foundation is equipped with recommendations on strategic investments to pursue that help our movement serve new audiences in a changing internet. Discuss
- Objective context: Due to ongoing changes in technology and online user behavior (e.g., increasing preference for getting information via social apps, popularity of short video edu-tainment, the rise of generative AI), the Wikimedia movement faces challenges in attracting and retaining readers and contributors. These changes also bring opportunities to serve new audiences by creating and delivering information in new ways. However, we as a movement do not have a clear data-informed picture of the benefits and tradeoffs of different potential strategies we could pursue to overcome the challenges or seize new opportunities. For example, should we...
  - Invest in large new features like chatbots?
  - Bring Wikimedia's knowledge and pathways to contribution to popular third-party platforms?
  - Something else?
- To ensure that Wikimedia becomes a multi-generational project, we will test hypotheses to better understand and recommend promising strategies – for the Wikimedia Foundation and the Wikimedia movement – to pursue to attract and retain future audiences.
  - Key result FA1.1: As result of Future Audiences experimental insights and recommendations, by the end of Q3 at least one objective or key result owned by a non-Future Audiences team is present in the draft for the following year's annual plan.
    - Since 2020, the Wikimedia Foundation has been tracking external trends that may impact our ability to serve future generations of knowledge-consumers and knowledge-contributors and remain a thriving free knowledge movement for generations to come. Future Audiences, a small R&D team, will:
      - Perform rapid, time-bound experiments (aiming for at least 3 experiments per fiscal year) to explore ways to address these trends
      - Based on insights from experimentation, make recommendations for new non-experimental investments that WMF should pursue – i.e. new products or programs that need to be taken on by a full team or teams – during our regular annual planning period.
    - This key result will be met if at least one objective or key result that is owned by a team outside of Future Audiences and is driven by a Future Audiences recommendation appears in the draft annual plan for the following fiscal year.

Social video (FA2)

Objective: Young (<25-year-old) people love, learn from, engage with, and share Wikipedia content on platforms where they like to spend time online. Discuss
- Objective context: Future Audiences experimentation with short video this fiscal year has shown that we can reach younger audiences at scale on these platforms, but our Brand Health data is showing that our current investment is not enough to counter the decline in awareness and affinity with Wikipedia among Gen-Z-aged audiences.
- In order to ensure that we effectively reach and engage this generation, we believe that we will need to engage in a variety of tactics, and significantly increase our engagement in areas such as paid and influencer marketing, creative campaigns, being responsive to trends and increasing our level of experimentation on these channels.
- We expect that the challenges we are facing will require a more substantial investment to help us overcome them, particularly in Communications and Marketing efforts to create engagement, as well as cross-departmental collaboration on creating new products and experiences geared at increasing the presence of Wikipedia's brand and content on these platforms.
  - Key result FA2.1: Generate 9,500,000 views from short-form video content across all owned channels by the end of H1.
    - This year, we achieved a reach of approximately 1 million views within 3 months of launching short videos on the @Wikipedia channels on TikTok, Instagram, and YouTube. By the start of next fiscal year, we expect more followers on our owned channels and more insights into effective/engaging content that we can put into practice to reach even more viewers.
    - By setting an ambitious goal in the first half of the year, we hope to drive toward more significant impact, allow for the creation of new strategies/processes to facilitate the work, and be able to advocate for additional resources to meet this goal.
  - Key result FA2.2: Grow our off-platform following on TikTok from the Mid tier (100k–250k followers) to the Macro tier (250k–1M followers) by the end of FY25/26 (June 2026).
    - We’re currently in the Mid tier of TikTok following (100k–250k followers), and our goal is to reach the Macro tier (250k–1M followers) by the end of FY25/26 (June 2026). These tiers—Micro, Mid, and Macro—are standard benchmarks in the industry for audience size and reach. To get there, we’ll refine our content strategy to better attract Gen Z followers and increase our overall visibility through community management. H1 performance will inform tactical adjustments in H2 to accelerate growth and hit this milestone.
  - Key result FA2.3: Launch a product off-platform aimed at future audiences' new methods of learning/media consumption and bring it to market through a collaborated product branding and marketing campaign.
    - Future Audiences typically works on small-scale experiments with minimal/organic marketing. This year, we would like to reserve time for a more scaled-up new product + marketing campaign targeting younger audiences off-platform.

Product & Engineering Support (PES)

Product & Engineering Support (PES1)

Objective: WMF Product and Engineering teams are more effective due to improved processes, fostering a positive shift in our culture. Discuss
- Objective context: This objective is about making The Wikimedia Foundation’s ways of work faster, smarter, and better. It’s all about how we work. This means less friction and obstacles (inefficiencies and errors) in processes, and achieving impact quicker. This Objective is also about learning ways of work that can be adopted across the department and organization.
  - Key result PES1.1: By end of Q2, define SLOs for 6 production services based on a prioritization rubric that aims to maximise our learning of how to define and use SLOs to make informed decisions regarding prioritization of reliability related work by stakeholder teams.
    - A Service Level Objective (SLO) is an agreement between stakeholder teams on a target level of service (reliability/performance) that teams collaborate to meet (and not greatly exceed). For example, it helps determine when reliability or performance work should to be prioritized or deprioritized by a development team, or what constitutes a problem. Teams need to care about identifying what is immediate (alerting/incident response/critical bugs) versus what isn’t. The goal is to reduce friction across functions by negotiating targets and informing shared and clear prioritization.
  - Key result PES1.2: By the end of Q2, community signals (including the Wishlist) have influenced WMF to prioritize at least 5 product workstreams for Q3 - Q4.
    - Our goal is to identify and celebrate when teams prioritize work based on evidence-based community requests.
    - Two planned hypotheses are focused on the Wishlist exclusively. They’re designed to improve trust, streamline processes, and increase participation among staff and volunteers. Another hypothesis is an experiment designed to see if there are enough valuable signals from village pump, etc, and if AI can support our signal gathering muscle.
  - Key result PES1.3: Two early-stage cross-departmental experiments, validated by our external consumer, donor, and contributor audiences, are incorporated by the Foundation into the annual plan.
    - This work is about creating experiments and experimentation processes for adoption across our organization.
    - The Foundation strengthens a culture of cross-departmental experimentation by incorporating two validated, early-stage experiments into its annual planning. This initiative fosters collaboration beyond the Product & Technology department feature teams, encouraging more innovation with other departments in the organization (such as Communications and Advancement). By seeding untested newer ideas and streamlining processes for experimentation, teams enhance productivity and scale impact. Success is measured by completing two cross-departmental experiments per year, integrating them into future OKR work, and increasing adoption of experimentation practices. Examples of outputs are new prototypes to increase new editors’ growth and productivity, to experimental features that deepen reader and donor connection to Wikipedia. One specific opportunity identified is connecting small feature explorations to celebrate Wikipedia’s 25th birthday.

Hypotheses

Q1

The first quarter (Q1) of the WMF annual plan covers July-September.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Randau
Hypothesis shortname	Q1 text	Details & Discussion
WE1.1.1	If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥10% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.1.2	If we deliver an initial beta version of the “Improve Tone” Suggested Edit then we can learn whether this new format of Suggested Edits is a meaningful way to increase constructive edits for new contributors without increasing the moderation burden for patrollers/reviewers.
WE1.1.3	If we deploy a new Suggestion Mode targeted to Senior Contributors within the visual editor (mobile + desktop) as a Beta Feature with ≥ 3 new edit suggestions within it, we will discover what – if any – adjustments need be made before evaluating the experience with new(er) volunteers through a controlled experiment.
WE1.1.4	If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥10% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.5	If we test a progression system via design prototypes with newcomers, then we can identify which types of milestones, guidance, and recognition are perceived as most motivating, and use these insights to finalize a design for future pilot wiki experimentation.
WE1.1.6	If we investigate the top technical, social, and behavioral barriers and enablers to mobile web editing through user research and data analysis, we will generate at least 3 actionable insights that close key knowledge gaps and strengthen our ability to confidently prioritize product investments for the second half of FY25/26 and beyond.
WE1.2.1	If we create a proof of concept for displaying collaborative contribution data on the wikis, we can gather feedback from at least 30 contributors with 70% of respondents sharing that the feature is useful and could help drive collaborative growth.
WE1.3.1	If we utilize the needs identified from previous research and design and share early mockups of the top X most impactful moderator modules, we can modify the homepage for moderation actions with them.
WE1.3.2	If we modify the newcomer homepage to conditionally render moderator modules, then we can prove the feasibility of using the homepage for moderators.
WE1.4.1	If we make a number of improvements called out in T396489, we will reduce the slow recentchanges queries by X percent on large wikis. Then moderator tools will be able to deploy homepage modules on those wikis without special db performance concern.	T400696
WE2.1.1	If we invite native speakers of small wikis through a CentralNotice banner on a high-traffic Wikipedia in their region to contribute to SuggestedEdits and other Growth features, we can assess whether this approach attracts new native speakers and if they use these editing tools to improve vital content.
WE2.1.2	If we developed and released translation suggestions tailored for new editors, we would then be able to test whether this approach produces better translation outcomes compared to our current approach. This addresses the known challenges faced by new editors, who have a higher probability of article deletion. By pointing them towards translating more manageable content, the goal is to provide a less overwhelming and more accessible introduction to the translation process. Good article and section candidates could look like limited complexity in terms of formatting and overall length.
WE2.1.3	If we learn about the editor experience when creating new articles and sections (including motivations, pain-points and their reaction to new ideas on how to better support them),then we will uncover user needs and behaviors that provide actionable insights and strategies to inform product, design, and engineering on improving the article creation experience.
WE2.1.4	If we explore, through participatory workshops or interviews, how three medium-sized Wikipedias approach knowledge gaps and importance, we will uncover working definitions or framing concepts for “vital knowledge” that are relevant for each community.
WE2.2.1	If we follow Parsoid’s rollout and integrate Wikifunctions on most Wiktionaries and some low-traffic Wikipedias, we will get the testing we need to confidently roll out to larger wikis.
WE2.2.2	If we enable Wikifunctions to output HTML tables, styling, and links, we will demonstrate through a Function that displays a conjugation table its capability for generating net new knowledge on Wiktionaries beyond simple conversions.
WE2.2.3	If we add support for Wikidata entities in embedded function calls, we will enable over 200 new functions that can generate comprehensive sentences using Wikidata entities, making functions more easily used on Wikimedia projects.
WE2.2.4	If we build out an architecture plan for where Abstract Content will reside and how it will interact with Wikipedia, we will be more ready to implement the Abstract Wikipedia platform to increase provision of high-quality encyclopedic content.
WE2.2.5	If we define and socialize across Product & Technology teams on the product needs for citations that are required for Abstract Content, we will be able to drive cross-Wikimedia work to deliver provenance information attached to Abstract Content, which is crucial for successful take-up across wikis.
WE2.2.6	If we make our backend-internal request format more expressive and concise, we can increase the system's stability, thereby supporting a broader rollout.
WE2.2.7	If we provide prototype fragments using Wikidata and Wikifunctions calls to generate natural language snippets, we will show readiness for the project, and will be ready for it to be used to train AI so humans don't have to think too much about functions.
WE2.2.8	If we provide import of Wikidata statements with qualifiers, it will be possible to generate multifaceted facts (facts requiring more than just subject/predicate/value to express), which includes an estimated 50% of encyclopedic content in Wikidata.
WE2.2.9	If we provide caching of retrieved Wikidata entities, we will reduce by at least 50% the average runtime of Wikidata content-based functions, reducing timeouts and user frustration.
WE2.2.10	If we provide a Wikidata lexeme sense component into the Wikifunctions UI, then contributors will be able to identify and select relevant lexemes without leaving the platform/Wikifunctions—reducing context switching and enabling faster and more successful creation of language-related functions.
WE2.2.11	If we address usability findings from the Dagbani community on Wikifunctions integration on Wikipedia, we will observe that editors encounter fewer or zero critical usability issues when inserting a function into an article during testing.
WE3.1.1	If we A/B test an improved version of the Tabbed browsing feature, on the IOS App, we’ll see a 5% increase in multi-day usage among Tabs users.
WE3.1.3	If we provide a new way for users to browse through relevant image or video content within article pages, we will see at least an 3% click-through rate among users who are presented with this feature.
WE3.1.4	If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.
WE3.1.5	If we provide web readers the option to view a machine translated version of Wikipedia content unavailable in their language, we'll learn if reading activity is increased, measured as a 3% increase in page interactions, drawing readers to the local language wiki with a potential increase in local editing activity. This will be provided as a controlled A/B testing setting for no longer than 6 months, and in 13 Wikipedias with prior consent, using open machine translation services already available to Wikipedia editors.
WE3.2.1	If we collaborate with fundraising we will develop more engaging, integrated, and personalized donor slides in the iOS Year in Review as measured through user testing. This will be followed up with a hypothesis in Q2 to assess if the improved Year-in-Review saw 5% more donations than 2024’s Year in Review.
WE3.2.2	If we prompt Android App readers in non-campaign markets to set up an optional, customizable (amount and frequency) reminder for donations based on their usage of Wikipedia, we’ll see a 5% increase in app menu donations in those markets.
WE3.2.3	If we run an A/B test experiment on logged out users to display subtle variants of the donation entry point for both mobile and desktop, we will observe a 2% higher number of donations via the treatment paths, as compared to control.
WE3.3.1	If we add low to medium effort personalized elements requested by iOS users in 2024 to 2025’s Year-in-Review, we will see a 3% increase in satisfaction compared to last year, as measured through usability testing or beta testing.
WE3.3.2	If we expand the existing Edit tab on Android into a personalized activity hub that includes insights into reading and non-editing participation, we’ll see a 5% increase in multi-day engagement with the tab compared to the original version.
WE3.3.3	If we introduce at least one unlockable avatar in the Android app for account holders—earned through meaningful reader actions like saving a certain number of articles — we’ll increase repeated engagement with associated action by logged-in users by 10% over multiple days.
WE3.3.4	If we give logged-in readers the ability to save articles to a private reading list, we expect engagement on the site to increase, as measured by a 5% increase in internal referral traffic for readers who use the feature, and a statistically significant increase for all users.
WE3.3.5	If we conduct a user study that allows web readers to collect/curate content from Wikipedia, then at least 10% of participants will save two or more distinct types of content (e.g. articles, excerpts, media) to a collection.
WE3.4.1	If we work towards a hybrid PoP/CDN deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.6.1	If we run an A/A test on retention rate for logged-out users, we will establish a baseline for retention rate we can use for future quarters.
WE3.6.2	If we create and publish a definition of logged-in reader, we will be able to use this definition across all teams and hypotheses related to the WE 3.3 KR.
WE3.6.3	If we engage communities in conversations about the evolving needs of readers, and about the changing nature of knowledge on the internet, we can build a shared focus on how to serve readers and work together on whether and how to test our various ideas (including those around multimedia, search and discovery, and machine learning).
WE3.6.4	If we research the distinct motivations, behaviors, and needs behind when, why and how readers use Wikipedia and other knowledge platforms, we will have findings we can use to inform and evolve our consumer strategy.
WE4.1.1	If we prototype a minimally viable non-emergency flow, and keep open an iterative feedback loop as we develop it with users with extended rights, then these groups will support expanded deployment of this flow.	Project page
WE4.2.1	If we surface the hCaptcha risk level associated with account creation to trusted functionaries, we will decrease the time needed to identify bad actors, and increase the number of detections of bad actor accounts created on the platform. We can measure the success of the hypothesis by looking at the rate of blocks applied to accounts, the alignment of hCaptcha risk levels and blocks of accounts generally, and qualitative feedback from functionaries.
WE4.2.2	If we generate suggested investigations for CheckUsers to follow up on, we will see a decrease in the time needed to identify bad actor accounts and an increase in the number of bad actor accounts identified. We will know we’re successful when we see regular usages of the “Suggested investigations” feature, an increase in mitigations applied to accounts identified via suggested investigations, and via qualitative survey feedback.
WE4.2.3	If we analyze data from the hCaptcha account creation trial, we will understand the account creation funnel, the effectiveness of hCaptcha’s puzzle and scores, and have the data necessary to inform further rollout of hCaptcha on account creations.
WE4.2.4	If we deploy the UserInfoCard across all wikis, we will empower functionaries and moderators to more efficiently identify and mitigate bad actor accounts.	Project page
WE4.2.5	If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.2.6	If we develop the capability for deploying OpenSearch based clusters on the Data Platform, then product feature engineering teams will be empowered to develop systems that integrate this capability, with a great deal of autonomy, resilience, and isolation from other search-based systems. The first and principal tenant for this system will be the IPoid service.
WE4.2.7	If we deploy hCaptcha Enterprise integration on several production Wikipedias as a pilot trial, we will be able to collect data on the efficacy and value of hCaptcha Enterprise on anti-abuse, bot detection, usability and accessibility.
WE4.3.1	If we integrate support for the new Edge Uniques cookie into requestctl, our edge rules engine for SREs fighting abuse, we will better be able to defend from DDoS and content reuse.
WE4.4.1	If we can make improvements based on pilots feedback and deploy Temporary Accounts to all projects we will be able to protect the exposure of personally identifiable information (IP addresses) of unregistered users on all our projects to be available to less than 0.1% of all (registered) users.	Project page
WE4.4.2	If we communicate with the relevant movement stakeholders (incl. wiki communities and global functionaries) clearly and on time, we will be able to deploy on all remaining wikis, reduce workload discovered last-minute, and avoid rolling back deployment.
WE4.4.3	If we make it easier for patrollers to filter actions by and view the activity of temporary accounts, based on their IP addresses, then we will enable temporary accounts to be successfully rolled out to all wikis.
WE4.4.4	If we allow temporary account IP reveal access to be revoked in line with the IP reveal access policy, and surface the feature in more places, then we will enable temporary accounts to be successfully rolled out to all wikis.
WE4.5.1	If we run qualitative research to identify examples of abuse from bad actors assisted by generative AI (such as spam, harassment, long term abusers, undisclosed paid editing, or disinformation campaigns), we will be able to assess the risk to our community models and generate ideas to mitigate different types of generative AI assisted abuse.
WE4.6.1	If we automate the sync account process within Zendesk for password resets, this will alleviate the burden on T&S and allow them to handle more incoming 2FA reset requests.
WE4.6.2	If we support and encourage users to register multiple authentication factors, users with 2FA enabled will be less likely to lock themselves out of their account.
WE4.6.3	If we allow all users with a confirmed email address to be able to turn on 2FA for their accounts, but do not proactively advertise this change to users, our recovery support desk load will remain at a sustainable level.
WE5.1.1	If we use different storage backends for authenticated and anonymous sessions, we will be able to protect Sessionstore from DDoS attacks and high-volume scrapers, by not overloading it with the anonymous sessions that are created to provide CSRF prevention on authentication pages.	T398814
WE5.1.2	If we change MediaWiki session cookies to a structured format with a cryptographic signature, we will be able to use the presence of a session as a factor in protection against scrapers, by enabling trusted verification of sessions at the edge in a performant and highly scalable manner.	T398815
WE5.1.3	If we create a rate limiting solution for the API gateway using a local development environment based on Kubernetes, we will be able to determine the best option to test with production traffic, by comparing the performance and functionality of at least three different rate limiting services.	T398913
WE5.2.1	If we redesign the REST API Sandbox UI to better meet developers’ informational needs, we will improve documentation clarity, as validated through usability testing.
WE5.2.2	If we route all APIs under rest.php through a central gateway, we will unlock the means of centralized API management and can begin consistently measuring REST API traffic and usage patterns to gain insights that will inform future decisions and actions.
WE5.2.3	If we implement monitoring dashboards and alarms for the MediaWiki REST API, then we may demonstrate a sustainable, useful, and replicable way to improve visibility into our systems’ behavior and surface issues sooner, especially during critical modifications.
WE5.3.1	If we expand and streamline UX attribution guidelines while updating any existing guidelines, we will establish a core set of improved guidelines ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2	If we create a pitch that demonstrates the benefits of attributing Wikipedia to 3rd party content reusers and their end-users, we can support WME4.1 & WME4.2 by enabling at least one additional reuse partner to agree to appear in an attribution case study or demo by the end of Q1.
WE5.4.1	If we ensure a majority of web requests get an edge uniques cookie, it will be easier to identify bots and forged requests.
WE5.4.2	If we build a scalable way to identify known clients, we can allow exceptions to general rate-limits for bots of verified origin, and move towards systematic enforcement of our rules.
WE5.4.3	If we reorganize filtering of text requests at the CDN around an allowlist/denylist approach, we can enforce stricter general rate-limiting for bots and streamline traffic filtering.
WE5.4.4	If we develop a unified measurement strategy, we will enable evaluation of the multi-year strategy for 'responsible use of infrastructure,' and define a roadmap to guide metric development and reporting capabilities.
WE6.1.1	If we rehome daily image builds to the deployment server and add image updates triggered by select deployment actions we will uncover constraints and establish a baseline for time needed to perform more continuous deployments.
WE6.1.3	If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.2.1	If we review and publish our Production Readiness Checklist that clearly defines the prerequisites for a service to be considered production-ready, along with self-serviceable tasks, we will align expectations between SREs and development teams, improving our overall operational efficiency and scalability.
WE6.2.2	If we announce creating a Golang and nodejs library abstracting a lot of toilous tasks for developers, they will respond offering feedback and interest.
WE6.2.3	If we create a checklist/worksheet, developers can fully prepare in advance for the Data Persistence design review.
WE6.3.1	If we roll-out at least 70 low-traffic Wikipedias in Q1, excluding wikis with Language variant support, we will increase our confidence for the eventual roll-out to the top 10 wikis which will have a bigger impact in page views served through Parsoid.
WE6.4.1	If we deploy splitting links table of Commons in its own cluster, we will increase the chances that database growth for Commons remains sustainable.	T398709
WE6.4.2	If we (SRE) provide assistance to the MediaWiki engineering teams - by creating documentation, preparing necessary infrastructure (e.g., PHP packages, container images), and offering guidance and review - they will be able to confidently initiate the production PHP 8.3 upgrade by the start of Q2.	T360995
WE6.4.3	If we require a physical second factor (hardware security key) for SSH logins by users with elevated system privileges, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.4	If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and Search Engine Optimization (SEO) risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.	T214998
WE6.4.5	If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2.	T360995

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Randau
Hypothesis shortname	Q1 text	Details & Discussion
SDS1.1.1	If we analyze the efficacy of the automated traffic detection heuristics in our pageviews datasets, we will be able to develop data quality metrics to describe their performance and determine the need for further investment in these heuristics.
SDS1.2.2	If we migrate the XML Dumps process from the current 'Dumps 1' infrastructure to a data pipeline that leverages the MediaWiki Content Pipelines we will be able to guarantee SLOs and turn off the 'Dumps 1'-based XML export.
SDS1.2.3	If we do a walkthrough and review the SLOs for MediaWiki Content History and Event Platform / Event Gate, we can validate the customers, metrics, and dependent stakeholders, and identify improvements that might be needed for the SLOs, which will help us clarify any gaps in our weekly delivery guarantees.
SDS2.1.1	if we pair closely with teams running experiments, we will learn how to make the system more self-service in the future and what conceptual or technical challenges they may run into.
SDS2.1.2	If we can implement better debugging for eventlogging, then product teams will know that their experiment is collecting event data as expected, increasing experiment owners’ confidence.
SDS2.1.3	If we improve logging and observability for the A/B testing system (xLab) component of the experimentation platform, and for its related MediaWiki parts, we’ll be able to establish baselines for the system's performance and respond to experiment-related failures.
SDS2.1.4	If we share experiment stories and results across the organization once a month (through Product Ops meetings, Design team meetings, and cross-team presentations), then we will create organic adoption of the experimentation platform.
SDS2.1.5	If we tell users that their instrument, if created in xLab, contains a set of attributes that changes the risk category, we will deter instrumentation users from over-collecting data and increase clarity around what combination of attributes require privacy review.

Future Audience (FA) Hypotheses [ FA Key Results ] Randau
Hypothesis shortname	Q1 text	Details & Discussion
FA1.1.1	If we 1) offer ways for media collectors on other platforms (such as Letterboxd, Goodreads, and RateMyMusic) to enhance their collections with Wikipedia-exclusive knowledge, or 2) offer these media collectors interesting social media shareables, then we will be able to increase Wikipedia's reach off-platform.
FA2.1.1	If we build up our internal capacity to create short video content (by increasing our team size and auditing and identifying opportunities to increase efficiency in our current production process) in Q1, we will be able to act on learnings from content created in FY2024-5 and achieve higher YoY reach of content produced in Q2 FY2025-6.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Randau
Hypothesis shortname	Q1 text	Details & Discussion
PES1.1.1	If we support xLab, Charts, and ToneCheck in defining metrics for SLIs (Service Level Indicators) in Prometheus, and onboard the those Service Level Objectives (SLOs) on Pyrra, we'll learn the limits and corner cases of our tooling in multiple complex scenarios, as well as clarify what iterations are needed for the SLO template, which will help us to better support the 6 planned SLOs for the KR.
PES1.1.2	If we pilot two sets of SLO alert dashboards, we'll learn how difficult it would be to implement suitable tooling such that service owners clearly understand their commitments, and also whether we need to migrate to a different tool that offers only a single view of a specific SLO. One dashboard will be for quarterly reports (where the actual Service Level Agreement for the error budget is set) and a smaller dynamic one (called "rolling") will be for day-to-day operations and alerting.
PES1.1.3	If we keep supporting the Abstract Wikipedia group in drafting an SLO (Service Level Objectives) for the Wikifunctions project, we'll learn how to define a list of SLO targets (alongside with their Service Level Indicator metrics) for a complex feature currently being added to a critical user workflow: rendering Wiki articles. We'll also learn how to properly visualize the related error budgets and alert on them using dashboards and monitors provided by SRE.
PES1.1.4	If we support the Data Platform group with review and iteration of the Service Level Objectives (SLO) for the MediaWiki Content History project, we'll learn how to leverage SLOs to support service ownership when a combination of batch and stream processing services are orchestrated together to update dataset, keeping it consistent and available to downstream users.
PES1.2.1	If we create 3 targeted improvements to the Wishlist, then we will encourage 30% more unique participants in the Wishlist
PES1.2.2	If we triage incoming wishes and assign a Maintainer (e.g. Product Managers) within 72 hours (including declining, clarifying, flagging unmaintained services, etc.), by cross-referencing new wishes against the Maintainers table and assigning a “Maintainer category” to the most relevant product team or individual, Maintainers (e.g. Product Managers) will be able to assess and respond to wishes in 10 days or less.
PES1.2.3	If we pilot work to identify community signals at large, we will incorporate more voice of volunteer in our community-informed prioritization efforts
PES1.2.4	If we pilot a quarterly wish and community signal review process with 3 teams in Q1, we will engage Product Managers to integrate community signals into their quarterly and annual planning processes.
PES1.3.1	If, by the end of Q1, we coordinate 3 functional planning sessions with the Communications department and product teams to align on messaging, creative needs, and campaign timelines for WP25 initiatives, then we will finalize creative briefs for all 3 campaign experiments (25YiR, Easter Eggs, WikiRun).
PES1.3.2	If we establish a steering committee with representatives from Design and feature engineering, we will be able to define baseline metrics about contributions to Codex: awareness, usage, quality of contribution, and quantity. Insights from assessing against these baseline metrics will help us determine a roadmap for federating growth and diversification of the Codex contributor base.

Q2

The second quarter (Q2) of the WMF annual plan covers October-December.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] Randau
Hypothesis shortname	Q2 text	Details & Discussion
WE1.1.1	If we analyze a pre-predetermined set of leading indicators ≥2 weeks after the start of the Paste Check A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.4	If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.7	If we analyze a pre-predetermined set of leading indicators ≥2 weeks after the start of the Tone Check A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.8	If we apply the Tone Check model to published articles, we will learn whether we can identify the ≥10,000 tone issues (each with a probability score of 0.8 or higher) that are needed to build a high-quality (accuracy ≥ 70%) pool of suggestions to help guide editors in improving article tone.
WE1.1.10	If we interview ~10 experienced volunteers at en.wiki and fr.wiki who write AbuseFilters (and other gadgets/scripts/templates/edit notices) to automate patrolling/moderation workflows, we will identify ≥3 patterns/needs that will help shape the value proposition of community-authored Edit Checks.
WE1.1.11	If we distribute a survey to ≥500 successful newcomers[i] and obtain high quality data that is representative of the broader successful newcomer population, we will be able to identify ≥4 actionable insights we can use to prioritize what aspects of the onboarding experience to improve.
WE1.1.12	If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.13	Given we scaled “Add a Link” to 100% of newer volunteers at English Wikipedia, then newcomer constructive activation and retention will improve, which will increase constructive edits made by newer volunteers by ≥4%.
WE1.2.3	If we remove the requirement that someone needs the Event Organizer right to use Event Registration on small and medium-sized wikis, then we will see at least X more events* created on small and medium-sized wikis by the end of the fiscal year. pending baseline/target calculation.
WE1.2.4	If we iterate on the Collaborative Contributions MVP with at least 2 improvements, then more collaborations will be created via Event Registration.
WE1.2.5	If we set one adoption strategy for Event Registration on Wikimedia Commons in early Q2, we will be able to test it with organizers of at least 1 large campaign and enable 5 local organizers to use the feature.
WE1.3.3	If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.4.1	If we make improvements defined in T396489, we will reduce the slow recentchanges queries by at least 30% on large wikis, which will enable Community Tech to deploy Watchlist Labels without overloading the recentchanges database.
WE1.4.3	If we instrument recent changes and watchlist, then we can define a baseline for how often people click to pages.
WE1.5.1	If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.2	If we determine in Q2 which moderation actions to include in the definition of who is a Moderator, then the Movement Insights team can build out the metric of Monthly Active Moderators in Q3/Q4.
WE2.1.3	If we learn about the editor experience when creating new articles and sections (including motivations, pain-points and their reaction to new ideas on how to better support them),then we will uncover user needs and behaviors that provide actionable insights and strategies to inform product, design, and engineering on improving the article creation experience.
WE2.2.12	If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.13	If we socialize the availability of the conjugation table function with the Wiktionary community, we will gain valuable feedback about function usage and insights into our user personas that we can apply to future rollouts.
WE2.2.14	If we look into the community’s Databox work on using Wikidata for infoboxes and investigate whether Wikifunctions might help, we will be able to identify a first experiment for Wikifunctions in infoboxes.
WE2.2.15	If we create community awareness about the ability to create and translate error messages on Wikifunctions, we will see an increase in the number of helpful error messages.
WE2.2.16	If we demo available semantic functions to the community, we will see an increase in grammatical functions by 50%.
WE2.2.17	If we provide a custom component for viewing Wikidata statements on Wikifunctions, users will be more able to understand data fetched from Wikidata and feel less overwhelmed.
WE2.2.18	If we can prevent 10x memory consumption spikes, the orchestrator will be better able to handle Wikidata objects, supporting the utility of Wikifunctions as a platform for Abstract Wikipedia.
WE2.2.19	If we enable users to share direct links to specific function calls — including their inputs — contributors will be able to reproduce, verify, and discuss function behavior more easily, which will in turn speed up debugging, improve testing workflows, and support collaborative problem-solving across the Wikifunctions community.
WE2.3.1	If we finalize the decision for creating a new wiki and decide on a name with the community, we will be able to more broadly socialize the creation of this new wiki with our stakeholders and prepare for the logistics of a potential product name change.
WE2.3.2	If we define an MVP for an Abstract wiki prototype that includes the barest possible experience for testing our back-end and NLG capabilities, and allows us design iteratively, we will be able to plan and launch a live prototype in Q3.
WE2.3.3	If we start talking to the community and exploring potential designs for the user experience of an Abstract wiki, we will be able to keep work moving forward in Q3.
WE2.4.1	If we collect Wikidata and WDQS use cases from WMDE and WMF teams, we will be able to define product requirements for infrastructure improvements.
WE2.4.2	If we produce an aggregated reporting view of key performance indicators (KPIs) with existing service level objectives (SLOs) for Wikidata and WDQS, we will be able to articulate and track success criteria for improvements to the technical infrastructure supporting the critical Wikidata use case.
WE2.4.3	If we can evaluate and benchmark alternative stores to Blazegraph using production-realistic criteria within the quarter, we will be able to make a data-driven migration decision and articulate a concrete roadmap with timeline and resource requirements.
WE3.1.1	If we A/B test an improved version of the Tabbed browsing feature, we’ll see a 5% increase in multi-day usage among Tabs users.
WE3.1.3	If we provide a new way for users to browse through relevant image content within article pages, and test it with a subset of logged-out readers via an A/B test across a set of wikis, we will see at least an 3% click-through rate among users who are presented with this feature.
WE3.1.4	If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.
WE3.1.5	If we provide web readers the option to view a machine translated version of Wikipedia content unavailable in their language, we'll learn if reading activity is increased, measured as a 3% increase in page interactions, drawing readers to the local language wiki with a potential increase in local editing activity. This will be provided as a controlled A/B testing setting for no longer than 6 months, and in 13 Wikipedias with prior consent, using open machine translation services already available to Wikipedia editors.
WE3.1.6	If we produce a prototype for semantic search and in-article Q&A, delivered as a demo interface that contrasts the current approach with new exploratory approaches, then the Reader teams will be able to qualitatively evaluate how each approach performs across different user journeys and surface gaps or opportunities for further iteration.
WE3.1.7	If we review existing research on how readers interact with search and navigation tools on Wikipedia, and how they use external search to find knowledge on Wikipedia, we will be able to provide the Reader teams with ≥3 actionable recommendations and findings that help them scope a search and discovery MVP to address gaps in reader expectations and needs.
WE3.1.8	If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.9	If we show high-fidelity design concepts for content discovery through semantic search to 10-20 casual Wikipedia readers in a qualitative study, we will see positive sentiment for the feature and gain the confidence needed to proceed with a search and discovery MVP that relies on short-form human-written excerpts to search queries.
WE3.1.10	If we show 10 casual readers a live prototype of the new image browsing experience in an unmoderated user study, we will uncover at least one UX improvement for future iterations of the feature.
WE3.1.11	If we relax the matching of keywords in Search, then we better support natural language queries, and enable Product to evaluate this capability, include it in how they design, prioritize and deliver work in the Semantic Search space.
WE3.2.5	If we introduce a Year in Review feature on Android that highlights user impact and includes integrated donor messaging, we’ll drive new donation behavior—and we’ll see a 5% increase in app menu compared to 2024.
WE3.2.6	If we make the donor slides in the iOS Year in Review, more integrated, and personalized, we’ll see a 5% increase in donations compared to 2024.
WE3.3.3	If we introduce at least one unlockable avatar in the Android app for account holders—earned through meaningful reader actions like saving a certain number of articles — we’ll increase repeated engagement with associated action by logged-in users by 10% over multiple days.
WE3.3.4	If we give logged-in readers the ability to save articles to a private reading list, we expect engagement on the site to increase, as measured by a 5% increase in internal referral traffic for readers who use the feature, and a statistically significant increase for all users.
WE3.3.6	If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.3.7	If we leverage the data platform’s processing capabilities to aggregate tailored editor metrics and impact data and serve the aggregated data through suitable services with defined SLOs, we can enhance future iterations of Year in Review WE3.3.1 and Activity Tab WE3.3.2.
WE3.3.9	If we release Year in Review on Android and A/B test offering engaged users a reward to save a custom reading list, we will see a 1% increase in overall app retention rate amongst readers offered the reward compared to those who were not.
WE3.3.10	If we A/B test requiring an account to view the personalized reading insights of Year in Review, we’ll see a 1% increase in overall retention rate for users that were required to have an account, compared to those that were not.
WE3.3.11	If we A/B test an improved version of the “Activity” tab on iOS that highlights reading, editing and other participation behaviors, we will see a 5% increase in multi-day visits by logged-in readers to the tab compared to the prototype version.
WE3.4.1	If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.1	If Product & Technology and Fundraising collaboratively evaluate and document technical approaches for identifying donors within our platforms, we will be able to recommend a short- and long-term solution that balances privacy, feasibility, and impact. This shared understanding will help align decision-making, enable persistent donor recognition across platforms, as well as more targeted experimentation in future fundraising related features.
WE3.6.3	If we engage communities in conversations about the evolving needs of readers, and about the changing nature of knowledge on the internet, we can build a shared focus on how to serve readers and work together on whether and how to test our various ideas (including those around multimedia, search and discovery, and machine learning).
WE3.6.4	If we research the distinct motivations, behaviours, and needs behind when, why and how readers use Wikipedia and other knowledge platforms, we will be able to propose priority areas and specific initiatives for the consumer strategy.
WE3.6.5	If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6	If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE4.1.1	If we prototype a minimally viable non-emergency flow, and keep open an iterative feedback loop as we develop it with users with extended rights, then these groups will support expanded deployment of this flow.
WE4.1.3	If we update 7 Wikipedias (French, German, Spanish, Hungarian, Italian, Polish, Portuguese) by the end of October, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.1.4	If we deploy the Incident Reporting System MVP to at least 15 wikis, with a focus on larger complex communities, we will observe it being used as intended by the community, and will have demonstrated a working model for non-emergency incident reporting.
WE4.1.5	If we design a flow diagram for reporting incidents of abuse to wikis without established abuse-handling processes, this will encourage adoption of the Incident Reporting System on such wikis and enable users on those wikis to have a clear and viable support pathway.
WE4.2.3	If we analyze data from the hCaptcha account creation trial, we will understand the account creation funnel, the effectiveness of hCaptcha’s puzzle and scores, and have the data necessary to inform further rollout of hCaptcha on account creations.
WE4.2.5	If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.2.6	If we develop the capability for deploying OpenSearch based clusters on the Data Platform, product feature engineering teams will be empowered to develop systems that integrate this capability, with a great deal of autonomy, resilience, and isolation from other search-based systems. The first and principal tenant for this system will be the IPoid service.
WE4.2.7	If we deploy hCaptcha Enterprise integration on several production Wikipedias as a pilot trial, we will be able to collect data on the efficacy and value of hCaptcha Enterprise on anti-abuse, bot detection, usability and accessibility.
WE4.2.8	If we make the hCaptcha proxy production-ready by improving its availability and observability, we will be delivering a more stable and reliable service to production Wikipedias in Q1.
WE4.2.9	If we integrate the hCaptcha SDK into the native mobile apps, evaluate the native app user experience and evaluate enabling hCaptcha challenges as part of the account creation API, we will have sufficient understanding to inform further rollout of hCaptcha for the account creation API.
WE4.2.11	If we enable hCaptcha for detecting bots in higher risk editing scenarios, we will see that hCaptcha can reduce automated abuse.
WE4.2.16	If we consult with relevant WMF teams, we will be able to develop an agreed-upon plan to manage more granular user access to non-public data, and support the deployment of non-public defensive software rules.
WE4.2.17	If we analyze real world examples and interview CheckUsers to identify at least 2 signals of potential abusive behaviour from the editor history prototype, the Product Safety and Integrity team will be able to later incorporate these signals into the Suggested Investigations feature with a higher level of confidence that the signals will provide value.
WE4.3.2	If we deploy JA4H fingerprints, which summarize HTTP client behavior, we will be better able to identify and categorize bot traffic
WE4.4.1	If we can make improvements based on pilots feedback and deploy Temporary Accounts to all projects we will be able to protect the exposure of personally identifiable information (IP addresses) of unregistered users on all our projects to be available to less than 0.1% of all (registered) users
WE4.4.2	If we communicate with the relevant movement stakeholders (incl. wiki communities and global functionaries) clearly and on time, we will be able to deploy on all remaining wikis, reduce workload discovered last-minute, and avoid rolling back deployment.
WE4.4.5	If we reduce friction for patrollers to identify bad actors who are using temporary accounts to vandalise, we will be able to prevent an increase in vandalism by measuring no increase in the revert rate across all wikis with temporary accounts.
WE4.4.6	If we sunset the LiquidThreads extension, we will unblock Temporary Accounts being deployed to all projects that currently use this extension.
WE4.6.1	If we automate the sync account process within Zendesk for password resets, this will alleviate the burden on T&S and allow them to handle more incoming 2FA reset requests
WE4.6.3	If we allow all users with a confirmed email address to be able to turn on 2FA for their accounts, but do not proactively advertise this change to users, our recovery support desk load will remain at a sustainable level.
WE4.6.4	If we continue our user experience overhaul of our 2FA system, and add support for passkeys, then more users will register multiple authentication factors and be better protected against losing account access.
WE4.6.5	If we design and build a general framework for specifying requirements that a local or global group’s members must meet, we will use this framework to enforce that members of the temporary-account-ip-viewer group meet existing policy requirements.
WE4.6.6	If we research how users with extended rights (UWER) rely on User Scripts, we will be able to propose a plan, which the UWER community could support, to make one or more significant technical interventions that would meaningfully secure the User Scripts system.
WE4.6.7	If we evaluate the user experience and technical changes required for the native mobile apps to align the mobile sign-in experience with the web platform, through exploring alternative mechanisms like OAuth, we can determine the feasibility of integration, in the interest of providing a more secure and consistent experience for users.
WE4.6.8	If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.2b	If we integrate multiple methods for developer identification and authentication in the API gateway, we will be able to assign an appropriate rate limit to each request, by correctly identifying requests that come from different user cohorts.
WE5.1.3b	If we perform a dry run for rate limiting on at least 3 routes of the REST gateway, this will allow us to verify feasibility of rate limiting with respect to resource consumption and to define an initial set of limits that could be enforced with minimal user impact.
WE5.1.4b	If we validate the proposed API user segmentation mechanisms with broader data sets and manual reviews of the identified groups, we will be able to finalize the user cohorts, refine the methodologies used for calculation, and better understand their efficacy.
WE5.1.5	If we collaborate with the MediaWiki Platform team on traffic identification and rate limiting, we will be able to deploy rate limiting for dry run testing in production, by supporting the Platform team in the creation and roll out this capability.
WE5.2.1b	If we engage with prospective users of the new REST API Explorer, this will help us identify key usability insights that indicate whether the new design is easy to use and aligned with developers’ mental model.
WE5.2.2b	If we route the Action API through the central API gateway, we can begin consistently measuring traffic and usage patterns to gain insights that will inform future decisions and actions.
WE5.2.4	If we implement standard documentation patterns for 2 APIs, we will be able to refine the content guidelines, understand what API owners need in order to adopt the guidelines, and quantify the effort required to implement the guidelines across remaining Wikimedia API docs.
WE5.2.5	If we experiment with defining and applying OpenAPI spec linting rules to the MediaWiki REST APIs, we will demonstrate a means of programmatically enforcing API style guides to improve the quality and consistency of APIs published across Wikimedia and our communities.
WE5.3.1	If we expand and streamline UX attribution guidelines while updating any existing guidelines, we will establish a core set of improved guidelines ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.1b	If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2	If we create a pitch that demonstrates the benefits of attributing Wikipedia to 3rd party content reusers and their end-users, we can support WME4.1 & WME4.2 by enabling at least one additional reuse partner to agree to appear in an attribution case study or demo by the end of Q1.
WE5.4.2b	If we build a scalable way to identify known clients, we can allow exceptions to general rate-limits for bots of verified origin, and move towards systematic enforcement of our rules.
WE5.4.5	If we start enforcing rate limits tailored to different classes of individual clients, we will reduce the burden of crawling on our infrastructure.
WE5.4.6	If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.7	If we settle on a standardized sets of allowed thumbnail sizes on our media infrastructure, and we pregenerate the most expensive ones while rate-limiting generation of different image sizes, we will reduce the burden on the media serving infrastructure.
WE6.1.2	If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.2.1	If we review and publish our Production Readiness Checklist that clearly defines the prerequisites for a service to be considered production-ready, along with self-serviceable tasks, we will align expectations between SREs and development teams, improving our overall operational efficiency and scalability.
WE6.2.2	If we announce creating a Golang and nodejs library abstracting a lot of toilous tasks for developers, they will respond offering feedback and interest.
WE6.2.4	If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production.
WE6.3.2	If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3	If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.4.6	If SRE provides assistance to the MediaWiki engineering teams - through capacity and traffic management, preparation and review of configuration changes, and collaboration to investigate and troubleshoot issues - we will together complete the production PHP 8.3 upgrade in Q2 and document a set of recommendations to minimize critical-path dependencies on SRE for future upgrades.	T360995
WE6.4.7	If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8	If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.	T360995

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Randau
Hypothesis shortname	Q2 text	Details & Discussion
SDS1.2.1	If we migrate the XML Dumps process from the current 'Dumps 1' infrastructure to a data pipeline that leverages the MediaWiki Content Pipelines we will be able to guarantee SLOs and turn off the 'Dumps 1'-based XML export.
SDS1.2.2	If we do a walkthrough and review the SLOs for MediaWiki Content History and Event Platform / Event Gate, we can validate the customers, metrics, and dependent stakeholders, and identify improvements that might be needed for the SLOs, which will help us clarify any gaps in our weekly delivery guarantees.
SDS1.3.1	If we introduce client-side signals and audit them in comparison to the server-side webrequest logs, we will find additional bot patterns that can be characterized.
SDS1.3.2	If we assume the current bot vs human distribution as baseline and create automated alerts for shifts in the distribution, we will decrease detection time of the next unforeseen pattern of automated traffic from weeks to minutes.
SDS1.3.3	If we automate the backfill mechanism for webrequest and use it on the May logs, we will decrease the remediation time for future incidents from months to days and resolve the “rise in May pageviews” incident.
SDS1.3.4	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.3.5	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS1.3.6	If we import, analyze and incorporate into our heuristics the Spur.us IP reputation, we will detect additional bot patterns in the Data Platform.
SDS1.3.7	If we import, analyze and incorporate into our heuristics one signal from the edge, we will detect additional bot patterns in the Data Platform.
SDS1.4.1	If we reconfirm existing analysis of trends within the Wikimedia ecosystem - pageviews, contributor and readership metrics, traffic, etc. - we will be able to confidently support salient talking points for our most important movement insights.
SDS1.4.2	If we reconfirm existing analysis of trends within the Wikimedia ecosystem - pageviews, contributor and readership metrics, traffic, etc. - we will be able to confidently support salient talking points for our most important movement insights.
SDS2.1.1	if we pair closely with teams running experiments, we will learn how to make the system more self-service in the future and what conceptual or technical challenges they may run into.
SDS2.1.2	If we can implement better debugging for eventlogging, then product teams will know that their experiment is collecting event data as expected, increasing experiment owners’ confidence.
SDS2.1.3	If we improve logging and observability for the A/B testing system (xLab) component of the experimentation platform, and for its related MediaWiki parts, we’ll be able to establish baselines for the system's performance and respond to experiment-related failures.
SDS2.1.4	If we share experiment stories and results across the organization once a month (through Product Ops meetings, Design team meetings, and cross-team presentations), then we will create organic adoption of the experimentation platform.
SDS2.1.5	If we tell users that their instrument, if created in xLab, contains a set of attributes that changes the risk category, we will deter instrumentation users from over-collecting data and increase clarity around what combination of attributes require privacy review.
SDS2.1.6	If the Growth Team works on instrumenting 2 use-cases (one with an A/B test to gain insight about bucketing capabilities, and one with long-term instrumentation to learn about support for KPI-like metrics) with the Experiment Lab, then we can evaluate whether it sufficiently fulfils the requirements to replace our bespoke experiments setup in GrowthExperiments.

Future Audience (FA) Hypotheses [ FA Key Results ] Randau
Hypothesis shortname	Q2 text	Details & Discussion
FA1.1.4	[Continued from last FY] If we build a new Wikipedia experience on Roblox, we will learn if this could be an effective way to introduce our brand to younger (Gen Alpha) audiences.
FA1.1.2	If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] Randau
Hypothesis shortname	Q2 text	Details & Discussion
PES1.1.5	If we onboard the service level objectives (SLOs) for MediaWiki Content History and Wikifunctions to Sloth/Pyrra, we will get 2 more SLOs into production.
PES1.1.6	If we pilot Sloth with retroactive data from existing SLOs, we will understand whether Pyrra or Sloth (or something else) is the right tool for our fixed-window approach to error budget windows. We will learn about how to support service owners with a self-serve approach to SLO metrics and use them in decision making.
PES1.2.4	If we pilot a quarterly wish and community signal review process with 3 teams in Q1, we will engage Product Managers to integrate community signals into their quarterly and annual planning processes.
PES1.2.5	If we add the ability to filter and sort wishes on the Wishlist extension, to the improvements that allow categorisation with tags and voting, the 3 improvements will increase more unique participants in the Wishlist by at least 30%.
PES1.3.3	If we create at least 5 delightful interventions on platform that occur based on user interactions, we will define what the triggers will be for the portal page and the Birthday Mode gadget. Usability testing will tell us which interventions create positive associations with our brand. This hypothesis is time-bound to end by WikiCon North America at the end of October.
PES1.3.4	If we create an immersive website exploring Wikipedia's history, present, and future, in collaboration with members of the Comms department, aimed at engaging online audiences between 18-34 in campaign target areas, it will simulate greater connection with Wikipedia via social shares and other online activities. This will contribute to Comms’ KR of increasing brand presence by 10 percentage points, while telling us if dynamic approaches to content improve brand likeability.

Planning Together

January 2025 update.

Perambu Genap Taun nya penerang Yayasan Wikimedia pasal utai ti dikearapka kitai ulih dijapai dalam taun ti deka datai. Kami bebendar gawa ngambika pelin nya bisi penyereta, bisi aspirasyen sereta ulih dijapai. Ninting taun, kami minta bala penyaup bekunsika perspektif, pengarap enggau peminta ti spesifik lebuh kami nempa pelin nya. Sekeda chara kami ngiga input nya iya nya nengah randau tim produk enggau komuniti, Rintai Pengingin Komuniti, randau komuniti baka siri randau Commons, ba aum besai enggau nengah lambar wiki baka ke diatu.

Ungkup perambu genap taun kami ti deka datai, ari bulan Julai 2025 ngagai Jun 2026, kami berunding baka ni kami ulih meri servis ti pemadu manah ngagai visyen mayuh rebak, berindik ari ubah ti jampat nyadi ba dunya enggau internet lalu baka ni nya meri empas ngagai misi penemu kami ti bibas.

Baka ti udah dipadah aku taun nyin kemari, kitai patut fokus ngagai utai ti nyelaika kitai: pengulih kitai nyendiaka isi ti tau dikearapka taja pan penerang ti salah enggau penerang ti salah majak nambah ba serata internet enggau ba pelasar ti berebutka perati rebak baru. Tu nyengkaum nentuka kitai nyapai misyen ngumpul sereta ngenataika penyampau semua penemu mensia ngagai dunya nengah chara ngerembaika bungkur penerang kitai ti lenyau, ti tau nyadi ketegal layan ti enda sebaka, diskriminasyen enggau bechiping. Isi kitai mega begunaka servis sereta mengkang beguna dalam internet ti berubah ti dipejalaika pemintar tiru enggau peneleba ti kaya. Lalu ke penudi, kitai patut ngiga chara dikena melanja pejalai kitai enggau meruan nengah chara ngaga strategi bekunsi ungkup produk enggau ngumpul belanja kitai ngambika kitai ulih nyukung pengawa tu ungkup kandang maya ke panjai.

Dikena ngaga pilih enggau tukar ganti pasal dini endur deka fokus ngagai pengawa kami ba taun ti deka datai, kami ngumpul tanya lalu berunding baka ni deka ngagihka perengka guna kami ti bisi sekat nuju ngulihka empas ti pemadu manah.

Enti nuan bisi minat enggau spesifik ba nama penteba tauka servis ti deka digaga jabatan Produk enggau Teknologi bepelasarka pemerat ti ditetapka ditu, bisi awak dalam bulan Mac meri komen pasal objektif ti spesifik enggau asil kunsi. (Tu objektif enggau asil kunsi ungkup perambu genap taun ke diatu, nyadika penyanding.)

Enti nuan deka berunding pasal penanggul enggau peluang dalam rampa teknikal kami enggau tuju ti patut ditetapka kami dalam perambu genap taun ti deka datai, minta berundingka tanya di baruh tu enggau kami.

Kami seruran ngambi penerang pasal tanya tu ngena mayuh chara -- ari randau komuniti, data ti digumpul kami, interbiu pansik ti digaga kami, enggau mayuh agi. Tu ukai keterubah iya kami nanya sereta belajar pasal mayuh utai tu–lalu kami udah ngereja pengawa ngelingi mayuh utai nya! Kami deka nanya sida baru diatu lalu terus belajar, laban sida nya pekara keterubah ba kami ba renggat perambu kami tu.

Tanya:

Metrik enggau data
- Nama sekeda chara data enggau metrik ulih nyukung pengawa nuan nyadi editor enggau manah agi? Ulih nuan berundingka data pasal ngedit, macha, tauka ngatur utai ti ulih nulung nuan milih chara ngena awak nuan, tauka maya utai ti begunaka perati? Tu tau nyadi data pasal pengawa nuan empu tauka pengawa orang bukai.
Ngedit
- Kemaya pengawa ngedit berasai pemadu mai penguntung sereta ngerinduka ati nuan? Kemaya iya berasai pemadu asa sereta tusah?
- Kami deka ke bala penyaup nerima mayuh agi timbal enggau pengangkun ketegal pengawa sida, nya alai enda berasai nadai orang beratika pengawa ti dipelanja sida ba wiki. Nama bansa timbal enggau pengangkun ti meransang nuan? Nama utai ti meransang nuan terus ngedit?
- Ketegal wiki nya mayuh amat, tau ngasuh bala editor tusah deka mutuska nama pengawa wiki ti pemadu beguna dikena sida ngena awak sida ninting hari. Nama penerang tauka kereban ke ulih nulung nuan milih chara ngena awak nuan? Kati bisi guna enti bisi endur ti tengah, ti personal ti ngemendarka nuan ngiga peluang baru, ngatur pengawa nuan, sereta meretika empas nuan?
- Kami deka ngemanahka agi peneleba kerejasama ba wiki, ngambika nyamai agi ngagai bala penyaup ngiga pangan diri lalu gawa ba projek begulai, sekalika nya nengah backlog drive, edit-a-thons, WikiProjects, tauka dua iku editor ti bekerejasama. Baka ni runding nuan, baka ni kitai ulih nulung mayuh agi orang ke meri bantu ngiga pangan diri, besambung, sereta bekerejasama?
Macha/Belajar
- Wiki nya jampat tauka laun dimuat bepanggai ba dini endur ba dunya tu orang diau. Bisi endur ba dunya tu ke dipeda nuan pemadu begunaka pengawa ti manah agi?
- Baka ni kitai ulih nulung bala pemacha rebak baru nemu isi Wikipedia manah sereta narit ati? Kami udah berandauka penemu pasal isi interaktif enggau video dulu suba, lalu ba taun ke diatu udah fokus ngagai charta enggau ba nguji chara baru dikena mantaika isi Wikipedia ke udah bisi. Baka ni kitai tau terus ba jalai tu ngena isi kitai ti udah bisi ngena chara baru ti nyelai ba Wikimedia?
Moderator
- Nama utai ti engka patut diubah pasal Wikipedia ngambika mayuh agi orang deka ngaul diri dalam pengawa voluntia ti mansang, baka pengawa matau tauka admin?
- Nama penemu tauka konteks pasal edit tauka pengguna ti ulih nulung nuan ngaga pemutus pengawa matau tauka admin enggau jampat tauka mudah agi?
Alur Luar
- Nama ubah ti pemadu beguna ti diperatika nuan ba dunya luar Wikimedia? Tu engka gaya teknologi, pelajar, tauka chara orang belajar.
- Di luar ari engkebut Wikimedia, nama komuniti online bukai ti bisi enggau nuan? Nama ajar ti ulih diambi kitai ari kereban enggau proses ba pelasar komuniti bukai?
- Baka ni nuan ngena perengka AI dalam enggau luar pengawa Wikimedia nuan? Nama utai ti ditemu nuan beguna AI?
Commons
- Nama pemutus ti ulih digaga kitai enggau komuniti Commons dikena nempa projek ti meruan ti nyukung nempa penemu ensiklopedia?
Wikidata
- Baka ni nuan deka meda Wikidata mansang jemah ila? Baka ni iya tau pemadu beguna dikena nempa isi ensiklopedia ti tau dikearapka?

Randau

–– Selena Deckelmann