Jump to content

Plan Anual de la Fundación Wikimedia/2025-2026/Objetivos y Resultados Clave de Producto y Tecnología

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 59% complete.
Outdated translations are marked like this.
Other languages:
Plan Anual de la Fundación Wikimedia 2025-2026

El próximo año

A medida que el mundo cambia, la Fundación Wikimedia continúa su convicción de hacer que nuestra misión - es decir, crear y mantener información útil en los proyectos Wikimedia disponible en Internet de forma gratuita - sea un esfuerzo intergeneracional. Queremos que el conocimiento libre siga estando disponible para muchas generaciones futuras.

Internet está cambiando rápidamente. Las nuevas generaciones se informan a través de vídeos, redes sociales y experiencias de IA y, en comparación con las generaciones anteriores, cada vez son menos los que conocen Wikipedia. Estamos viendo descensos relacionados en el número de personas que visitan nuestros sitios y el número de personas que editan. Mientras tanto, las plataformas de internet dependen del contenido de Wikimedia para sustentar sus ofertas de IA y sus búsquedas. Estas dinámicas son desafíos importantes, pero dejan claro por qué el conocimiento libre y fiable que creamos juntos/as es tan importante. El mundo necesita más que nunca una fuente de conocimiento fiable y revisado por humanos y los proyectos Wikimedia siguen demostrando que pueden proporcionarla.

Para hacer frente a estos retos en el próximo año, vamos a construir vías para aprovechar el contenido de Wikimedia de manera sostenible, y llevaremos el contenido de Wikimedia a los espacios sociales en línea donde las nuevas generaciones están pasando su tiempo. Mejoraremos nuestros propios sitios para que los lectores/as quieran volver, participar en profundidad y contribuir de forma significativa para ellos/as. También invertiremos en nuestra capacidad para experimentar rápidamente con nuevas tecnologías, de modo que nuestro ritmo de desarrollo se adapte al ritmo al que cambia el mundo.

El objetivo de la infraestructura es cómo la plataforma y la experiencia del usuario permitirán afrontar estos desafíos y llegar a la mayoría de los/as participantes en el movimiento. No se trata de una lista de proyectos, sino de un conjunto de directrices para impulsar el crecimiento del voluntariado, permitir a los/as voluntarios/as crear contenidos enciclopédicos fiables, financiar nuestra misión y hacer evolucionar nuestra oferta para dar forma a la cambiante Internet. Puedes leer más sobre esos cuatro pilares estratégicos.

Impulso al crecimiento del sector voluntariado

La comunidad de voluntarios y voluntarias es el único motor del éxito de los proyectos Wikimedia y necesitamos que sea saludable y crezca, pero en este último año, hemos visto descensos continuos en el número de nuevos editores y de editoras que regresan a los proyectos. Para comprender mejor y responder más eficazmente a las necesidades de nuestros/as voluntarios/as actuales, la Fundación renovó la lista de deseos de la comunidad, que pasó de ser una encuesta anual a ser un proceso de admisión siempre abierto en el que las necesidades de los usuarios/as y las ideas de proyectos puedan alimentar el trabajo de múltiples equipos de la Fundación. Agrupamos los deseos en «áreas de interés» y hemos integrado tres de esas áreas de interés en los resultados clave del plan anual. También hemos puesto en marcha un Consejo Asesor de Productos y Tecnología piloto para complementar las numerosas conversaciones que los equipos de la Fundación mantienen con los miembros de la comunidad dentro y fuera de la wiki a lo largo del año. Además, hemos identificado oportunidades para incorporar nuevas generaciones a nuestros proyectos, como el hecho de que los/as más jóvenes participen con entusiasmo en otros espacios sociales en línea en los que disponen de formas sencillas y fáciles de usar desde el móvil para conectarse sobre temas de interés común.

El año que viene impulsaremos el crecimiento del voluntariado facilitando la contribución y haciéndola más atractiva para las nuevas generaciones mediante la expansión de nuevas formas de editar que prioricen los dispositivos móviles («tareas estructuradas») y la incorporación de flujos de trabajo inteligentes que faciliten la edición constructiva desde el móvil (celular) a los/as nuevos/as colaboradores/as («comprobaciones de edición»). Para implicar y retener más a los/as voluntarios/as existentes, ofreceremos acciones y tareas recomendadas y las presentaremos en un sitio centralizado que facilite la organización de la actividad en la wiki. Utilizaremos cuidadosamente la IA para reforzar a los/as voluntarios/as en su trabajo, manteniendo siempre a los humanos informados y dando prioridad a la transparencia. Tanto para los/as voluntarios/as nuevos/as como para los/as experimentados/as, crearemos vías para conectarse y trabajar juntos/as en nuestros sitios - inspirados en campañas y WikiProyectos exitosos - permitiéndoles encontrar editores afines y mejorar el contenido relacionado con sus intereses (alineado con esta área de interés de la lista de deseos).

Ofrecer contenidos enciclopédicos fiables

A medida que el material generado por IA se multiplica en internet, el mundo necesita más que nunca contenidos enciclopédicos fiables. Queremos aumentar la capacidad del voluntariado para crear nuevos contenidos, garantizar que los existentes sigan siendo fiables y ofrecer contenidos fiables a una nueva generación de lectores/as con nuevas necesidades y preferencias.

Para ayudar al voluntariado a crear nuevos contenidos, nos basaremos en herramientas y flujos de trabajo guiados ya existentes, como la herramienta de traducción de contenidos, de modo que tanto las comunidades grandes como las más pequeñas puedan cubrir contenidos vitales. Para garantizar que los contenidos existentes sigan siendo fiables, ayudaremos al voluntariado experimentado a gestionar mejor su creciente carga de trabajo ampliando las herramientas que utilizan para encontrar tareas que requieren su atención, facilitándoles la actualización de artículos y la reversión de ediciones inútiles (en línea con esta área de interés de la lista de deseos).

También ayudaremos a los/as funcionarios/as a defender nuestros contenidos haciendo aflorar nuevas señales, más allá de las direcciones IP, que identifiquen a los malos actores, permitiendo bloquear a los/as usuarios/as de forma que se minimicen los bloqueos erróneos de editores/as de buena fe.

Para ofrecer contenido enciclopédico a una nueva generación, crearemos funciones que ayuden a los nuevos tipos de lectores a entender los artículos fácilmente, a encontrar la información que les interesa y a participar activamente mientras leen. Estos cambios pretenden animar a los nuevos lectores de Wikipedia a convertirse en lectores dedicados de Wikipedia, y a algunos de ellos a convertirse en donantes (en línea con esta área de interés de la lista de deseos).

Ofrecer contenidos fidedignos también significa apoyar un modelo de «conocimiento como servicio», en el que todo internet se nutre de los contenidos de Wikimedia. En este modelo, nuestra infraestructura no es únicamente un recurso valioso para las personas que visitan nuestro sitio web, sino también para las empresas de búsqueda e inteligencia artificial, que acceden a nuestro contenido automáticamente como entrada y salida fundamental de sus productos. Este tipo de empresas representan solamente uno de los muchos usos que suponen una carga cada vez más insostenible para nuestra infraestructura. En el último año, un aumento significativo del volumen de solicitudes procedentes de herramientas de extracción de información web y bots ha hecho más urgente que corrijamos esta tendencia. Tenemos que establecer vías sostenibles para que desarrolladores y reutilizadores accedan a los contenidos del conocimiento, de modo que se dé prioridad a los humanos sobre los bots.

Financiar el porvenir de «lo gratis»

El departamento de Producto y Tecnología desempeña un papel importante para garantizar la sostenibilidad de nuestro movimiento. El año que viene colaboraremos estrechamente con el equipo de Recaudación de Fondos para que nuestros donantes tengan una experiencia cada vez más clara y gratificante. En nuestros sitios web y aplicaciones móviles, crearemos oportunidades para que los/as lectores/as expresen su agradecimiento a Wikipedia a través de donaciones y crearemos nuevas formas de que los/as donantes se sientan reconocidos/as para que continúen con sus donaciones año tras año.

Dar forma a una internet cambiante

Para llevar el conocimiento libre a todas las personas del mundo, tenemos que encontrarnos con ellas allí donde estén, con las experiencias que les ayudan a aprender. Las personas de entre 18 y 24 años tienen un menor conocimiento y uso de Wikipedia que las generaciones anteriores. Aprenden e interactúan principalmente con plataformas de vídeo de formato corto, personalidades en línea de confianza, experiencias de juegos sociales y, cada vez más, aplicaciones de IA. Este año, pondremos Wikipedia a disposición de esas audiencias en los lugares en los que pasan tiempo en línea, para que conozcan Wikipedia como una fuente de conocimiento fiable y creada por humanos. Aumentaremos nuestra presencia en plataformas de vídeo populares, difundiendo contenidos de Wikipedia y generando comunidad en esos espacios. Y exploraremos ideas para llevar el conocimiento de Wikipedia a los juegos y las plataformas sociales.

Dentro de infraestructura, se divide en tres carteras de trabajo, denominadas «cubos»: Experiencias Wiki; Señales y Servicios de Datos; y Audiencias Futuras. Estas categorías son las mismas que el año pasado y el anterior.

En conjunto, creemos que este plan responde a un momento crucial en la historia de internet, preparándonos para garantizar que los contenidos de conocimiento libre sigan siendo accesibles y moldeados por todas las generaciones. Nuestros objetivos y resultados clave muestran con más detalle la estructura y los contenidos de este plan, y deseamos escuchar preguntas e ideas de la comunidad en general.

Construir, mejorar y mantener la infraestructura alineada con nuestros valores para los proyectos y el voluntariado de Wikimedia

"La Fundación pondrá y mantendrá disponible en internet, de forma gratuita y a perpetuidad, información útil de sus proyectos."


La infraestructura que sustenta los proyectos Wikimedia es un foco constante de inversión para los equipos de Producto y Tecnología, quienes la construyen, mejoran y mantienen durante todo el año. Esta inversión incluye alojar los proyectos, desarrollar software de código abierto y sistemas de diseño, y mantener la infraestructura de productos de datos y modelos de IA.

Parte de nuestro trabajo esencial se centra en los fundamentos del desarrollo y alojamiento de un gran sitio web popular. Alojamos nuestros proyectos Wikimedia en centros de datos, en servidores y hardware que compramos, instalamos y mantenemos, conectados entre sí y con el resto de internet a través de una red de alta velocidad. Controlamos y añadimos capacidad cuando es necesario y renovamos el equipo cuando se queda demasiado viejo. Por ejemplo, este año prevemos ampliar nuestra capacidad y renovar nuestro hardware en nuestros centros de datos de Ashburn, Virginia y Carrollton, Texas.

Diseñamos y desarrollamos software de código abierto (sobre todo MediaWiki). También utilizamos y desplegamos muchas aplicaciones, bibliotecas y marcos de trabajo de código abierto de terceros. Los errores importantes en nuestro software son priorizados y corregidos. El mantenimiento del software de código abierto requiere el trabajo altamente cualificado de personas con experiencia especial en el desarrollo de software de código abierto, ingeniería de fiabilidad de sitios (SRE), gestión de productos, gestión de programas, diseño y mucho más. Nuestro personal trabaja para garantizar que nuestro software y nuestros sistemas estén actualizados y se adapten a un entorno en constante cambio. Esto incluye la modernización de nuestro código para que siga beneficiándose de las correcciones de seguridad y funcione bien con el nuevo software de terceros. Por ejemplo, mediawiki está escrito en PHP, y el año pasado migramos de PHP 7.4 a 8.1, lo que exigió cambios tanto en el código como en la infraestructura donde alojamos nuestros sitios y servicios. Este año nos basaremos en ese esfuerzo y migraremos a la 8.3, aprovechando las lecciones aprendidas y las herramientas desarrolladas en la actualización a la 8.1. La actualización hará que nuestros sistemas sean más rápidos para los lectores, más fáciles de usar para el personal y para el voluntariado, y más seguros para todos/as. También ahorrará tiempo de desarrollo en el futuro gracias a las mejoras de seguridad, rendimiento y asistencia que conllevan las actualizaciones lingüísticas.

Nuestros equipos dedican un esfuerzo considerable a asegurar una alta disponibilidad de nuestros sitios y servicios para garantizar que nuestros proyectos y contenidos sigan estando disponibles en Internet, tanto hoy como a perpetuidad. Uno de los aspectos de este trabajo se centra en la recuperación ante catástrofes o actos malintencionados. Por ejemplo, nos aseguramos de tener copias de seguridad de los datos importantes y de poder recuperarlos. Del mismo modo, dos veces al año comprobamos nuestra capacidad para cambiar de sitio entre nuestros centros de datos de forma automatizada y solucionamos cualquier problema que encontremos. Otro aspecto de este trabajo se centra en identificar y adaptarnos a la evolución de las tendencias en los tipos y volúmenes de tráfico que recibimos. Por ejemplo, con el crecimiento sin precedentes de scrapers ("raspadores") automatizados, estamos dando prioridad al trabajo para garantizar que nuestros sitios y servicios sigan siendo accesibles para los/as usuarios/as humanos/as, adoptando un enfoque sistemático para establecer normas sobre el uso responsable de nuestra infraestructura.

No todo el trabajo se planifica con mucha antelación. También respondemos a hechos o incidentes inesperados, como cortes del sitio, informes o problemas de seguridad, o ataques vandálicos a gran escala contra nuestros proyectos. Supervisamos nuestro rendimiento y los obstáculos a la accesibilidad en todo el mundo, incluidos problemas de conectividad a internet o bloqueos por censura, e investigamos cualquier anomalía que encontramos. Algunos de estos hechos inesperados o patrones repetitivos de problemas dan lugar a que el personal de prioridad a proyectos de seguimiento a corto plazo destinados a mitigar o prevenir por completo nuevos efectos negativos. Por ejemplo, este tipo de esfuerzos fueron cruciales para permitir que nuestros proyectos Wikimedia resistieran los picos de tráfico global debidos a acontecimientos noticiosos importantes - por ejemplo, muertes de celebridades de alto perfil - mediante una combinación de optimización del rendimiento, rediseño arquitectónico de áreas con cuellos de botella y aumentos de capacidad. Del mismo modo, las recientes mejoras en la usabilidad de nuestras herramientas y sistemas de gestión de tráfico que recibimos nos han permitido reaccionar con una mayor rapidez y eficacia a las condiciones cambiantes. Este tipo de trabajo de adaptación es esencial para nuestra capacidad de responder a acontecimientos emergentes, a menudo a corto plazo, y garantizar que nuestros proyectos y contenidos sigan estando disponibles.

Objetivos de Producto y Tecnología

Los objetivos que aquí se presentan son un borrador y están abiertos a comentarios y debate.

  • Los objetivos representan una dirección de alto nivel.
  • Los "resultados clave" (KR) representan una forma cuantificable de medir el éxito de sus objetivos.
  • Las "hipótesis" subyacentes de cada KR representan el trabajo real que estamos realizando para intentar alcanzar los resultados clave asociados. Se irán actualizando en este documento y en las páginas wiki del proyecto o equipo correspondiente a medida que se vayan adquiriendo conocimientos a lo largo del año.
  • wishlist item es para el trabajo al que la Fundación está dando prioridad en el marco de la lista de deseos de la comunidad.

Experiencias wiki (WE)

Experiencias de colaboradores (WE1)

  • Objetivo: Las contribuciones aumentan porque a cada voluntario se le ofrecen oportunidades atractivas y entiende su impacto. Discusión
    • Contexto: Este objetivo será la base de la nueva estrategia para los colaboradores con sus tres pilares: 1) ofrecer a voluntarios una forma centralizada de organizar su actividad en la wiki, 2) proporcionar tareas más pequeñas y discretas para crear más claridad y ayudar a voluntarios a alcanzar su potencial, y 3) hacer que la contribución sea más significativa. En el ejercicio fiscal 25/26, tenemos previsto proporcionar la infraestructura básica para ayudar a voluntarios a organizar su actividad en la wiki de forma centralizada, comenzando con intervenciones centradas específicamente en editores y moderadores experimentados. En los años siguientes añadiremos intervenciones en todas las funciones de los colaboradores e incluiremos más espacios problemáticos. Además, seguiremos invirtiendo en Edit Check y Structured Tasks, construyendo una base sobre cómo utilizar la IA de forma escalable, tanto como guía durante el proceso de edición como para dirigir a voluntarios hacia oportunidades atractivas. Y, por último, invertiremos en hacer más visible el impacto que tienen las personas voluntarias para crear una experiencia más relevante para ellas.
      • artículo de la lista de deseos Resultado clave WE1.1: Aumentar la tasa a la que las personas editoras con ≤100 ediciones acumuladas publican ediciones constructivas en la web móvil [i] en un 4% [ii], de acuerdo con las mediciones de experimentos controlados (para el final de Q2).
        • i. "Ediciones constructivas" = ediciones a páginas en cualquier espacio de nombres Principal de Wikipedia que no sean revertidos en las primeras 48 horas después de haber sido publicadas.
        • ii. T389403#10960480
        • A los nuevos voluntarios les cuesta empezar a editar con éxito. Sobre todo los que utilizan dispositivos móviles, donde el espacio de la pantalla es limitado y la atención suele fragmentarse.
        • Algunos se cansan del contexto, la paciencia y la prueba y error necesarios para contribuir de forma constructiva. Otros aún no han encontrado una oportunidad convincente para intentarlo.
        • WE 1.1 abordará estas cuestiones mediante:
          • Traer a luz sugerencias para editar
          • Ofrecer orientación práctica durante la edición
          • Crear flujos de trabajo de edición más específicos
        • En el centro de estos esfuerzos está la necesidad de contar con formas escalables de detectar cómo podrían mejorarse las ediciones en curso y el contenido existente. Para aumentar esta capacidad, seguiremos experimentando con el aprendizaje automático para aprender cómo puede usarse para servir a las personas editoras en distintos roles y con diferentes niveles de experiencia.
        • Metolodogía propuesta de puntuación del KR: Calcular, para cada plataforma, la proporción de intervenciones desplegadas y evaluadas a través de experimentos controlados que cumplieron o superaron la meta de ediciones constructivas que establecimos al inicio de este año. Véase phab:T379285#10782051 para conocer el razonamiento detrás de esto.
          • Nota: al 30 de junio de 2025, WE 1.1 ya tiene planeados dos experimentos controlados.
      • artículo de la lista de deseos Resultado clave WE1.2: Aumento del número de colaboraciones en las wikis en un 55% interanual al final del cuarto trimestre.
        • A menudo, los colaboradores se esfuerzan por encontrar oportunidades de colaborar entre sí, especialmente en torno a los temas y tareas que les interesan. Esto puede hacer que los recién llegados se sientan solos en las wikis y que los editores experimentados se desgasten. Además, el impacto de las actividades de colaboración a menudo no está claro, lo que puede llevar a que menos personas quieran unirse, organizar o apoyar la colaboración en las wikis.
        • Queremos dejar más claro el valor de la colaboración haciendo lo siguiente:
        1. Crear nuevas formas de compartir el impacto de las actividades de colaboración en las wikis.
        2. Comenzar a recopilar datos de todo el movimiento sobre el impacto de las actividades de colaboración.
        3. Establecer la infraestructura básica para realizar un seguimiento de las contribuciones colaborativas, de modo que podamos ofrecer nuevas formas innovadoras de reconocer y recompensar las contribuciones en el futuro.
        • Las colaboraciones se medirán por las nuevas actividades creadas a través del registro de eventos en la extensión CampaignEvents. El objetivo es que, al final de este KR, tengamos más usuarios de las herramientas de la extensión y nuevas formas de hacer aflorar el impacto de la colaboración. Esto nos situará en una buena posición para conectar nuestra infraestructura existente con otras formas de reconocer y recompensar el trabajo en las wikis (como el módulo de impacto, agradecimientos, etc.).
        • Área de interés de la lista de deseos: Lista de deseos de la comunidad/Áreas de interés/Conexión de colaboradores
      • artículo de la lista de deseos Resultado clave WE1.3: para el final del tercer trimestre, el 10% de aquellos contribuidores a los que se les presentó una página de inicio enfocada hacia los nuevos moderadores la visitaron dos semanas seguidas.
        • Creemos que podemos hacer un mejor trabajo en cuanto a mostrarle al voluntariado las oportunidades de contribución. A largo plazo creemos que una página de inicio puede ser útil para que cualquier persona editora pueda organizar su trabajo, encontrar nuevas oportunidades, y entender el impacto de sus contribuciones. Nuestra meta para el año fiscal 2025/26 es traer a luz nuevas oportunidades para que las personas editoras con mayor experiencia puedan realizar tareas de moderación a las que de otra forma no habrían estado expuestas.
        • Primero probaremos esta teoría entendiendo cuánto participarían las personas editoras experimentadas con una página de inicio similar a la que tienen las cuentas nuevas.
        • Luego, les presentaremos actividades específicas de moderación (los detalles están por determinarse) a personas novatas a ese tipo de acciones de moderación, con el objetivo de ayudar a reducir la carga sobre otras personas editoras más experimentadas mediante la reducción de sus colas de trabajo (bajo un nuevo KR).
        • Si el concepto de la página de inicio es exitoso, planeamos hacer a esta página modular para atender las necesidades específicas de las comunidades. Estos módulos podrían incluir cosas tales como el facilitarle a las personas editoras entender su impacto.
        • Notas sobre la metodología:
        • Tendremos una hipótesis para definir nuestra audiencia, que será parte de WE1.3.1.
        • La definición de «Moderadores» se ajustará a la definición iniciada en Research:Develop a working definition for moderation activity and moderators, aunque se necesitará un trabajo de seguimiento para acotar más la definición cuantitativa.
        • La segunda semana será definida relativa al momento de la primera visita de cada persona usuaria. En este caso, revisaríamos a todas las nuevas personas moderadoras que visitaron la página de inicio durante un período de tiempo específico y después realizaron una visita más tarde (7 a 14 días después).
        • Área de interés de la lista de deseos: Lista de deseos de la comunidad/Áreas de interés/ Priorización de tareas
      • artículo de la lista de deseos Resultado clave WE1.4: mejorar el porcentaje de visitantes únicos a listas de seguimiento y/o cambios recientes que hacen clic para ver una edición.
        • Nuestro objetivo es ayudar a las personas que tienen más de 100 ediciones a encontrar y abrir ediciones que les interesen con mayor eficiencia. Exploraremos el área de interés de priorización de tareas, cumplir con algunos deseos de esta área, y solicitaremos retroalimentación adicional del voluntariado acerca de cómo mejorar estas interfaces. Nuestro éxito se medirá en cuanto a medir la eficacia de cada página para "encontrar trabajo", definida como la métrica indicatriz de tasa de click-through.
      • Resultado clave WE1.5: Definir y poner en operaciones siete métricas prioritarias [1] necesarias para monitorear el progreso hacia el cumplimiento de las metas detalladas en la estrategia del contribuidor para el final del cuarto trimestre, mediante la creación de un dashboard y poner en operación las métricas de Moderadores Activos Mensuales.
        [1] Personas editoras retenidas,activación constructiva, ediciones constructivas, cuentas registradas, personas nuevas retenidas, personas editoras activas por antigüedad, personas editoras activas por nivel de experiencia.
        • La estrategia de experiencia del contribuidor tiene como visión un esfuerzo de 3-5 años para "impulsar el crecimiento del voluntariado" y "aumentar la retención y activación" de contribuyentes tanto nuevos como existentes a través de tres áreas principales de actividades:
        1. Optimizar cómo pueden las personas voluntarias recibir recomendaciones, gestionar sus tareas e intereses, ver qué pasa en las wikis, y entender su impacto.
        2. Ofrecer tareas adecuadamente estructuradas para crear más claridad y ayudar a las personas voluntarias a alcanzar su potencial mediante la optimización de los flujos de trabajo a los que les enviamos, incluyendo una inversión continua en el ofrecimiento de orientación estructurada y la automatización de tareas repetitivas, con énfasis especial en la experiencia web móvil.
        3. Hacer que las contribuciones sean significativas al mostrar a las personas voluntarias su impacto e invertir en vías que faciliten la conexión humana y un entorno basado en retroalimentación positiva.
        • Un proyecto de estrategia de medición trazó una red extensa de métricas para rastrear esta teoría del cambio. Su conclusión fue que la medida primaria de éxito ("métrica central") debería ser un conteo de retención de personas editoras, complementada por métricas más acotadas de indicadores como la activación constructiva y las intenciones de los contribuyentes de regresar, así como métricas posteriores más amplias como personas editoras activas y calidad de los contenidos. Necesitamos asegurar que estas métricas estén operativas y visibles en un panel (dashboard) para poder rastrear nuestro progreso hacia la ejecución de la estrategia.
      • Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
        • Our goal is to help editors with 100+ edits to more efficiently find 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.
      • Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
        [i]         Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
        Guardrail:         No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
        • 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
        • WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
      • Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
        • Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
        • This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
        • We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
      • Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
        • Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
        • Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
        • Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
      • Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
        • The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Conocimientos Vitales (WE2)

  • Objetivo: Hacer que el conocimiento vital esté disponible y bien ilustrado en todas las lenguas y temas. Discusión
    • Contexto del objetivo: Este objetivo impulsará un crecimiento de contenidos que responda tanto a los intereses de los colaboradores en temas e idiomas concretos como a la demanda de los lectores de conocimientos vitales bien ilustrados. El conocimiento vital es un conjunto de artículos que ofrece la amplitud y profundidad de temas necesarios para un proyecto lingüístico de Wikipedia utilizable. Las comunidades lo definen en función de la notabilidad, la relevancia, el número de lectores previstos y las conexiones entre artículos.
    • Adoptaremos un enfoque sociotécnico para mejorar la eficacia de las funcionalidades, las herramientas y los procesos sociales. Nos basaremos en las funcionalidades de alto impacto del producto, como las tareas sugeridas, la búsqueda de medios y la traducción de contenidos, pero también facilitaremos la incorporación y el desarrollo de Wikipedias en idiomas más pequeños. Apoyaremos a los organizadores de Wikimedia que reclutan, forman y apoyan a los colaboradores para que trabajen en objetivos de contenido compartidos a través de configuraciones colaborativas como WikiProyectos y campañas. (Calculamos que al menos 300 organizadores están activos cada trimestre.) También desarrollaremos relaciones con los editores más relevantes para eliminar las barreras a los materiales fuente. (En la actualidad tenemos acuerdos de colaboración con más de 100 de las principales bases de datos del mundo que requieren suscripción).
    • Para asegurarnos de que nuestras intervenciones tienen un impacto positivo en el conocimiento esencial, mediremos tanto el aumento de contenidos prioritarios para la comunidad como la calidad de esos contenidos, atendiendo a factores como los índices de reversiones y el número de citas e imágenes.
      • Resultado clave WE2.1: Para finales del segundo trimestre, experimentar y evaluar 3 intervenciones que ayuden a las personas que contribuyen a mejorar el estado de los contenidos vitales en sus Wikipedias.
        • Este KR pondrá de relieve las lagunas de contenido dentro de los mecanismos de edición, como el descubrimiento de imágenes en Wikipedia, la traducción de contenidos y la creación guiada de nuevos artículos. También pondremos en práctica y probaremos una intervención sociotécnica para apoyar la actividad de creación de contenidos para pequeñas comunidades lingüísticas. El éxito se medirá dentro de cada hipótesis.
      • Resultado clave WE2.2: Para el final del cuarto cuatrimestre, construir las capacidades que la plataforma necesita para validad que podemos apoyar la visión de Abstract Wikipedia a gran escala. Sabremos que tuvomos éxito si mostramos que el sistema es capaz de producir contenidos enciclopédicos nutridos y multilingües usando Wikidata y generación de lenguaje natural, que está controlado por la comunidad Wikimedia, y que se mantiene funcional en lanzamientos sucesivos amplios.
        • Ahora que podemos usar Wikidata para producir contenidos básicos y en texto plano en las Wikipedias, el paso siguiente es continuar construyendo capacidades de la plataforma que puedan ayudar a Abstract Wikipedia a gran escala. La plataforma deberá apoyar contenidos ricos y multilingües que puedan ser controlados por la comunidad, y debe mantenerse funcional a gran escala. Este es un KR hito a medida que vamos de 0 a 1.
      • Resultado clave WE2.3: para el final del cuarto trimestre, lanzar una forma inicial de la nueva wiki para que la comunidad pueda crear de forma temprana artículos en Abstract.
        • Este KR nos prepara para probar las capacidades de la plataforma de Abstract el próximo año. La nueva wiki independiente alojará la biblioteca de artículos abstractos construidos a partir de Wikifunciones, y proporcionará a la plataforma las capacidades para integrar artículos abstractos en Wikipedia en el futuro.
      • Resultado clave WE2.4: Alinear a la WMF y WMDE sobre la definición de éxito para las mejoras a la infraestructura técnica que apoyan un caso de uso crítico de Wikidata para el final del segundo trimestre. Esto incluye métricas y objetivos para el año fiscal 2025-26.
        • El equipo de Plataforma de Wikidata de la Fundación Wikimedia (WDP por sus siglas en inglés) fue establecido en agosto de 2025 con un solo Líder de producto y un Líder tecnológico como su personal. Este objetivo, al ser una nueva adición a un programa con años de desarrollo técnico por parte de los dueños técnicos y de producto en la WMF y WMDE respectivamente, refleja nuestra intención de transicionar la propiedad a través del alineamiento sobre los casos de uso, dependencias y criterios clave del éxito. Este KR constituirá la base del entendimiento mutuo del espacio de problemas, sobre el que construiremos durante el resto del año fiscal (mayo 2026).
      • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
        • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Experiencia de consumidores (WE3)

  • Objetivo: Las personas lectoras de varias generaciones se involucran y mantienen dicho involucramiento con Wikipedia, lo que conduce a aumentos cuantificables en la retención y las donaciones. Discusión
    • Contexto del objetivo: Este objetivo se centrará en retener a los nuevos lectores a través de formatos de contenido innovadores, a las audiencias principales mediante el refuerzo de experiencias de lectura familiares, y en garantizar la sostenibilidad a largo plazo profundizando en las conexiones con los lectores y diversificando las donaciones. Este objetivo incluirá la continuación de nuestro trabajo para facilitar el descubrimiento de contenidos a través de funciones nuevas y más experimentales, como los resúmenes de inteligencia artificial o los wikiagujeros de conejo personalizados. También se trabajará para mantener y mejorar la calidad de la experiencia de lectura en los niveles más profundos del proceso de lectura y para explorar la selección de lecturas a través de listas de lectura y otras formas de participación no editorial. Para los donantes, este trabajo seguirá centrándose en diversificar las fuentes de ingresos desde dentro de la plataforma.
      • elemento de la lista de deseos Resultado clave WE3.1: A finales del segundo trimestre, demostrar un aumento significativo en gran medida en la retención de lectores sin sesión iniciada, medido a través de pruebas A/B de una función por plataforma.
        • Este KR se centrará en seguir invirtiendo en experiencias que optimicen las nuevas formas de navegar y adquirir contenidos, a menudo mediante el uso de nuevas tecnologías y formatos, presentando los contenidos existentes de formas nuevas y atractivas. En este plan anual, nos gustaría seguir experimentando con nuevas características, al tiempo que nos centramos en la ampliación de experimentos exitosos a través de wikis y plataformas. El trabajo en el KR abarcará el sitio web móvil y de escritorio, así como las aplicaciones para iOS y Android, y se centrará en el descubrimiento de contenidos (puntos de entrada de navegación y recomendaciones) y formatos de aprendizaje adaptables (resúmenes asistidos por máquinas, remezcla de contenidos).
        • Área de interés de la lista de deseos: nuevas experiencias de consumo
      • Resultado clave WE3.2: aumentar el número de donaciones a través de métodos que no sean banners ni correo electrónico en un 5% interanual por plataforma mediante intervenciones de productos que fomenten conexiones más profundas y reduzcan la fricción para los y las donantes para fines del segundo trimestre
        • Este KR nos permitirá seguir explorando nuevos puntos de entrada para las donaciones y otras oportunidades para convertir a lectores en donantes y retenerlos mediante la profundización de sus conexiones con las wikis, incluido un contenido más personalizado. El KR se centrará en introducir nuevos puntos de entrada e iterar sobre los puntos de entrada existentes en aplicaciones y web, en colaboración con el equipo de recaudación de fondos.
      • Resultado clave WE3.3: A finales del segundo trimestre, demostrar un aumento significativo en la retención de lectores con sesión iniciada medido a través de pruebas A/B de una función por plataforma.
        • Este KR se centrará en mejorar la experiencia de lectura y aprendizaje para los lectores existentes y experimentados, con el objetivo de retener a nuestra audiencia actual y profundizar su conexión con el sitio para que puedan aprender más, así como estar listos y abiertos a tomar caminos hacia la donación y la edición. El trabajo aquí se centrará en mejorar la experiencia de lectura en la web y las aplicaciones (mejoras de legibilidad, mejor navegación y descubrimiento), así como en desarrollar e iterar sobre nuestras ofertas de curación y personalización (listas de lectura, sugerencias personalizadas, historial de usuarios y artículos, etc.).
      • Resultado clave WE3.4: Para el final del cuarto trimestre, eliminar todos los obstáculos identificados a los despliegues de sitios de cache de escala pequeña (PoPs) cumplan con nuestros estándares actuales de calidad de servicio y seguridad según nuestros despliegues actuales de sitios de almacenamiento en caché
        • Este KR se centrará en probar el concepto de que podemos mejorar el rendimiento del sitio web y reducir la latencia para nuestros lectores simplificando nuestra infraestructura de almacenamiento en caché y mejorando los procesos para el despliegue de un sitio de almacenamiento en caché reduciendo el tiempo de despliegue de referencia de aproximadamente un año de media a un trimestre como máximo. Aquí nos centraremos en completar la simplificación, desplegar una PoC, llevar a cabo una revisión de seguridad y completar un informe de decisión sobre si proceder con el despliegue de nuestras cachés de borde en nubes públicas. Disminuir la latencia puede conducir a un aumento probado de las páginas vistas y a una base de lectores más diversa geográficamente.
      • Resultado clave WE3.5: mejorar la identificación de los donantes, garantizando que todos los/as lectores/as registrados/as que consienten puedan ser identificados/as por estado de donante para una experiencia personalizada, para el final del cuarto trimestre.
        • Pondremos en marcha estrategias de identificación de donantes para garantizar que todas las personas que hayan iniciado sesión - y que así lo consientan - puedan ser identificadas por su condición de donantes, lo que permitirá una experiencia más personalizada y atractiva. Los esfuerzos de identificación de donantes se priorizarán durante el cuarto trimestre para apoyar iniciativas de personalización y activación más eficaces en el futuro.
      • Resultado clave WE3.6: Finalizar, publicar y comunicar una estrategia para la experiencia del lector y consumidor de Wikipedia en todas las plataformas para finales del cuarto trimestre, con objetivos definidos y métricas de referencia, desarrollada en colaboración con las partes interesadas y la comunidad, para guiar nuestro trabajo hasta 2030
        • Se seguirá trabajando en la estrategia para las personas consumidoras, centrándose en construirla y comunicarla internamente, así como con la comunidad, y definiendo y estableciendo parámetros básicos para los consumidores, con sus respectivas bases de referencia.
      • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
        • 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.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
        • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
      • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
        • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
      • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
        • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Confianza y Seguridad (WE4)

  • Objetivo: Nuestros sistemas protegen mejor por defecto las cuentas y la información privada de nuestros editores, al tiempo que ofrecen más vías a editores y usuarios con permisos extendidos para prevenir y responder a actividades abusivas. Discusión
  • Resultado clave WE4.1: Desplegar un sistema de notificación de incidentes viable y operativo en todas nuestras wikis, que sea utilizado y aceptado por sus comunidades, para finales del segundo trimestre.
    • Garantizar la seguridad y el bienestar de nuestra plataforma es una responsabilidad fundamental de los usuarios. Muchas jurisdicciones cuentan con normativas que obligan a plataformas en línea como la nuestra a vigilar y tomar medidas contra el acoso, el ciberacoso y otros contenidos nocivos en su plataforma. No hacer frente a estos problemas puede exponer a las plataformas a responsabilidades legales y sanciones reglamentarias.
    • Queremos capacitar a nuestros usuarios para que puedan informar de amenazas inmediatas de daño a través de un mecanismo de denuncia fácil de encontrar e intuitivo para asegurarnos de que somos capaces de aprender acerca de tales incidentes y tomar medidas rápidas cuando sea necesario. Es un paso más para que nuestros usuarios se sientan seguros cuando contribuyen a nuestra plataforma. Para ello, hemos implantado un sistema de notificación de incidentes en nuestras wikis.
  • Resultado clave WE4.2: Reforzar la precisión y eficacia de las herramientas antiabuso, implementando 2 mejoras para finales del segundo trimestre.
    • Para la comunidad, así como nuestro equipo, nos es necesario detectar mejor y prevenir la actividad no auténtica y maliciosa en las wikis. Para ello, aumentaremos el número y la calidad de las señales de las que dispone la plataforma, combinaremos estas señales en herramientas que pondremos a disposición de los usuarios con permisos extendidos e identificaremos los casos en los que podemos imponer restricciones automatizadas a la actividad sospechosa de forma segura.
    • También vemos oportunidades de mejorar la accesibilidad de Wikipedia y de nuestros otros proyectos al mismo tiempo. Por ejemplo, un proyecto consiste en sustituir el CAPTCHA autogestionado de las wikis, muy convencional, que impide al usuario iniciar sesión hasta que resuelve un enigma, por un servicio de puntuación de riesgos que rara vez desafía al usuario. En su lugar, etiquetaría silenciosamente las cuentas con un nivel de sospecha que podemos utilizar para deshabilitar la funcionalidad, y haría visible este estado a moderadores muy privilegiados para ayudarles en su trabajo.
    • En términos más generales, los proyectos Wikimedia se basan en gran medida en el bloqueo de direcciones IP para mitigar el abuso de los malos actores. Esto es cada vez más ineficaz para detener el abuso y afecta negativamente a los usuarios de buena fe que se ven afectados por los bloqueos de IP y de rango de IP. En este resultado clave, nuestro objetivo es mejorar las capacidades existentes y ofrecer nuevas herramientas que permitan un bloqueo más preciso y eficaz de los malos actores, y disminuir los daños colaterales causados por los bloqueos de IP y de rango de IP.
    • Para medir nuestra eficacia, analizaremos los comentarios cualitativos de las personas voluntarias que trabajan en la lucha contra el abuso, e indicadores cuantitativos como la tasa de bloqueos de IP que se están desplegando, la adopción de la reputación de la IP y mitigación basada en señales de navegador, la tasa de interacciones probables entre humanos cuando un usuario es bloqueado, y la adopción del nuevo sistema de herramientas contra el abuso.
    • El trabajo en este resultado clave incluye la mejora de la detección y mitigación de la evasión de prohibiciones y de los títeres, la difusión de información sobre el potencial de daños colaterales, el refuerzo de la detección de bots, la difusión de señales a las personas voluntarias en contra del abuso, la mejora de la eficacia de las interfaces de las herramientas en contra del abuso, la mejora de las métricas relacionadas con el abuso y la presentación de sugerencias de actividades de cuentas sospechosas para su investigación a CheckUsers.
  • Resultado clave WE4.3: Reducir el número de ataques a gran escala que requieren la intervención de personas en un 50% (en comparación con el año anterior), para el final del cuarto trimestre
    • La evolución del panorama de Internet, incluido el surgimiento de botnets a gran escala y de ataques más frecuentes, ha dejado obsoletos nuestros métodos tradicionales para limitar los abusos a gran escala. Estos ataques pueden hacer que nuestros sitios no estén disponibles al inundar nuestra infraestructura de peticiones, o desbordar la capacidad de nuestra comunidad para combatir el vandalismo a gran escala. Esto también supone una carga excesiva para nuestros editores con privilegios elevados y nuestra comunidad técnica.
    • Necesitamos urgentemente mejorar nuestra capacidad para detectar, resistir y mitigar o detener automáticamente estos ataques.
    • Este año nos centraremos sobre todo en automatizar la detección de direcciones IP y redes que nos atacan con regularidad, y en reducir la carga que esas entidades persistentemente dañinas pueden imponer a nuestros sistemas.
  • Resultado clave WE4.4: Para el segundo trimestre, las cuentas temporales se habrán desplegado en el 100% de nuestros proyectos, de forma que la exposición de información personal identificable de nuestros editores no registrados esté disponible para menos del 0,1% de los usuarios registrados, para el final del segundo trimestre.
    • El objetivo de las cuentas temporales es mejorar la privacidad y, por tanto, la seguridad de nuestros editores no registrados, protegiendo su información personal (dirección IP) de la vista del público y limitando el acceso únicamente a quienes lo necesiten con fines de patrullaje. Además de suponer una importante mejora de la seguridad de los usuarios, este proyecto también es relevante para cumplir diversos requisitos normativos.
  • Resultado clave WE4.5: Llevar a cabo y publicar una evaluación de riesgos y oportunidades para la confianza y la seguridad, identificando las amenazas y oportunidades potenciales, junto con las estrategias de mitigación o adopción recomendadas para los proyectos Wikimedia, para el final del tercer trimestre
    • El uso de la IA, y en particular de la IA generativa, está aumentando rápidamente en Internet. Con la omnipresencia de la IA surgen oportunidades y amenazas para la confianza y la seguridad. Por ejemplo, es más fácil y barato generar contenidos, pero la moderación es más ardua. Del mismo modo, la investigación puede llevarse a cabo con mucho menos esfuerzo, pero las alucinaciones de la IA son más difíciles de identificar.
    • Este proyecto se basa en la Evaluación del Impacto de la Inteligencia Artificial y Aprendizaje Automático (Machine Learning) en los Derechos Humanos, evaluando el impacto de la Inteligencia Artificial en los aspectos de confianza y seguridad del ecosistema de Wikimedia. Esto incluye:
      • Consulta con usuarios con permisos extendidos.
      • Identificación de ejemplos de abuso asistido por IA generativa y posibles mitigaciones.
      • Identificar oportunidades de aprendizaje automático para disminuir la carga de los usuarios con permisos extendidos.
      • Realización de experimentos para saber en qué debemos centrarnos para lograr el mayor impacto.
  • Resultado clave WE4.6: Imponer técnicamente que el 100% de los privilegios que permiten a los usuarios realizar acciones sensibles desde el punto de vista de la seguridad o la privacidad sólo puedan ser ejecutados por cuentas que hayan habilitado la autenticación de dos factores, para finales del cuarto trimestre.
    • Tenemos que reforzar la seguridad de las cuentas de usuario en nuestras wikis, en particular para los usuarios con permisos sensibles. Un objetivo clave es exigir que cualquier acción sensible solo pueda ser realizada por usuarios que hayan activado la autenticación de dos factores (2FA). Construiremos un sistema más extensible para la implementación eficiente del acceso que evitará la necesidad de auditorías y la aplicación manual de 2FA, y ampliaremos qué privilegios requieren que 2FA esté habilitado en la plataforma.
    • Como parte de esto, vamos a mejorar nuestros sistemas de autenticación y recuperación para que el equipo (WMF) y nuestros usuarios podamos apoyar más fácilmente una postura más estricta hacia el 2FA. Ampliaremos la disponibilidad general de la autenticación de dos factores en toda la plataforma, para que todas las personas puedan activarla cuando lo deseen y para garantizar que se activa antes de conceder privilegios sensibles. También centraremos nuestra atención en reducir la carga operativa que soportan nuestros sistemas de recuperación y asistencia de cuentas, ayudando a racionalizar nuestros procesos de restablecimiento y recuperación en torno al inicio de sesión de cuentas. Además, tenemos la intención de mejorar la facilidad de uso de nuestra aplicación 2FA, ofreciendo a los usuarios más opciones para proteger sus cuentas y evitar bloqueos accidentales.
  • Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
    • This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
  • Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
    • The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
      We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
  • Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
    • For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
  • Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
    • In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
  • Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
    • We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
    • This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
    • During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
  • Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
    • We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
    • In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
    • We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Uso responsable de las infraestructuras (WE5)

  • Objetivo: Desarrolladores y reutilizadores acceden a contenidos de conocimiento en vías curadas, garantizando la sostenibilidad de nuestra infraestructura y la reutilización responsable de contenidos. Discusión
    • Contexto del objetivo: Este objetivo se centrará en el establecimiento de vías para la reutilización responsable de contenidos.
    • Wikimedia alberga la mayor colección de conocimientos de la red, recopilados por seres humanos. Esto ha convertido nuestra infraestructura de conocimiento en un destino inestimable no solo para los humanos, sino también para los consumidores automáticos de datos. Nuestro contenido alimenta motores de búsqueda, plataformas de redes sociales, comercio electrónico y, desde el auge de la IA, se utiliza para entrenar grandes modelos de aprendizaje automático. Los consumidores se abastecen de datos mediante páginas scraping, utilizando las API y descargando contenidos, normalmente sin atribución. En el mundo del tráfico no autenticado no podemos diferenciar de forma fiable a un usuario de otro, lo que limita enormemente nuestra capacidad para permitir y hacer cumplir un uso responsable de nuestra infraestructura: ¿Cómo podemos seguir facilitando el acceso a nuestra comunidad y, al mismo tiempo, poner límites al consumo automático de contenidos? ¿Cómo podemos canalizar a los usuarios hacia los canales preferidos y compatibles? ¿Qué orientación necesitamos para incentivar la reutilización responsable de contenidos? ¿Cómo podemos impulsar una experiencia cohesiva para los desarrolladores y crear productos que satisfagan las necesidades de los desarrolladores voluntarios, el personal y los reutilizadores por igual? Aunque todas estas preguntas no son nuevas, la urgencia de abordarlas ha crecido exponencialmente: Desde 2024 estamos observando un aumento espectacular del volumen de solicitudes, la mayor parte del cual procede de bots de scraping que recopilan datos de entrenamiento para flujos de trabajo y productos impulsados por IA. La carga que soporta nuestra infraestructura no es sostenible y pone en peligro el acceso humano al conocimiento: Tenemos que actuar ahora para restablecer un equilibrio saludable, para que podamos apoyar eficazmente los proyectos Wikimedia y permitir el éxito sostenido de nuestra misión.
      • Resultado clave WE5.1: A finales del cuarto trimestre, el 50% de las solicitudes a los canales de acceso programático pueden atribuirse a un desarrollador o aplicación conocidos.
        • Actualmente disponemos de medios limitados para identificar a los responsables del tráfico automatizado y, a diferencia de lo que ocurre en la wiki, para contactar con los usuarios o regular su acceso. Hemos observado un aumento significativo del volumen de tráfico automatizado externo, lo que no es sostenible para nosotros y pone en peligro el acceso humano al conocimiento. Nuestro objetivo es aumentar el porcentaje de tráfico automatizado que se atribuye a una cuenta conocida, exigiendo autenticación y autorización basadas en niveles de acceso para el scraping de gran volumen y el uso de la API. Esto nos ayudará a identificar quién está reutilizando contenidos a gran escala, lo que nos permitirá proteger nuestra infraestructura y mejorar la gobernanza en torno al uso justo, al tiempo que satisfacemos sus necesidades con mayor eficacia. También estudiaremos cómo apoyar mejor a la comunidad técnica con una experiencia de desarrollo más cohesionada que proteja el acceso preferente de los miembros de la comunidad y permita nuevas funciones a los desarrolladores.
      • Resultado clave WE5.2: A finales del cuarto trimestre, el 70% de los puntos de acceso finales de la API web de Wikimedia estarán respaldados por una infraestructura común.
        • Nuestro objetivo es mejorar la experiencia y la sostenibilidad de nuestros caminos de desarrollo ofreciendo API web más consistentes, estables y descubribles para todos los desarrolladores de Wikimedia. Simplificaremos nuestras ofertas de API introduciendo una infraestructura más centralizada para las capacidades de API básicas, lo que nos permitirá tener caminos y gobernanza consistentes para: especificaciones y documentación de OpenAPI, identificación y control de acceso de desarrolladores, aplicación de políticas de API, enrutamiento, versión y manejo de errores. Al agilizar nuestras ofertas de API, haremos que sea más rápido, más fácil y más agradable construir herramientas, bots, proyectos de investigación y características que sirvan a la misión de Wikimedia. Este enfoque apoya el futuro de la misión de varias generaciones mediante la reducción de los costos de mantenimiento de la infraestructura de API, el aumento de la visibilidad y el control de acceso para combatir a los malos actores y el fomento de una comunidad de desarrolladores más fuerte.
      • Resultado clave WE5.3: A finales del cuarto trimestre, se publicarán y enlazarán nuevos marcos de atribución para la web, las aplicaciones, los asistentes de voz y los modelos de lenguaje en todos los sitios Wikimedia, con dos demostraciones de reutilización desplegadas que impulsen un compromiso medible y un socio de reutilización externo que adopte las mejores prácticas de atribución.
        • Para aumentar la atribución adecuada de los contenidos de Wikimedia, proporcionaremos una guía clara de las mejores prácticas que promueva el uso responsable. Esto incluye crear marcos de atribución para plataformas clave (web, aplicaciones, voz, multimedia) y mostrar al menos dos ejemplos prácticos que destacan aplicaciones ejemplares de contenido de Wikimedia. Ejemplos de resultados incluyen alentar a las organizaciones de medios a acreditar imágenes de Wikimedia Commons, los motores de búsqueda para mostrar los datos relevantes de Wikimedia de manera más efectiva, o los asistentes de IA para integrar el conocimiento de Wikipedia de manera transparente y responsable que aumenta la confianza en su fiabilidad. Fortalecer las prácticas de atribución no solo aumenta la conciencia pública e impulsa el compromiso de nuevo a los proyectos de Wikimedia, sino que también ayuda a establecer formas responsables y novedosas de remezclar el conocimiento y disuadir el uso indebido.
      • Resultado clave WE5.4: Reducir la cantidad de tráfico generado por los scrapers en un 20% cuando se mide en términos de tasa de solicitud, y en un 30% en términos de ancho de banda
        • El scraping siempre ha estado aquí: los motores de búsqueda han confiado en Wikipedia para proporcionar información a sus usuarios durante décadas; sin embargo, últimamente hay otra gran motivación para raspar nuestros datos: es el mayor conjunto de contenido de conocimiento curado y multilingüe que se puede encontrar en Internet y es una herramienta fundamental para entrenar modelos de IA de idiomas grandes. Esto es cierto tanto para nuestro contenido enciclopédico como para nuestro repositorio multimedia, Wikimedia Commons, que es invaluable para los modelos de aprendizaje automático que generan imágenes.
        • Como consecuencia, durante el último año, hemos visto un aumento significativo en la cantidad de tráfico de rastreadores, y también en los incidentes relacionados con la estabilidad del sitio: los ingenieros de confiabilidad del sitio han tenido que hacer cumplir en una tasa de caso a caso que limita o prohíbe a los rastreadores repetidamente para proteger nuestra infraestructura. El scraping se ha vuelto tan prominente que nuestro ancho de banda saliente ha aumentado en un 50% en 2024. Además, un análisis reciente mostró que al menos el 65% de nuestras solicitudes más caras (las que no podemos servir desde nuestros servidores de caché y que se sirven desde las bases de datos principales) son realizadas por bots.
        • Nuestros recursos informáticos son extremadamente limitados en comparación con la cantidad de tráfico que generamos, por lo que tenemos que priorizar a quién servimos con esos recursos, y queremos favorecer el consumo humano, y priorizar el apoyo a los proyectos y colaboradores de Wikimedia con nuestros escasos recursos.

Acelerar el camino hacia los resultados del producto (WE6)

  • Objetivo: Los desarrolladores de Wikimedia entregan sus productos a los usuarios finales de manera rápida y segura. Discusión
    • Contexto de objetivo: Para alcanzar eficazmente los cuatro pilares estratégicos, los desarrolladores de Wikimedia deben dedicar tiempo y esfuerzo a actividades de alto impacto que permitan entregar productos de calidad lo antes posible. Los flujos de trabajo excesivamente complejos, la falta de herramientas estándar y los componentes del sistema insostenibles impiden estos resultados.
    • Este trabajo se basa en el impulso que hemos recogido en los últimos 2 planes anuales que evolucionan MediaWiki como plataforma y el software que apoya su desarrollo e implementación. El trabajo de este año se centrará en proporcionar entornos de desarrollo más fiables, simplificar los flujos de trabajo de pre-producción y reducir los riesgos de las plataformas e infraestructuras.
      • Resultado clave WE6.1: Al final del cuarto trimestre, la cantidad de errores que logran pasar de las wikis de prueba se reduce en un 10%
        • En 2024, los desarrolladores tuvieron que revisar su trabajo 144 veces debido a una emergencia que impidió la implementación de MediaWiki. En muchos de esos casos, los errores se detectaron después de la implementación en wikis de prueba, lo que significa que el problema llegó a una audiencia potencial de miles de millones de usuarios. No podemos controlar la existencia de errores, pero detectarlos antes reduciría el trabajo de los desarrolladores. Además, generaría confianza en los desarrolladores de que, cuando algo pase a producción real, no habrá un problema.
        • Detectaremos estos errores con mayor antelación al proporcionar los entornos que necesitan los desarrolladores para entregar y probar su código con confianza durante todo el ciclo de desarrollo e implementación. También debemos asegurarnos de que estas mejoras no afecten la velocidad del desarrollador.
      • Resultado clave WE6.2: Al final del cuarto trimestre, se pueden ejecutar 4 pasos de la lista de verificación de revisión de preparación para la producción sin la intervención de SRE
        • La implementación de un nuevo servicio o función en la producción depende actualmente de una lista de 24 pasos para los que cada paso normalmente necesita el apoyo de los SRE. Hemos establecido el programa de embajadores de SRE para intervenir más temprano en el ciclo de desarrollo y construir capacidad dentro de los propios equipos de desarrollo, pero muchas de las tareas deben ser totalmente autoservicibles. Actualmente, esto equivale a un trabajo manual, repetitivo, automatizable y que se escala linealmente con el número de equipos de desarrollo. Esto no es sostenible para el equipo de SRE a largo plazo.
        • Anteriormente, gran parte de este trabajo se delegaba en los equipos de desarrollo mediante el mantenimiento de un conjunto de bibliotecas comunes compartidas y mejores prácticas para interactuar con nuestra plataforma. Estas se abandonaron al migrar a nuestra nueva infraestructura de Kubernetes y no tienen un sustituto directo. Al proporcionar bibliotecas, documentación y capacitación similares que se aplican a la forma en que desarrollamos e implementamos actualmente, creemos que podemos reducir la participación necesaria de SRE antes de implementar un nuevo servicio o funcionalidad en producción.
      • Resultado clave WE6.3: Al final del cuarto trimestre, el 100% de las visitas a las páginas de Wikipedia se atienden a través de Parsoid
        • Parsoid ofrece capacidades mejoradas para la evolución del wikitexto y la preparación de la plataforma para el futuro. Mantener dos analizadores simultáneamente no es sostenible a largo plazo, ya que aumenta la deuda técnica y la complejidad. Además, el éxito de algunos proyectos nuevos como wikifunciones depende de la amplia disponibilidad de Parsoid.
        • Hemos estado ampliando el despliegue a proyectos más pequeños y este año estaremos listos para las Wikipedias. Servir a todas las lecturas de la página de Wikipedia a través de Parsoid es el próximo hito más importante. Además del lanzamiento en sí, este trabajo también incluye la resolución de problemas de rendimiento y la comunicación efectiva sobre el impacto a los lectores y editores.
      • Resultado clave WE6.4: Al final del segundo trimestre, al menos dos riesgos identificados que amenazan nuestra capacidad de seguir implementando o ampliando las wikis se han mitigado o reducido a un nivel aceptable
        • A través de algunas iniciativas específicas, reduciremos o mitigaremos varios riesgos de escalabilidad, fiabilidad o seguridad que hemos identificado como una amenaza potencial probable para el crecimiento y la sostenibilidad de nuestra plataforma y nuestros proyectos públicos.
        • Por ejemplo, refactorizaremos la estructura de las bases de datos principales de Commons para garantizar que su crecimiento no se vea limitado por la capacidad del hardware de servidor disponible en los próximos años. También actualizaremos PHP, el lenguaje de programación que impulsa MediaWiki y los servicios relacionados, a una versión más moderna. Otros riesgos identificados probablemente requerirán la implementación de medidas de seguridad adicionales para proteger y fortalecer nuestra infraestructura.
      • Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
        • One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
        • Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
        • With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
        • Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
      • Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
        • Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
        • To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
        • By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
      • Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
        • Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Servicios de señales y datos (SDS)

Métricas (SDS1)

  • Objetivo: Los responsables de la toma de decisiones utilizan métricas más confiables y oportunas para fundamentar las decisiones estratégicas y sobre productos. Discusión
    • Contexto objetivo: utilizamos métricas para fundamentar las decisiones de la Fundación sobre dónde enfocar nuestros esfuerzos para servir mejor al movimiento. Sin embargo, algunos de nuestros flujos de datos son propensos a fallar, lo que provoca retrasos en la entrega. Cuando surgen problemas con los datos, nuestro tiempo de identificación y resolución es demasiado largo. Además, muchos de nuestros conjuntos de datos no están optimizados para una fácil exploración de tendencias y carecen de dimensiones que se han revelado importantes para la interpretación de los datos. Estos problemas ralentizan y limitan nuestra capacidad para evaluar las métricas.
    • En el año fiscal 2025-26, nos centraremos en casos de uso específicos del plan anual para resolver las brechas de calidad en nuestras actuales canalizaciones de datos, establecer infraestructura y procesos para monitorear y resolver problemas de calidad de datos y brindar herramientas que permitan a los tomadores de decisiones comprender las tendencias.
    • Uno de los casos de uso se refiere a cómo medimos el tráfico humano y el de bots. El aumento del tráfico automatizado en los últimos años ha dificultado la comprensión del grado en que los seres humanos interactúan y contribuyen a los proyectos Wikimedia. Nuestro objetivo es mejorar nuestra capacidad para evaluar los patrones de tráfico humano y de bots, que son datos fundamentales para la planificación y la toma de decisiones sobre productos.
      • Resultado clave SDS1.1: Al final del primer trimestre, los analistas que utilizan métricas de visitas a la página tienen acceso a medidas de referencia de calidad de datos y medidas de rendimiento de las heurísticas de detección de tráfico automatizado
        • A través de las hipótesis exploradas en este resultado clave, nuestro objetivo es identificar las lagunas en nuestras heurísticas actuales de detección de tráfico automatizado y entender dónde no clasifican adecuadamente el tráfico de visualización de páginas. Estos conocimientos informarán mejoras en las líneas de producción que generan y clasifican las métricas de visualización de páginas. Además, definiremos métricas de calidad de los datos para monitorear y medir mejoras en la precisión de los datos.
        • Esta operación pondrá las bases para un objetivo clave de seguimiento centrado en la implementación de las mejoras necesarias en el flujo de trabajo identificado aquí. Las métricas de calidad de los datos establecidas en esta fase servirán como referencia para evaluar la eficacia de dichas mejoras futuras.
      • Resultado clave SDS1.2: Para finales del primer trimestre, el conjunto histórico de datos de contenidos de mediawiki estará disponible a través de la exportación de un archivo con garantías de entrega semana (SLOs). El archivo de datos exportado tendrá paridad comparado con el flujo de datos anterior (legacy) de dumps l XML .
        • El objetivo KR 1.4 para el año fiscal 2024/25 ha sido eliminar la dependencia de los conjuntos de datos mediawiki_wikitext_history y mediawiki_wikitext_history_current actualizados mensualmente para las tres canalizaciones descendentes más relevantes y brindar un conjunto de datos alternativo con SLO semanales garantizados.
        • Si bien la versión KR 1.4 del año fiscal 2024/25 ayudó a mitigar los problemas de fiabilidad de las canalizaciones dependientes más relevantes, aún quedan canalizaciones con la fuente de entrada heredada poco fiable. Estas también deberían migrarse, al igual que la fuente de entrada basada en archivos, al propio conjunto de datos del historial de wikitexto.
      • Resultado clave SDS1.3: Para el final del segundo trimestre, la detección de bots incorpora una (1) señal adicional y genera alertas automáticas por anomalías.
        • En toda la Fundación, los equipos están tomando decisiones de producto y financiación basándose en la capacidad de determinar la diferencia entre un lector humano y el tráfico automatizado. La Plataforma de Datos es el repositorio central de señales de detección de bots y análisis en lotes. A través de las hipótesis que hemos explorado en los primeros dos trimestres, planeamos comenzar a introducir nuevas señales de detección de bots para mejorar nuestro análisis de tráfico automatizado, así como comenzar a introducir nuevas señales que sean eficientes y repetibles.
      • Resultado clave SDS1.4: Para el final del segundo trimestre, las personas responsables de tomar decisiones tienen un entendimiento claro del estado actual de la visión que ofrecen nuestras métricas organizacionales. Sabremos si hemos tenido éxito si ofrecemos una presentación lista para la Junta Directiva que sitúe el análisis de nuestras métricas dentro del ecosistema Wikimedia y dentro de las tendencias y obstáculos generales del mercado en el internet.
        • La perspectiva de nuestras métricas organizacionales se usan para tomar múltiples decisiones en toda la Fundación, incluyendo decisiones acerca de cómo construimos nuestros productos, cómo asignamos recursos de infraestructura y cómo recaudamos fondos. Al mismo tiempo, el panorama del internet está evolucionando, y el tráfico automatizado en particular afecta nuestras métricas. La meta es que el liderazgo de la Fundación pueda entrar a su reunión de diciembre con una narración clara acerca de las amenazas y oportunidades que enfrenta el ecosistema Wikimedia, apoyado por análisis concienzudo de las métricas internas y tendencias externas. Podemos contar esta historia al reunir perspectivas, métricas y datos que nos hablen con confianza acerca de:
          • Las tendencias en nuestras mmedidas internas de lectores (vistas de página)
          • Tendencias en nuestro ecosistema de contribuyentes
          • Tendencias de los datos externos e indices de referencia de la competencia
          • Perspectivas obtenidas de estudios internos y externos, así como de investigaciones confiables
      • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
        • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
          • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
          • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.

        • In Q3/Q4, we will follow that with three main deliverables:
          • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
          • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
          • Operationalize a client-side signal, which remains the most promising internally developed detection method.
      • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
        • A consistent delivery cadence
        • Most valuable content for our stakeholders
        • Areas for future automation
        • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
          • What meaningfully changed in the past week/2 weeks?
          • Have we learned anything new about existing trends that we’re questioning?
          • Why does it matter now?
          • What requires attention or action?
        • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

Plataforma de experimentación (SDS2)

  • Objetivo: Los gerentes de producto pueden evaluar de manera rápida, sencilla y segura los impactos de los cambios en las características del producto en Wikipedia. Discusión
    • Contexto objetivo: Para facilitar y acelerar la toma de decisiones basada en datos sobre el desarrollo de funcionalidades de productos, los gerentes de producto necesitan una plataforma de experimentación donde puedan definir funcionalidades, seleccionar audiencias de usuarios y visualizar mediciones de impacto. Acelerar el proceso desde el lanzamiento hasta el análisis es crucial, ya que acortar el plazo de aprendizaje acelerará la experimentación y, en última instancia, la innovación. Las tareas manuales y los enfoques de medición a medida se han identificado como obstáculos para la velocidad. Lo ideal es que los gerentes de producto puedan pasar del lanzamiento del experimento al descubrimiento con poca o ninguna intervención manual de ingenieros y analistas.
    • Nos centramos en Wikipedia para el próximo año fiscal porque es allí donde las experiencias centrales están interesadas en la experimentación (la estrategia organizacional nos hace duplicar la apuesta por Wikipedia) y porque nos permite centrarnos y señalar más claramente con qué equipos y proyectos estamos participando. Otros equipos han utilizado los componentes de la plataforma experimental y podrían seguir haciéndolo, pero este objetivo no se centrará en ese uso.
      • Resultado clave SDS2.1: al final del segundo trimestre, permitir la finalización de al menos dos ciclos experimentales completos utilizando la plataforma de experimentación.
        • A medida que la organización prioriza cada vez más la toma de decisiones de productos basadas en datos, debemos facilitar la experimentación a todos los equipos de productos, no solo a aquellos con habilidades especializadas. El Equipo de Productos necesita estándares, herramientas e infraestructura compartidos que les permitan:
          • Probar ideas rápidamente en nuestra base global de usuarios
          • Medir el impacto en los cambios de productos con métricas estandarizadas.
          • Compartir los resultados de manera transparente con los grupos de interés de nuestro movimiento.
        • Por qué estamos cambiando el enfoque de número de "equipos habilitados" a "experimentos completados":
        1. Alineación estratégica: es la principal métrica de éxito de la plataforma.
        2. Enfoque basado en datos: nuestra investigación de usuarios/as (en curso) sugiere una preparación variable del equipo en toda la organización, mientras que sabemos que el equipo web ha confirmado su interés en dos experimentos específicos.
        3. Optimización de recursos: el lanzamiento de nuestra plataforma MVP requerirá una incorporación personalizada, lo que hará más eficiente a corto plazo centrarse en oportunidades de experimentación en lugar de abarcar una amplia red de contactos entre varios equipos. Planeamos avanzar hacia un lanzamiento general y, si podemos evitarlo, no queremos reinvertir en la capacitación de los equipos.
        4. Enfoque en el futuro: la retroalimentación de los ciclos completos de experimentación nos permitirá mejorar la plataforma de forma más eficaz que los aprendizajes obtenidos tras una adopción parcial o incompleta. A medida que avanzamos hacia el lanzamiento general, centrarnos en la finalización de los experimentos evita invertir en enfoques temporales que tendrían que rediseñarse.
        • Estamos llevando a cabo una investigación de usuarios/as para identificar las necesidades y requisitos del equipo: se programarán encuestas y entrevistas para aclarar las necesidades del equipo de productos en la segunda mitad de mayo de 2025. Una vez finalizada la investigación, elaboraremos un calendario de experimentación que nos permitirá establecer nuestros próximos objetivos de KR y priorización.
      • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
        • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
        • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
        • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
      • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
        • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
          In making GrowthBook the source of truth for experiment configuration, we aim to:
          • Reduce coordination when running an experiment
          • Enable more frequent and repeatable experimentation
          • Clearly delineate between instruments and experiments
          • Move toward a mental model centered on metrics rather than instruments
      • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
        • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
        • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
        • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Públicos futuros

Públicos futuros (FA1)

  • Objetivo: La Fundación Wikimedia cuenta con recomendaciones sobre inversiones estratégicas a realizar que ayuden a nuestro movimiento a servir a nuevas audiencias en una Internet cambiante. Discusión
    • Contexto objetivo: Debido a los cambios continuos en la tecnología y el comportamiento de los usuarios en línea (p. ej., la creciente preferencia por obtener información a través de aplicaciones sociales, la popularidad de los videos educativos de corta duración y el auge de la IA generativa), el movimiento Wikimedia se enfrenta a retos para atraer y retener lectores y colaboradores. Estos cambios también ofrecen oportunidades para llegar a nuevas audiencias mediante la creación y difusión de información de nuevas maneras. Sin embargo, como movimiento, no tenemos una visión clara, basada en datos, de los beneficios y las desventajas de las diferentes estrategias que podríamos implementar para superar los desafíos o aprovechar las nuevas oportunidades. Por ejemplo, ¿deberíamos...?
      • Invertir en nuevas características como chatbots?
      • Aportar el conocimiento y las vías de contribución de Wikimedia a plataformas populares de terceros?
      • Algo más?
    • Para asegurar que Wikimedia se convierta en un proyecto multigeneracional, probaremos hipótesis para comprender y recomendar estrategias prometedoras - para la Fundación Wikimedia y el movimiento Wikimedia - para perseguir para atraer y retener a futuros públicos.
      • Resultado clave FA1.1: Como resultado de los conocimientos y recomendaciones experimentales sobre audiencias futuras, al final del tercer trimestre al menos un objetivo o resultado clave propiedad de un equipo que no pertenece a Audiencias Futuras está presente en el borrador del plan anual del año siguiente.
        • Desde 2020, la Fundación Wikimedia ha estado siguiendo tendencias externas que pueden afectar nuestra capacidad para servir a las generaciones futuras de consumidores de conocimiento y contribuyentes de conocimiento, y seguir siendo un movimiento de libre conocimiento próspero para las generaciones venideras. Públicos Futuros, un pequeño equipo de I+D, será:
          • Realizar experimentos rápidos y limitados en el tiempo (que tengan como objetivo al menos 3 experimentos por año fiscal) para explorar formas de abordar estas tendencias
          • Con base en los conocimientos adquiridos a partir de la experimentación, hacer recomendaciones sobre nuevas inversiones no experimentales que la WMF debería llevar a cabo (es decir, nuevos productos o programas que deben ser asumidos por un equipo o equipos completos) durante nuestro período de planificación anual regular.
        • Este resultado clave se alcanzará si al menos un objetivo o resultado clave que pertenece a un equipo fuera de Públicos Futuros y que se impulse por una recomendación de Públicos Futuros aparece en el proyecto de plan anual para el ejercicio fiscal siguiente.

Vídeo social (FA2)

  • Objetivo: Los jóvenes (<25 años) aman, aprenden, interactúan con y comparten el contenido de Wikipedia en las plataformas en las que les gusta pasar tiempo en línea. Discusión
    • Contexto objetivo: la experimentación de Públicos Futuros con videos cortos durante este año fiscal ha demostrado que podemos llegar a audiencias más jóvenes a gran escala en estas plataformas, pero nuestros datos de salud de la marca muestran que nuestra inversión actual no es suficiente para contrarrestar la disminución del conocimiento y la afinidad con Wikipedia entre las audiencias de la Generación Z.
    • Para asegurarnos de llegar y involucrarnos de manera efectiva a esta generación, creemos que tendremos que involucrarnos en una variedad de tácticas, y aumentar significativamente nuestro compromiso en áreas como el marketing de pago e influencers, campañas creativas, ser receptivos a las tendencias y aumentar nuestro nivel de experimentación en estos canales.
    • Esperamos que los desafíos que enfrentamos requieran una inversión más sustancial para ayudarnos a superarlos, particularmente en los esfuerzos de Comunicación y Marketing para crear compromiso, así como en la colaboración interdepartamental para crear nuevos productos y experiencias orientadas a aumentar la presencia de la marca y el contenido de Wikipedia en estas plataformas.
      • Resultado clave FA2.1: Generar 9.500.000 de visualizaciones de contenido de vídeo de formato corto en todos los canales propios para el final del primer semestre.
        • Este año, hemos alcanzado un alcance de aproximadamente 1 millón de visitas en 3 meses después de lanzar videos cortos en los canales de Wikipedia en TikTok, Instagram y YouTube. Para el comienzo del próximo año fiscal, esperamos más seguidores en nuestros canales propios y más ideas sobre contenido efectivo/enganchador que podemos poner en práctica para llegar a más espectadores.
        • Al establecer un objetivo ambicioso en el primer semestre del año, esperamos lograr un impacto más significativo, permitir la creación de nuevas estrategias/procesos para facilitar el trabajo y poder abogar por recursos adicionales para alcanzar este objetivo.
      • Resultado clave FA2.2: aumentar nuestra población seguidora en TikTok de un nivel Mid (100 mil a 250 mil seguidores) a un nivel Macro (250 mil a 1 millón de seguidores) para el final del año fiscal 2025/26 (junio de 2026).
        • Actualmente estamos en el nivel Mid (medio) de seguidores de TikTok (100 mil a 250 mil seguidores), y nuestra meta es alcanzar el nivel Macro (250 mil a 1 millón de seguidores) para el final del año fiscal 2025/26 (junio de 2026). Estos niveles - Micro, Mid y Macro - son hitos estándar de la industria en cuanto a tamaño y alcance de audiencia. Para llegar ahí, refinaremos nuestra estrategia de contenidos para atraer mejor a seguidores de la Generación Z y aumentar nuestra visibilidad en general a través de gestión comunitaria. El rendimiento del primer semestre nos informará para hacer ajustes en el segundo semestre para poder acelerar el crecimiento y alcanzar este hito.
      • Resultado clave FA2.3: Lanzar un producto fuera de la plataforma orientado a los nuevos métodos de aprendizaje/consumo de medios de las audiencias futuras y llevarlo al mercado a través de una campaña de marketing y marca de producto colaborativa.
        • Públicos Futuros suele trabajar en experimentos a pequeña escala con un marketing mínimo/orgánico. Este año, nos gustaría reservar tiempo para una campaña de marketing de nuevos productos más amplio dirigido a audiencias más jóvenes fuera de la plataforma.

Soporte de productos e ingeniería (PES)

Soporte de productos e ingeniería (PES1)

  • Objetivo: Los equipos de productos e ingeniería de la WMF son más efectivos gracias a procesos mejorados, lo que fomenta un cambio positivo en nuestra cultura. Discusión
    • Contexto del objetivo: Este objetivo busca hacer que las formas de trabajo de la Fundación Wikimedia sean más rápidas, inteligentes y eficaces. Se trata de cómo trabajamos. Esto implica menos fricción y obstáculos (ineficiencias y errores) en los procesos, y lograr un impacto más rápido. Este objetivo también busca aprender formas de trabajo que puedan adoptarse en todo el departamento y la organización.
      • Resultado clave PES1.1: Para el final del segundo trimestre, definir objetivos de niveles de servicio para 6 servicios de producción basados ​​en una rúbrica de priorización que apunta a maximizar nuestro aprendizaje sobre cómo definir y usar los objetivos de niveles de servicio para tomar decisiones informadas con respecto a la priorización del trabajo relacionado con la confiabilidad por parte de los equipos de partes interesadas.
        • Un objetivo de nivel de servicio (ONS) es un acuerdo entre los equipos de las partes interesadas sobre un nivel de servicio objetivo (confiabilidad/rendimiento) que los equipos colaboran para alcanzar (y no exceder en gran medida). Por ejemplo, ayuda a determinar cuándo un equipo de desarrollo debe priorizar o priorizar el trabajo de fiabilidad o rendimiento, o qué constituye un problema. Los equipos deben preocuparse por identificar lo que es inmediato (alerta/respuesta a incidentes/errores críticos) en comparación con lo que no es. El objetivo es reducir las fricciones entre las funciones mediante la negociación de objetivos e informar sobre una prioridad compartida y clara.
      • Resultado clave PES1.2: A finales del segundo trimestre, las señales de la comunidad (incluida la lista de deseos) habrán influido en la WMF para priorizar al menos 5 líneas de trabajo de productos para el tercer y cuarto trimestre.
        • Nuestro objetivo es identificar y celebrar cuando los equipos priorizan el trabajo en función de las peticiones de la comunidad apoyadas en datos.
        • Dos hipótesis previstas se centran exclusivamente en la Lista de Deseos. Están diseñadas para mejorar la confianza, agilizar los procesos y aumentar la participación del personal y las personas voluntarias. Otra hipótesis es un experimento diseñado para ver si hay suficientes señales valiosas en los cafés, y si la IA puede apoyar nuestro músculo de recopilación de señales.
      • Resultado clave PES1.3: La Fundación incorpora al plan anual dos experimentos interdepartamentales en etapa inicial, validados por nuestras audiencias externas de consumidores, donantes y contribuyentes.
        • Este trabajo consiste en crear experimentos y procesos de experimentación para su adopción en toda nuestra organización.
        • La Fundación refuerza una cultura de experimentación interdepartamental mediante la incorporación de dos experimentos validados en primeras etapas en su planificación anual. Esta iniciativa fomenta la colaboración más allá de los equipos de características del departamento de Productos y Tecnología, fomentando más innovación con otros departamentos de la organización (como las Comunicaciones y el Avance). Al sembrar ideas nuevas no probadas y agilizar los procesos para la experimentación, los equipos mejoran la productividad y el impacto a escala. El éxito se mide completando dos experimentos interdepartamentales al año, integrándolos en el futuro trabajo de resultados claves y aumentando la adopción de prácticas de experimentación. Ejemplos de resultados son nuevos prototipos para aumentar el crecimiento y la productividad de los nuevos editores, a características experimentales que profundizan la conexión del lector y donantes a Wikipedia. Una oportunidad específica identificada es conectar pequeñas exploraciones de características para celebrar el 25 aniversario de Wikipedia.
      • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
        • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
        • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
        • We're anticipating that this will mean:
          • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
          • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
          • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
        • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
      • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
        • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
          • We have 19 SLOs currently.
          • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
          • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
        • Success looks like:
          • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
          • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
          • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
          • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
      • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
        • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
          • We estimate there are ~20 critical services without owners.
          • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
          • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
      • Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
        • Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Hipótesis

Primer trimestre

El primer trimestre (Q1) del plan anual de la WMF abarca de julio a septiembre.

Hipótesis sobre las experiencias wiki (WE)

[ Resultados clave sobre las experiencias wiki ]

Discusión

Abreviatura de la hipótesis texto del primer trimestre Detalles y discusión
WE1.1.1 Si pedimos a las nuevas personas voluntarias que pegan texto de un sitio externo que confirmen si son ellas quienes han escrito el contenido que intentan añadir, veremos un descenso de ≥10% en el porcentaje de nuevas ediciones de contenido que publican las nuevas personas voluntarias y que son revertidas por motivos de WP:COPYVIO (y políticas relacionadas).
WE1.1.2 Si entregamos una versión beta inicial de la edición sugerida «Mejorar el tono», entonces podremos saber si este nuevo formato de ediciones sugeridas es una forma significativa de aumentar las ediciones constructivas para los nuevos colaboradores sin aumentar la carga de moderación para los patrulleros/revisores.
WE1.1.3 Si desplegamos un nuevo Modo de Sugerencia dirigido a colaboradores de mayor antigüedad dentro del editor visual (móvil + escritorio) como una Característica Beta con ≥ 3 nuevas sugerencias de edición dentro de él, descubriremos qué ajustes -si los hay- deben hacerse antes de evaluar la experiencia con nuevos(as) voluntarios(as) a través de un experimento controlado.
WE1.1.4 Si desplegamos Reference Check (chequeo de referencias) en en.wiki a través de un experimento controlado, veremos un aumento de ≥10% en las ediciones constructivas que publican los nuevos(as) voluntarios(as) y sabremos si hay suficiente apoyo entre los patrulleros y moderadores para habilitar la función de forma más generalizada.
WE1.1.5 Si probamos un sistema de progresión a través de prototipos de diseño con personas recién llegadas, podremos identificar qué tipos de hitos, orientación y reconocimiento se perciben como más motivadoras, y utilizar estos conocimientos para finalizar un diseño para futuras experimentaciones piloto en wikis.
WE1.1.6 Si investigamos las principales barreras técnicas, sociales y de comportamiento, así como los factores que facilitan la edición web móvil a través de la investigación de usuarios y el análisis de datos, generaremos al menos 3 perspectivas procesables que cerrarán las principales lagunas de conocimiento y fortalecerán nuestra capacidad para priorizar con confianza las inversiones en productos para la segunda mitad del FY25/26 y más allá.
WE1.2.1 Si creamos una prueba de concepto para mostrar los datos de las contribuciones colaborativas en las wikis, podremos recabar la opinión de al menos 30 colaboradores, de los cuales el 70% opinará que la función es útil y podría ayudar a impulsar el esfuerzo colaborativo.
WE1.3.1 Si utilizamos las necesidades identificadas en la investigación previa y diseñamos y compartimos las primeras maquetas de los X módulos de moderación más impactantes, podremos modificar con ellas la página de inicio para las acciones de moderación.
WE1.3.2 Si modificamos la página de inicio para recién llegados para que muestre condicionalmente los módulos de moderador, podremos probar la viabilidad de utilizar la página de inicio para moderadores.
WE1.4.1 Si hacemos una serie de mejoras mencionadas en T396489, reduciremos la lentitud de las consultas de cambios recientes en un X por ciento en las wikis grandes. Entonces las herramientas de moderación serán capaces de desplegar módulos de página de inicio en esas wikis sin preocupación especial por el rendimiento de la base de datos. T400696
WE2.1.1 Si invitamos a los hablantes nativos de pequeñas wikis a través de un banner de CentralNotice en una Wikipedia de alto tráfico en su región a contribuir con ediciones sugeridas y otras características de Crecimiento, podemos evaluar si este enfoque atrae a nuevos hablantes nativos y si utilizan estas herramientas de edición para mejorar el contenido clave.
WE2.1.2 Si desarrolláramos y publicáramos sugerencias de traducción adaptadas a los nuevos editores, podríamos comprobar si este enfoque produce mejores resultados de traducción que el actual.

De este modo se abordan los conocidos retos a los que se enfrentan los nuevos editores, que tienen una mayor probabilidad de que se borren sus artículos. Al orientarles hacia la traducción de contenidos más manejables, el objetivo es ofrecer una introducción menos abrumadora y más accesible al proceso de traducción. Los buenos candidatos para artículos y secciones podrían parecer de complejidad limitada en cuanto a formato y longitud total.

WE2.1.3 Si aprendemos sobre la experiencia del editor al crear nuevos artículos y secciones (incluyendo motivaciones, puntos de dificultad y su reacción a las nuevas ideas sobre cómo apoyarlos mejor), entonces descubriremos las necesidades y comportamientos de los usuarios que proporcionan ideas y estrategias procesables para informar al producto, diseño e ingeniería sobre la mejora de la experiencia de creación de artículos.
WE2.1.4 Si exploramos, a través de talleres participativos o entrevistas, cómo tres Wikipedias de tamaño medio abordan las lagunas de conocimiento y su importancia, descubriremos definiciones de trabajo o conceptos marco para el «conocimiento vital» que son relevantes para cada comunidad.
WE2.2.1 Si seguimos el despliegue de Parsoid e integramos Wikifunciones en la mayoría de los Wikcionarios y en algunas Wikipedias de poco tráfico, obtendremos las pruebas que necesitamos para desplegar con confianza en wikis más grandes.
WE2.2.2 Si permitimos que las Wikifunciones muestren tablas HTML, estilos y enlaces, demostraremos a través de una Función que muestra una tabla de conjugaciones su capacidad para generar nuevos conocimientos netos sobre los Wikcionarios más allá de las simples conversiones.
WE2.2.3 Si añadimos soporte para entidades de Wikidata en interacciones con funciones incrustadas, habilitaremos más de 200 nuevas funciones que pueden generar frases completas usando entidades de Wikidata, haciendo que las funciones sean más fáciles de usar en los proyectos Wikimedia.
WE2.2.4 Si elaboramos un plan de arquitectura sobre dónde residirá el Contenido de Abstract y cómo interactuará con Wikipedia, estaremos más preparados para implementar la plataforma de la Abstract Wikipedia para aumentar la provisión de contenido enciclopédico de alta calidad.
WE2.2.5 Si elaboramos un plan de arquitectura sobre dónde residirá el Contenido de Abstract y cómo interactuará con Wikipedia, estaremos más preparados para implementar la plataforma de la Abstract Wikipedia para aumentar la provisión de contenido enciclopédico de alta calidad.
WE2.2.6 Si hacemos más expresivo y conciso el formato de las peticiones internas de nuestro servidor, podremos aumentar la estabilidad del sistema, lo que permitirá un despliegue más amplio.
WE2.2.7 Si proporcionamos fragmentos de prototipos que utilicen Wikidata y llamadas a Wikifunctions para generar fragmentos en lenguaje natural, demostraremos que estamos preparados para el proyecto, y estaremos listos para que se utilice para entrenar a la IA de modo que los humanos no tengan que pensar demasiado en las funciones.
WE2.2.8 Si facilitamos la importación de enunciados de Wikidata con calificadores, será posible generar hechos multifacéticos (hechos que requieren algo más que un asunto/predicado/valor para expresarse), lo que incluye un 50% estimado del contenido enciclopédico de Wikidata.
WE2.2.9 Si proporcionamos almacenamiento en la memoria caché de las entidades de Wikidata recuperadas, reduciremos al menos en un 50% el tiempo medio de ejecución de las funciones basadas en contenidos de Wikidata, lo que reducirá los tiempos de espera y la frustración de las personas.
WE2.2.10 Si proporcionamos un elemento de sentido del lexema de Wikidata en la interfaz de usuario de Wikifunciones, los colaboradores podrán identificar y seleccionar los lexemas relevantes sin salir de la plataforma/Wikifunciones, reduciendo el cambio de contexto y permitiendo una creación más rápida y satisfactoria de funciones relacionadas con el lenguaje.
WE2.2.11 Si atendemos a las conclusiones de usabilidad de la comunidad Dagbani sobre la integración de Wikifunciones en Wikipedia, observaremos que los editores encuentran pocos o ningún problema crítico de usabilidad al insertar una función en un artículo durante las pruebas.
WE3.1.1 Si probamos una versión mejorada de la función de navegación por pestañas en la aplicación para iOS, veremos un aumento del 5% en el uso de varios días entre los usuarios que utilicen pestañas.
WE3.1.3 Si ofrecemos a los usuarios una nueva forma de navegar por el contenido de imágenes o vídeos relevantes dentro de las páginas de los artículos, veremos al menos un 3% de clics entre los usuarios a los que se les presenta esta función.
WE3.1.4 Si mostramos a las personas lectoras varios conceptos para recorrer la red de conocimientos en las wikis, obtendremos una lista priorizada de conceptos para seguir desarrollando.
WE3.1.5 Si ofrecemos a las personas que leen la web la opción de ver una versión traducida automáticamente del contenido de Wikipedia que no está disponible en su idioma, sabremos si aumenta la actividad de lectura, medida como un aumento del 3% en las interacciones de la página, atrayendo a los lectores a la wiki en el idioma local con un aumento potencial de la actividad de edición local. Esto se llevará a cabo en un entorno controlado de pruebas A/B durante no más de 6 meses, y en 13 Wikipedias con consentimiento previo, utilizando servicios abiertos de traducción automática ya disponibles para los editores de Wikipedia.
WE3.2.1 Si colaboramos con la recaudación de fondos, desarrollaremos diapositivas de donantes más atractivas, integradas y personalizadas en el Resumen anual de iOS. A esto le seguirá una hipótesis en el segundo trimestre para evaluar si la mejora del Resumen anual se ha medido a través de pruebas con usuarios. A esto le seguirá una hipótesis en el segundo trimestre para evaluar si el Resumen anual mejorado obtuvo un 5 % más de donaciones que el Resumen anual de 2024.
WE3.2.2 Si pedimos a las personas que leen la aplicación de Android en mercados que no son de campaña que configuren un recordatorio opcional y personalizable (cantidad y frecuencia) para hacer donaciones en función de su uso de Wikipedia, veremos un aumento del 5% en las donaciones a través del menú de la aplicación en esos mercados.
WE3.2.3 Si realizamos un experimento de prueba A/B con usuarios que han cerrado sesión para mostrar variantes sutiles del punto de entrada de donaciones tanto para móviles como para equipos de escritorio, observaremos un 2% más de donaciones a través de las nuevas rutas de acceso, en comparación con el grupo de control.
WE3.3.1 Si añadimos elementos personalizados con un esfuerzo bajo o medio solicitados por los usuarios de iOS en 2024 al año de revisión de 2025, veremos un aumento del 3% en la satisfacción en comparación con el año pasado, medido a través de pruebas de usabilidad o pruebas beta.
WE3.3.2 Si ampliamos la pestaña Editar existente en Android para convertirla en un centro de actividades personalizado que incluya información sobre la participación de lectores y no editores, veremos un aumento del 5% en la participación de varios días con la pestaña en comparación con la versión original.
WE3.3.3 Si introducimos al menos un avatar desbloqueable en la aplicación de Android para las personas titulares de cuentas -obtenido a través de acciones significativas de las personas lectoras, como guardar un determinado número de artículos-, aumentaremos la participación repetida con la acción asociada por parte de los usuarios conectados en un 10% a lo largo de varios días.
WE3.3.4 Si damos a las personas lectoras que han iniciado sesión la posibilidad de guardar artículos en una lista de lectura privada, esperamos que aumente la participación en el sitio, medida por un aumento del 5% en el tráfico interno de referencia para las personas lectoras que utilizan esta función, y un aumento estadísticamente significativo para todas las personas.
WE3.3.5 Si realizamos un estudio de usuarios que permita a las personas lectoras en la web recopilar/curar contenidos de Wikipedia, al menos el 10% de las participantes guardarán dos o más tipos distintos de contenidos (por ejemplo, artículos, extractos, medios de comunicación) en una colección.
WE3.4.1 Si trabajamos hacia un despliegue híbrido de Punto de Presencia (PoP)/CDN, nos permitirá poner en marcha tanto PoPs completos como mini PoPs (físicos y en la nube) según sea necesario, sentando las bases para un prototipo de despliegue de mini PoPs en el futuro.
WE3.6.1 Si realizamos una prueba A/A sobre la tasa de retención de los usuarios que han cerrado sesión, estableceremos una línea de base para la tasa de retención que podremos utilizar en trimestres futuros.
WE3.6.2 Si creamos y publicamos una definición para el lector logueado, podremos utilizar esta definición en todos los equipos e hipótesis relacionados con el WE 3.3 KR.
WE3.6.3 Si involucramos a las comunidades en conversaciones sobre la evolución de las necesidades de sus lectores y sobre la naturaleza cambiante del conocimiento en Internet, podemos crear un enfoque compartido sobre cómo servir a las personas lectoras y trabajar conjuntamente sobre la conveniencia y el modo de poner a prueba nuestras distintas ideas (incluidas las que giran en torno al multimedia, la búsqueda y el hallazgo, y el aprendizaje automático).
WE3.6.4 Si investigamos las distintas motivaciones, comportamientos y necesidades que hay detrás de cuándo, por qué y cómo utilizan las personas lectoras Wikipedia y otras plataformas de conocimiento, obtendremos conclusiones que podremos utilizar para informar y hacer evolucionar nuestra estrategia de consumo.
WE4.1.1 Si creamos un prototipo de flujo no urgente mínimamente viable y mantenemos abierto un ciclo iterativo de retroalimentación a medida que lo desarrollamos con usuarios con permisos extendidos, estos grupos apoyarán un despliegue más extenso de este flujo. Project page
WE4.2.1 Si comunicamos el nivel de riesgo de hCaptcha asociado a la creación de cuentas a funcionarios de confianza, reduciremos el tiempo necesario para identificar a personas malintencionadas y aumentaremos el número de detecciones de cuentas de malintencionadas creadas en la plataforma. Podemos medir el éxito de la hipótesis observando la tasa de bloqueos aplicados a las cuentas, la alineación de los niveles de riesgo hCaptcha y los bloqueos de cuentas en general, y los comentarios cualitativos de los funcionarios.
WE4.2.2 Si generamos investigaciones sugeridas para que los CheckUsers realicen un seguimiento, observaremos una disminución del tiempo necesario para identificar las cuentas de actores malintencionados y un aumento del número de cuentas de actores malintencionados identificadas. Sabremos que hemos tenido éxito cuando veamos un uso regular de la función «Investigaciones sugeridas», un aumento de las mitigaciones aplicadas a las cuentas identificadas a través de las investigaciones sugeridas y a través de los comentarios de la encuesta cualitativa.
WE4.2.3 Si analizamos los datos de las pruebas para la creación de cuentas con hCaptcha, comprenderemos el proceso de creación de cuentas, la eficacia del rompecabezas y las puntuaciones de hCaptcha, y dispondremos de los datos necesarios para informar sobre el futuro despliegue de hCaptcha en las creaciones de cuentas.
WE4.2.4 Si desplegamos la UserInfoCard en todas las wikis, capacitaremos a los funcionarios y moderadores para identificar y mitigar más eficazmente las cuentas de actores malintencionados. Project page
WE4.2.5 Si investigamos, consultamos a las comunidades e investigamos soluciones técnicas, podremos definir un conjunto de razones de bloque estructuradas que puedan utilizarse en todas las wikis de la WMF.
WE4.2.6 Si desarrollamos la capacidad de implementar clústeres basados en OpenSearch en la plataforma de datos, los equipos de ingeniería de características de productos podrán desarrollar sistemas que integren esta capacidad, con un alto grado de autonomía, resiliencia y aislamiento respecto a otros sistemas basados en búsquedas. El primer y principal componente de este sistema será el servicio IPoid.
WE4.2.7 Si implementamos la integración de hCaptcha Enterprise en varias Wikipedias en producción como prueba piloto, podremos recopilar datos sobre la eficacia y el valor de hCaptcha Enterprise en la defensa contra el abuso, la detección de bots, la usabilidad y la accesibilidad.
WE4.3.1 Si integramos el soporte para la nueva cookie Edge Uniques en requestctl, nuestro motor de reglas de perímetro para SRE que lucha contra el abuso, podremos defendernos mejor contra los ataques DDoS y la reutilización de contenido.
WE4.4.1 Si podemos realizar mejoras basadas en la retroalimentación de los pilotos e implementar cuentas temporales en todos los proyectos, podremos proteger la exposición de la información de identificación personal (direcciones IP) de los usuarios no registrados en todos nuestros proyectos para que esté disponible para menos del 0.1 % de todos los usuarios (registrados). Project page
WE4.4.2 Si nos comunicamos de forma clara y oportuna con las partes interesadas relevantes del movimiento (incluidas las comunidades wiki y los funcionarios globales), podremos implementar el cambio en todas las wikis restantes, reducir la carga de trabajo imprevista y evitar tener que revertir la implementación.
WE4.4.3 Si facilitamos a las personas encargadas del patrullaje la tarea de filtrar acciones y ver la actividad de las cuentas temporales, basándose en sus direcciones IP, entonces permitiremos que las cuentas temporales se implementen con éxito en todas las wikis.
WE4.4.4 Si permitimos que se revoque el acceso temporal a la revelación de IP de las cuentas de acuerdo con la política de acceso a la revelación de IPs, y mostramos la función en más espacios, entonces permitiremos que las cuentas temporales se implementen con éxito en todas las wikis.
WE4.5.1 Si realizamos una investigación cualitativa para identificar ejemplos de abuso por parte de personas malintencionadas asistidas por IA generativa (como spam, acoso, abusadores habituales, ediciones pagadas no reveladas o campañas de desinformación), podremos evaluar el riesgo para nuestros modelos comunitarios y generar ideas para mitigar los diferentes tipos de abuso asistido por la IA generativa.
WE4.6.1 Si automatizamos el proceso de sincronización de cuentas en Zendesk para restablecer contraseñas, se aliviará la carga de trabajo de T&S y les permitirá gestionar más solicitudes de restablecimiento de 2FA entrantes.
WE4.6.2 Si apoyamos y animamos a los usuarios a registrar múltiples factores de autenticación, los usuarios con 2FA habilitado serán menos propensos a quedarse sin acceso a su cuenta.
WE4.6.3 Si permitimos que todos los usuarios con una dirección de correo electrónico confirmada puedan activar la autenticación de dos factores (2FA) para sus cuentas, pero no anunciamos de forma proactiva este cambio a los usuarios, la carga de trabajo de nuestro servicio de asistencia para la recuperación se mantendrá en un nivel sostenible.
WE5.1.1 Si utilizamos diferentes backends de almacenamiento para sesiones autenticadas y anónimas, podremos proteger Sessionstore de ataques DDoS y scrapers de gran volumen, al no sobrecargarlo con las sesiones anónimas que se crean para proporcionar prevención CSRF en las páginas de autenticación. T398814
WE5.1.2 Si cambiamos las cookies de sesión de MediaWiki a un formato estructurado con firma criptográfica, podremos utilizar la presencia de una sesión como factor de protección contra los scrapers, al permitir la verificación confiable de las sesiones en el perímetro de una manera eficiente y altamente escalable. T398815
WE5.1.3 Si creamos una solución de limitaciones de velocidad para la puerta de enlace API utilizando un entorno de desarrollo local basado en Kubernetes, podremos determinar la mejor opción para realizar pruebas con tráfico de producción, comparando el rendimiento y la funcionalidad de al menos tres servicios diferentes de limitaciones de velocidad. T398913
WE5.2.1 Si rediseñamos la interfaz de usuario de REST API Sandbox para satisfacer mejor las necesidades de información de los desarrolladores, mejoraremos la claridad de la documentación, tal y como se ha validado mediante pruebas de usabilidad.
WE5.2.2 Si dirigimos todas las API por debajo de 1 dólar a través de una puerta de enlace central, desbloquearemos los medios de gestión centralizada de las API y podremos empezar a medir de forma coherente el tráfico y los patrones de uso de las API REST para obtener información que nos servirá para tomar decisiones y medidas en el futuro.
WE5.2.3 Si implementamos paneles de control y alarmas para la API REST de MediaWiki, podremos demostrar una forma sostenible, útil y replicable de mejorar la visibilidad del comportamiento de nuestros sistemas y detectar problemas más rápidamente, especialmente durante modificaciones críticas.
WE5.3.1 Si ampliamos y optimizamos las directrices de atribución de la experiencia de usuario (UX) al tiempo que actualizamos las directrices existentes, estableceremos un conjunto básico de directrices mejoradas listas para ser probadas internamente y perfeccionadas de forma iterativa con el fin de prepararlas para un uso público más amplio.
WE5.3.2 Si creamos una presentación que demuestre las ventajas de atribuir Wikipedia a terceros que reutilizan contenidos y a sus usuarios finales, podremos apoyar WME4.1 y WME4.2 al conseguir que al menos un socio de reutilización adicional acepte aparecer en un testimonio o demostración de atribución antes de que finalice el primer trimestre.
WE5.4.1 Si nos aseguramos de que la mayoría de las solicitudes de la web obtengan una cookie única, será más fácil identificar los bots y las solicitudes falsificadas.
WE5.4.2 Si creamos una forma escalable de identificar a los clientes conocidos, podremos permitir excepciones a los límites generales de velocidad para los bots de origen verificado y avanzar hacia la aplicación sistemática de nuestras reglas.
WE5.4.3 Si reorganizamos el filtrado de las solicitudes de texto en la CDN en torno a un abordaje basado en listas de permitidos y denegados, podemos aplicar una limitación de velocidad general más estricta para los bots y optimizar el filtrado del tráfico.
WE5.4.4 Si desarrollamos una estrategia de medición unificada, podremos evaluar la estrategia plurianual para el «uso responsable de la infraestructura» y definir una hoja de ruta que sirva de guía para el desarrollo de métricas y las capacidades de presentación de informes.
WE6.1.1 Si reubicamos las compilaciones de imágenes diarias en el servidor de implementación y añadimos actualizaciones de imágenes activadas por acciones de implementación seleccionadas, descubriremos las limitaciones y estableceremos una referencia del tiempo necesario para realizar implementaciones más continuas.
WE6.1.3 Si añadimos wikifarms a un entorno de pruebas previo a la fusión, esto permitirá a los equipos de desarrollo que trabajan en producción y necesitan múltiples wikis para probar sus parches de forma aislada, lo que les dará mayor confianza antes de la producción y reducirá el número de fallos que pasan desapercibidos.
WE6.2.1 Si revisamos y publicamos nuestra lista de verificación de preparación para la producción, que define claramente los requisitos previos para que un servicio se considere listo para la producción, junto con las tareas que se pueden realizar de forma autónoma, alinearemos las expectativas entre los ingenieros de confiabilidad del sitio (SRE) y los equipos de desarrollo, mejorando nuestra eficiencia operativa y escalabilidad generales.
WE6.2.2 Si anunciamos la creación de una biblioteca Golang y nodejs que abstraiga muchas tareas laboriosas para los desarrolladores, estos responderán ofreciendo sugerencias y mostrando interés.
WE6.2.3 Si creamos una lista de verificación/hoja de trabajo, los desarrolladores podrán prepararse completamente con anticipación para la revisión del diseño de persistencia de datos.
WE6.3.1 Si implantamos al menos 70 Wikipedias con poco tráfico en el primer trimestre, excluyendo las wikis con soporte para variantes lingüísticas, aumentaremos nuestra confianza para la eventual implementación en las 10 wikis más importantes, lo que tendrá un mayor impacto en las visitas a las páginas servidas a través de Parsoid.
WE6.4.1 Si implementamos la tabla de enlaces divididos de Commons en su propio clúster, aumentaremos las posibilidades de que el crecimiento de la base de datos de Commons siga siendo sostenible. T398709
WE6.4.2 Si proporcionamos asistencia (SRE) a los equipos de ingeniería de MediaWiki (creando documentación, preparando la infraestructura necesaria, como paquetes PHP e imágenes de contenedores, y ofreciendo orientación y revisión), podrán iniciar con confianza la actualización de PHP 8.3 para producción a principios del segundo trimestre. T360995
WE6.4.3 Si exigimos un segundo factor físico (llave de seguridad de hardware) para los inicios de sesión SSH de los usuarios con privilegios elevados en el sistema, reduciremos el riesgo de que una computadora portátil comprometida provoque una grave brecha de seguridad.
WE6.4.4 Si unificamos nuestros dominios sirviendo todas las visitas a las páginas de los sitios MediaWiki a través de un dominio canónico, reduciremos la complejidad de la plataforma y los riesgos de optimización para motores de búsqueda (SEO) al eliminar el redireccionamiento del subdominio móvil. La finalización se mide en la disminución de redirecciones de visitas en dispositivos móviles a dominios canónicos, del 100% al 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
Hipótesis sobre los servicios de señales y datos (SDS)

[ Resultados clave de SDS ]

Discusión

Abreviatura de la hipótesis Texto del primer trimestre Detalles y discusión
SDS1.1.1 Si analizamos la eficacia de los algoritmos heurísticos de detección automática de tráfico en nuestros conjuntos de datos de visitas a la página, podremos desarrollar métricas de calidad de datos para describir su rendimiento y determinar la necesidad de realizar más inversiones en estos algoritmos.
SDS1.2.2 Si migramos el proceso de copias de seguridad XML de la infraestructura actual «Dumps 1» a un canal de datos que aproveche los canales de contenido de MediaWiki, podremos garantizar los SLO y desactivar la exportación XML basada en «Dumps 1».
SDS1.2.3 Si hacemos un repaso y revisamos los SLO para el historial de contenido de MediaWiki y la plataforma de eventos/Event Gate, podemos validar los consumidores, las métricas y las partes interesadas dependientes, e identificar las mejoras que podrían ser necesarias para los SLO, lo que nos ayudará a aclarar cualquier laguna en nuestras garantías de entrega semanales.
SDS2.1.1 Si colaboramos estrechamente con los equipos que realizan experimentos, aprenderemos cómo hacer que el sistema sea más autónomo en el futuro y qué retos conceptuales o técnicos pueden encontrar.
SDS2.1.2 Si logramos implementar una mejor depuración para el registro de eventos, los equipos de producto sabrán con certeza que su experimento está recopilando datos de eventos según lo previsto, lo que aumentará la confianza de los responsables del experimento.
SDS2.1.3 Si mejoramos el registro y la observabilidad del componente del sistema de pruebas A/B (xLab) de la plataforma de experimentación, así como de sus partes relacionadas con MediaWiki, podremos establecer puntos de referencia para el rendimiento del sistema y responder a los fallos relacionados con los experimentos.
SDS2.1.4 Si compartimos las historias y los resultados de los experimentos en toda la organización una vez al mes (a través de reuniones de operaciones de producto, reuniones del equipo de diseño y presentaciones entre equipos), conseguiremos una adopción orgánica de la plataforma de experimentación.
SDS2.1.5 Si informamos a los usuarios de que su instrumento, si se ha creado en xLab, contiene un conjunto de atributos que modifican la categoría de riesgo, disuadiremos a las personas que utilizan instrumentos para recopilar datos en exceso y aumentaremos la claridad en torno a qué combinación de atributos requiere una revisión de privacidad.
Hipótesis sobre las audiencias futuras (FA)

[ Resultados clave de las FA ]

Discusión

Abreviatura de la hipótesis texto del primer trimestre Detalles y discusión
FA1.1.1 Si 1) ofrecemos a los coleccionistas de medios en otras plataformas (como Letterboxd, Goodreads y RateMyMusic) formas de mejorar sus colecciones con conocimientos exclusivos de Wikipedia, o 2) ofrecemos a estos coleccionistas de medios contenidos interesantes para compartir en las redes sociales, podremos aumentar el alcance de Wikipedia fuera de la plataforma.
FA2.1.1 Si desarrollamos nuestra capacidad interna para crear contenido de videos breves (aumentando el tamaño de nuestro equipo y auditando e identificando oportunidades para aumentar la eficiencia en nuestro proceso de producción actual) en el primer trimestre, podremos aplicar lo aprendido del contenido creado en el año fiscal 2024-2025 y lograr un mayor alcance interanual del contenido producido en el segundo trimestre del año fiscal 2025-2026.
Hipótesis de soporte técnico y de productos (PES)

[ Resultados clave de PES ]

Discusión

Abreviatura de la hipótesis texto del primer trimestre Detalles y discusión
PES1.1.1 Si apoyamos a xLab, Charts y ToneCheck en la definición de métricas para los (Indicadores de nivel de servicio) o SLI en Prometheus, e incorporamos los Objetivos de nivel de servicio (SLO) en Pyrra, aprenderemos los límites y los casos extremos de nuestras herramientas en múltiples escenarios complejos, además de aclarar qué iteraciones son necesarias para la plantilla SLO, lo que nos ayudará a respaldar mejor los 6 SLO previstos para el objetivo clave.
PES1.1.2 Si probamos dos conjuntos de paneles de alertas SLO, aprenderemos lo difícil que sería implementar herramientas adecuadas para que los propietarios de los servicios comprendan claramente sus compromisos, y también si necesitamos migrar a una herramienta diferente que ofrezca una única vista de un SLO específico. Un panel de control se destinará a los informes trimestrales (donde se establece el Acuerdo de Nivel de Servicio real para el presupuesto de errores) y otro más pequeño y dinámico (denominado «rolling») se destinará a las operaciones diarias y a las alertas.
PES1.1.3 Si seguimos apoyando al grupo de Abstract Wikipedia en la redacción de un SLO (Objetivos de nivel de servicio) para el proyecto de Wikifunciones, aprenderemos a definir una lista de objetivos SLO (junto con sus métricas de indicadores de nivel de servicio) para una función compleja que se está añadiendo actualmente a un flujo de trabajo crítico para los usuarios: la representación de artículos de Wiki. También aprenderemos a visualizar correctamente los presupuestos de errores relacionados y a alertar sobre ellos utilizando los paneles y monitores proporcionados por SRE.
PES1.1.4 Si apoyamos al grupo de la Plataforma de Datos con la revisión y la iteración de los Objetivos de Nivel de Servicio (SLO) para el proyecto Historial de Contenido de MediaWiki, aprenderemos cómo aprovechar los SLO para respaldar la propiedad del servicio cuando se coordinan conjuntamente servicios de procesamiento por lotes y en flujo para actualizar el conjunto de datos, manteniéndolo coherente y disponible para los usuarios finales.
PES1.2.1 Si creamos tres mejoras específicas para la lista de deseos, fomentaremos un aumento del 30 % en el número de participantes únicos en la lista de deseos.
PES1.2.2 Si clasificamos los deseos entrantes y asignamos un responsable (por ejemplo, un gerente de producto) en un plazo de 72 horas (incluyendo rechazar, aclarar, indicar servicios sin mantenimiento, etc.), cotejando los nuevos deseos con la tabla de responsables y asignando una «categoría de responsable» al equipo de producto o persona más relevante, los responsables (por ejemplo, los gerentes de producto) podrán evaluar y responder a los deseos en un plazo máximo de 10 días.
PES1.2.3 Si ponemos en marcha una iniciativa piloto para identificar las necesidades generales de la comunidad, incorporaremos más opiniones de voluntarios en nuestros esfuerzos por establecer prioridades basadas en la información proporcionada por la comunidad.
PES1.2.4 Si ponemos a prueba un proceso trimestral de revisión de deseos y opiniones de la comunidad con tres equipos en el primer trimestre, involucraremos a los gerentes de producto para que integren las opiniones de la comunidad en sus procesos de planificación trimestral y anual.
PES1.3.1 Si, al final del primer trimestre, coordinamos tres sesiones de planificación funcional con el departamento de Comunicaciones y los equipos de producto para armonizar los mensajes, las necesidades creativas y los plazos de las campañas para las iniciativas WP25, entonces finalizaremos los resúmenes creativos para los tres experimentos de campaña (25YiR, Easter Eggs, WikiRun).
PES1.3.2 Si creamos un comité directivo con representantes de Diseño e Ingeniería de Funcionalidades, podremos definir métricas de referencia sobre las contribuciones para Codex: conocimiento, uso, calidad de las contribuciones y cantidad. La información obtenida al evaluar estas métricas de referencia nos ayudará a determinar una hoja de ruta para fomentar el crecimiento y la diversificación de la base de colaboradores de Codex.

Q2

El segundo trimestre (Q2) del plan anual comprende de octubre a diciembre.

Hipótesis sobre las experiencias wiki (WE)

[ Resultados Clave sobre las experiencias wiki (WE) ]

Discusión

Abreviatura de la hipótesis Texto del primer trimestre Detalles y discusión
WE1.1.1 Si analizamos un conjunto predeterminado de indicadores líderes igual o mayor a 2 semanas después del inicio de la prueba A/B de Paste Check, podremos identificar qué facetas - si hubiera alguna - de la experiencia punto-a-punto deben ser ajustadas o investigadas antes de tener confianza para evaluar el impacto de la funcionalidad.
WE1.1.4 Si desplegamos Reference Check en la Wikipedia en inglés mediante un experimento controlado, veremos un incremento igual o mayor al 4% en las ediciones constructivas que publiquen las personas voluntarias más nuevas, y podremos aprender si existe suficiente apoyo entre los patrulleros y moderadores para habilitar la funcionalidad para un mayor público.
WE1.1.7 Si analizamos un conjunto predeterminado de indicadores líderes 2 o más semanas después del inicio de la prueba A/B de Tone Check, podremos identificar qué facetas - si hubiera alguna - de la experiencia punto-a-punto deben ser ajustadas o investigadas antes de tener confianza para evaluar el impacto de la funcionalidad.
WE1.1.8 Si aplicamos el modelo de Tone Check a los artículos publicados, podremos saber si podemos identificar los más de 10,000 problemas de tono (cada uno con un puntaje de probabilidad de 0.8 o mayor) que se necesitan para construir un conjunto de sugerencias de alta calidad (con al menos un 70% de precisión) para ayudar y guiar a las personas editoras a mejorar el tono de un artículo.
WE1.1.10 Si entregistamos a aproximadamente 10 personas voluntarias en la Wikipedias en inglés y francés que escriben filtros de abuso (además de otros gadgets/scripts/plantillas/noticificaciones de edición) a fin de automatizar los flujos de trabajo de patrullaje y moderación, identificaremos al menos 3 patrones o necesidades que nos ayudarán a dar forma a la propuesta de valor de las Revisiones de Edición (Edit Checks) realizados por la comunidad.
WE1.1.11 Si distribuimos la encuesta a al menos 500 personas recién llegadas con éxito[i] y obtenemos datos de alta calidad que representen la población general de personas novatas, podremos identificar 4 o más ideas prácticas que podremos saber a qué aspectos de la experiencia de incorporación debemos darle prioridad para mejorar.
WE1.1.12 Si permitimos a 3 o más personas voluntarias que evalúen 30 o más ediciones muestra cada una, en cada uno de los 10 idiomas en donde buscamos escalar Tone Check, aprenderemos con qué frecuencia las personas voluntarias coinciden con las predicciones del modelo y podremos decidir a qué nuevas wikis podemos acercarnos para implementar Tone Check.
WE1.1.13 Dado que aumentamos "Add a Link" [Agrega un Enlace] al 100% de personas voluntarias nuevas en la Wikipedia en inglés, después la activación constructiva y retención de personas novatas mejorará, lo que a su vez aumentará las ediciones constructivas hechas por personas novatas en 4% o más.
WE1.2.3 Si removemos el requisito actual de tener los derechos de Organizador de Evento para usar la herramienta de Registro de Eventos en wikis de tamaño pequeño y mediano, entonces veremos al menos X más eventos* creados en wikis de tamaño pequeño y mediano para el final del año fiscal.
  • Pendiente de cálculos de números base y objetivo.
WE1.2.4 Si iteramos sobre el Producto Mínimamente Viable de Contribuciones Colaborativas con al menos 2 mejoras, entonces vermos más colaboraciones creadas a través de la herramienta de Registro de Eventos.
WE1.2.5 Si establecemos una estrategia de adopción de la herramienta de Registro de Eventos en Wikimedia commons al inicio del segundo trimestre, podremos ponerla a prueba con organizadores de al menos 1 campaña de gran escala y habilitaremos a 5 personas organizadoras locales para usar la función.
WE1.3.3 Si lanzamos un experimento para mostrar el panel de moderador a personas editoras nuevas, el 10% de contribuyentes que lo visiten lo harán dos semanas seguidas.
WE1.4.1 Si realizamos mejoras definidas en T396489, reduciremos las solicitudes a Cambios Recientes en al menos 30% en las wikis más grandes, lo que le permitirá al equipo de Tecnología Comunitaria implementar las Etiquetas de la Lista de Seguimiento sin sobrecargar la base de datos de Cambios Recientes.
WE1.4.3 Si analizamos los cambios recientes y la lista de seguimiento, entonces podremos definir una base para saber con qué frecuencia las personas hacen clic en las páginas.
WE1.5.1 Si implementamos un panel para explorar 7 métricas de contribución y estandaruzamos el cálculo de al menos una métrica usando dbt, entonces podremos habilitar a los equipos de productos del contribuidor para auto-servirse de perspectivas sobre las métricas y a desarrollar un estándar para almacenar la lógica de cálculo de métricas.
WE1.5.2 Si determinamos en el segundo trimestre qué acciones de moderación incluir en la definición de quién es un Moderador, entonces el equipo de Perspectivas del Movimiento podrá construir la métrica de Moderadores Activos por Mes en el tercer y cuarto trimestres.
WE2.1.3 Si aprendemos acerca de la experiencia de edición al crear nuevos artículos y secciones (incluyendo las motivaciones, puntos de dificultad, y reacciones a nuevas ideas acerca de cómo ayudarles), entonces podremos descubrir las necesidades y comportamientos de los usuarios y usuarias que nos den a su vez ideas prácticas y estrategias que informarán al producto, diseño e ingeniería de mejoras a la experiencia de creación de artículos.
WE2.2.12 Si implementamos Wikifunciones en wikis que tengan habilitado Parsoid, podremos continuar probando si el sistema se mantiene funcional y útil en implementaciones cada vez más amplias.
WE2.2.13 Si socializamos la disponibilidad de lafuncionalidad de la tabla de conjugación con la comunidad de Wikcionario, podremos obtener retroalimentación valiosa acerca del uso de la función, así como perspectivas sobre nuestras personas de usuario que podremos aplicar en futuras implementaciones.
WE2.2.14 Si analizamos en Databox el trabajo comunitario en el uso de Wikidata para fichas (infoboxes) e investigamos si podrían ayudar las Wikifunciones, entonces podremos identificar un primer experimento para las Wikifunciones en las fichas.
WE2.2.15 Si creamos conciencia en la comunidad acerca de la capacidad de crear y traducir mensajes de error en Wikifunciones, veremos un aumento en el número de mensajes de error útiles.
WE2.2.16 Si realizamos demostraciones de funciones semánticas disponibles a la comunidad, veremos un aumento de las funciones gramaticales en un 50%.
WE2.2.17 Si ofrecemos un componente personalizado para ver las declaraciones de Wikidata en Wikifunciones, las personas usuarias podrán entender mejor los datos obtenidos de Wikidata y sentirse así menos abrumadas.
WE2.2.18 Si podemos evitar los picos en los que el consumo de memoria se multiplica por 10, el orquestador podrá manejar mejor los objetos de Wikidata, apoyando la utilidad de Wikifunciones como una plataforma para la Abstract Wikipedia.
WE2.2.19 Si habilitamos a las personas usuarias a compartir enlaces directos a llamadas específicas de funciones - incluyendo sus datos de entrada - los contribuyentes podrán reproducir, verificar y discutir los comportamientos de las funciones con mayor facilidad, lo que a su vez acelerará la depuración de errores, mejorará los flujos de trabajo de pruebas, y apoyará la solución colaborativa de problemas en la comunidad de Wikifunciones.
WE2.3.1 Si completamos la decisión de crear una nueva wiki y decidimos con la comunidad un nuevo nombre, podremos socializar con mayor alcance la creación de esta nueva wiki con nuestras partes interesadas y nos prepararemos para la logística de un potencial cambio de nombre de producto.
WE2.3.2 Si definimos un Producto Mínimo Viable para un prototipo de wiki abstracta que incluya la experiencia más básica posible para probar nuestras capacidades de back-end y NLG, y que nos permita diseñar de forma iterativa, podremos planear y desplegar un prototivo en el tercer trimestre.
WE2.3.3 Si comenzamos a dialogar con la comunidad y a explorar diseños potenciales para la experiencia de usuario en una wiki Abstracta, podremos continuar el trabajo en el tercer trimestre.
WE2.4.1 Si recolectamos casos de uso de Wikidata y WDQS [Wikidata Query Service] provenientes de los equipos de la WMF y WMDE, podremos definir los requisitos de producto para las mejoras de infraestructura.
WE2.4.2 Si producimos una vista de reporte agregada de los indicadores clave de desempeño (KPIs) con los objetivos de niveles de servicio (SLOs) para Wikidata y WDQS, podremos articular y monitorear los criterios de éxito de las mejoras a la infraestructura técnica que apoyan los casos de uso críticos de Wikidata.
WE2.4.3 Si podemos, durante el trimestre, evaluar y establecer puntos de referencia de alternativas de Blazegraph usando criterios realistas de producción, podremos tomar una decisión sobre la migración basada en datos, y establecer un plan concreto con requisitos de tiempo y recursos definidos.
WE3.1.1 Si realizamos una prueba A/B sobre una versión mejorada de la funcionalidad de navegación por pestañas, veremos un aumento del 5% en usos múltiples diario entre usuarios de Pestañas.
WE3.1.3 Si ofrecemos a las personas usuarias una nueva forma de navegar el contenido relevante de imágenes dentro de los artículos, y lo probamos con un subconjunto de personas lectoras que no han iniciado sesión mediante una prueba A/B en varios wikis, veremos al menos una tasa de click-through de al menos 3% entre las personas usuarias a las que se les presenta esta funcionalidad.
WE3.1.4 Si mostramos a las personas lectoras varios conceptos para navegar la red de conocimiento en las wikis, podremos establecer una lista de conceptos que deben recibir más desarrollo, ordenada por prioridad.
WE3.1.5 Si ofrecemos a las personas lectoras en web la opción de ver la traducción automática de cierto contenido Wikipedia no disponible en su idioma, sabremos si la actividad de lectura aumenta, medida como un aumento del 3% en las interacciones de página, llevando a las personas lectoras al wiki del idioma local con un aumento potencial en la actividad de edición local. Esto se ofrecerá como un ajuste controlado de prueba A/B durante no más de 6 meses, y en 13 Wikipedias con consentimiento previo, usando servicios de traducción automática previamente disponibles para las personas editoras de Wikipedia.
WE3.1.6 Si producimos un prototipo de búsqueda semántica y de preguntas-y-respuestas dentro del artículo, en forma de una demostración de interfaz que ponga en contraste la funcionalidad actual y las nuevas funciones exploradas, entonces los equipos de Lectura podrán evaluar cualitativamente el desempeño de cada funcionalidad en distintos viajes de usuario, y podran poner de relieve las brechas u oportunidades que requieran más iteraciones.
WE3.1.7 Si revisamos las investigaciones existentes acerca de cómo las personas lectoras interactúan con las herramientas de búsqueda y navegación en Wikipedia, así como la forma en la que usan las herramientas externas de búsqueda para encontrar conocimiento en Wikipedia, entonces podremos ofrecer a los equipos de Lectura con 3 o más recomendaciones y perspectivas prácticas que les ayudarán a establecer el alcance de un Producto Mínimo Viable de descubrimiento para disminuir las brechas de las expectativas y necesidades del público lector.
WE3.1.8 Si evaluamos 2 prototipos de búsqueda semántica (búsqueda por lenguaje natural, preguntas y respuestas) con participantes externos, podremos aprender si las personas usuarias ven algún valos en las herramientas mejoradas de búsqueda, y podremos ofrecer a los equipos de Búsqueda recomendaciones acerca de cómo continuar con un Producto Mínimo Viable de búsqueda y descubrimiento.
WE3.1.9 Si realizamos un estudio en el que mostramos conceptos de diseño de alta fidelidad que apoyen el descubrimiento de contenidos mediante búsqueda temática en 10-20 personas lectoras casuales de Wikipedia, entonces vermos sentimientos positivos hacia la funcionalidad y ganaremos la confianza necesaria para continuar con un Producto Mínimo Viable de búsqueda y descubrimiento que se basa en muestras muestras de escritos cortos escritos por seres humanos en los términos de búsqueda.
WE3.1.10 Si mostramos a 10 personas lectoras casuales de Wikipedia un prototipo en vivo de la nueva experiencia de navegación de imágenes en un estudio de usuarios no moderados, podremos reconocer al menos una mejora a la UX (Experiencia de Usuario) para las futuras iteraciones de la funcionalidad.
WE3.1.11 Si relajamos el requisito de exactitud de las palabras clave de la búsqueda, entonces podremos apoyar mejor las búsquedas en lenguaje natural y le permitiremos al equipo de Productos la evaluación de esta capacidad, además de que podrán incluirla en sus diseños, prioridades y entregables en el área de búsqueda semántica.
WE3.1.14 If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3) T409163
WE3.2.5 Si introducimos una funcionalidad de Resumen del Año en Android que resalte el impacto del usuario o usuaria e incluya mensajes a los donantes, entonces alentaremos el comportamiento de nuevas donaciones y veremos un incremento del 5% en el menú de aplicación en comparación con 2024.
WE3.2.6 Si creamos que las diapositivas de donantes en el Resumen del Año en iOS sean más integrales y personalizadas, veremos un aumento del 5% en donaciones en comparación con 2024.
WE3.3.3 Si introducimos al menos un avatar desbloqueable en la aplicación de Android para personas con cuentas registradas—y obtenido a través de acciones significativas de lectura como guardar un cierto número de artículos—entonces aumentaremos en un 10% la participación repetida asociada con la acción asociada por parte de las personas usuarias, a lo largo de varios días.
WE3.3.4 Si le damos a las personas lectoras con sesión iniciada la capacidad de aguardar artículos en una lista privada de lectura, entonces podremos esperar que la participaciń en el sitio aumente, medida como un aumento de 5% en el tráfico de referencias internas para las personas que usen dicha funcionalidad, y un aumento estadísticamente significativo para todas las personas usuarias.
WE3.3.6 Si ponemos a disposición pública los datos inferenciales de temas de artículos mediante un servicio que cumpla con requisitos previamente acordados de escalabilidad y disponibilidad, además de los rellenos de datos necesarios, entonces habremos establecido las bases técnicas necesarias para apoyar cualquiera de las experiencias personalizadas del lector próximas a ser lanzadas, siempre que dichas experiencias dependan de estos datos.
WE3.3.7 Si aprovechamos las capacidades de procesamiento de la plataforma de datos para agregar métricas de edición personalizadas y datos de impacto, y ofrecemos estos datos agregados mediante servicios con SLOs definidas, entonces podremos mejorar las siguientes iteraciones del Resumen del Año en WE3.3.1 y la Pestaña de Actividades WE3.3.2.
WE3.3.9 Si lanzamos la funcionalidad de Resumen del Año en Android y hacemos una prueba A/B en la que se ofrecerán a usuarios involucrados una recompensa para guardar una lista personalizada de lectura, entonces observaremos un incremento del 1% en la tasa de retención general de la aplicación entre las personas a quienes se les ofreció la recompensa, en comparación con quienes no tuvieron dicha oferta.
WE3.3.10 Si hacemos una prueba A/B que requiera de una cuenta para ver las estadísticas de lectura del Resumen del Año, entonces veremos un incremento del 1% en la tasa de retención general entre las personas a quienes se les requirió tener una cuenta, en comparación con quienes no tuvieron dicho requisito.
WE3.3.11 Si realizamos una prueba A/B sobre una versión mejorada de la pestaña de "Actividad" en iOS que resalte los comportamientos de lectura y edición entre otros, entonces veremos un aumento del 5% en las visitas de varios días a dicha pestaña por parte de las personas con sesión iniciada, en comparación con la versión prototipo.
WE3.4.1 Si trabajamos hacia el desplieque del punto híbrido de presencia (PoP/CDN), esto nos permitirá poner en marcha PoPs completos y mini PoPs (en físico y en la nube) según se requiera, estableciendo las bases para el despliegue de mini PoP prototipos en el futuro.
WE3.5.1 Si los equipos de Producto y Tecnología junto con el equipo de Recaudación de Fondos evalúan y documentan de forma colaborativa los enfoques técnicos de identificación de donantes en nuestras plataformas, entonces podremos recomendaro soluciones a corto y largo plazos que equilibren la privacidad, viabilidad y el impacto. Este entendimiento cmpartido ayudará a alinear las tomas de decisión, permitirá el reconocimiento persistente de donantes en todas las plataformas y aumentará la experimentación enfocada en futuras funcionalidades de recaudación de fondos.
WE3.6.3 Si involucramos a las comunidades en las conversaciones acerca de las necesidades cambiantes de la población lectora, y en las que traten sobre la naturaleza cambiante del conocimiento en internet, entonces podremos construir un enfoque compartido sobre cómo servir a la población lectora y trabajar en equipo acerca de cómo y cuándo se podrían probas nuestras varias deas (incluyendo las que se refieren a multimedios, busca y descubrimiento, y aprendizaje automático).
WE3.6.4 Si investigamos las diferentes motivaciones, comportamientos y necesidades relativas a cómo y cuándo la población lectora usa Wikipedia y otras plataformas de conocimiento, entonces podremos proponer áreas prioritarias e iniciativas específicas para la estrategia de consumo.
WE3.6.5 Si los equipos de Producto y Tecnología, junto con el equipo de Recaudación de Fondos colaboran en una estrategia compartida de diversificación de oportunidades de donación en la plataforma, y gestionan y reconocen a las personas donates, entonces podremos establecer metas claras y alineadas, además de métricas vinculadas a nuestras estrategias de consumo y recaudación de fondos.
WE3.6.6 Si desarrollamos una estrategia unificada de medición, podremos habilitar la evaluación de la estrategia multianual de consumidores y definiremos una ruta que guíe el desarrollo de métricas y las capacidades de reporteo de informes.
WE4.1.1 Si creamos un prototipo de flujo no urgente mínimamente viable, y mantenemos un ciclo iterativo de retroalimentación a medida que lo desarrollamos con las personas usuarias con derechos extendidos, entonces estos grupos apoyarán el despliegue expandido de este flujo.
WE4.1.3 Si actualizamos a 7 Wikipedias (en francés, alemán, español, húngaro, italiano, polaco y portugués) para finales de octubre, entonces habremos completado la fase 1 del nuevo lanzamiento del Pie de Página Legal en respuesta a los requisitos de DSA.
WE4.1.4 Si implementamos el Producto Mínimo Viable del Sistema de Reporte de Incidentes en al menos 15 wikis, con un enfoque en las comunidades más grandes y complejas, entonces observaremos su uso como se pretende por la comunidad, y habremos demostrado un modelo funcional para el reporteo no de emergencia de incidentes.
WE4.1.5 Si diseñamos un diagrama de flujo para reportar incidentes de abuso en las wikis sin un proceso establecido de manejo de abusos, esto animará la adopción del Sistema de Reporte de Incidentes en estas wikis y permitirá a las personas usuarias de dichas wikis tener una vía de apoyo clara y viable.
WE4.2.3 Si analizamos los datos de la prueba de creación de cuentas con hCaptcha, entenderemos el embudo de creación de cuentas, la eficiencia de los acertijos y puntajes de hCaptcha, y tendremos los datos necesarios apara informar los subsecuentes despliegues de hCaptcha en la creación de cuentas.
WE4.2.5 Si realizamos investigaciones, consultamos con las comunidades e investigamos soluciones técnicas, podremos definir un conjunto de razones estructuradas de bloqueos que pueda ser usado en todas las wikis de la WMF.
WE4.2.6 Si desarrollamas la capacidad de desplegar clústeres en la plataforma de datos basados en OpenSearch, los equipos de ingeniería de funcionalidades de productos tendrán la capacidad de desarrollar sistemas que integren dicha capacidad, con un alto grado de autonomía, resiliencia y aislamiento con respecto a otros sistemas basados en búsqueda. El primer y principal componente de este sistema será el servicio de IPoid.
WE4.2.7 Si implementamos la integración de hCaptcha Enterprise en varias Wikipedias en producción como prueba piloto, entonces podremos recolectar datos sobre la eficiencia y valor de hCaptcha Enterprise en cuanto a la defensa contra el abuso, detección de bots, usabilidad y accesibilidad.
WE4.2.8 Si hacemos que el proxy de hCaptcha esté listo para producción mediante la mejora de su disponibilidad y observabilidad, entonces ofreceremos un servicio más estable y confiable a las Wikipedias en producción en el primer trimestre.
WE4.2.9 Si integramos el SDK (Kit de Desarrollo de Software) de hCaptcha en las aplicaciones móviles nativas, y evaluamos la experiencia de usuario de dichas aplicaciones y evaluamos los desafíos de habilitar los retos de hCaptcha como parte de la API de creación de cuentas, entonces tendremos suficiente comprensión para informar el despliegue posterior de hCaptcha en la API de creación de cuentas.
WE4.2.11 Si habilitamos a hCaptcha para detectar bots en escenarios de edición de alto riesgo, veremos si hCaptcha es capaz de reducir los abusos automatizados.
WE4.2.16 Si consultamos con los equipos relevantes de la Fundación, podremos desarollar un plan acordado sobre el acceso más granular de usuarios a datos no públicos, y apoyaremos el desarrollo de reglas de software defensivo no público.
WE4.2.17 Si analizamos ejemplos reales y entrevistamos a personas con privilegios de CheckUser para identificar al menos 2 señales de comportamientos potencialmente abusivos del prototipo de historial del editor, el equipo de Seguridad e Integridad del Producto podrá incorporar estas señales a la funcionalidad de Investigaciones Sugeridas con un nivel de confianza mayor de que las señales serán de valor.
WE4.3.2 Si implementamos las huellas digitales JA4H, que resumen el comportamiento de un cliente HTTP, tendremos una mejor capacidad para entender y categorizar el tráfico de bots.
WE4.4.1 Si podemos implementar mejoras basadas en la retroalimentación de los programas piloto y lanzamos las Cuentas Temporales a todos los proyectos entonces seremos capaces de proteger la exposición de información de identificación personal (direcciones IP) de personas que no hayan iniciado sesión en todos los proyectos, reduciendo dicha exposición a menos del 0.1% de todas las personas usuarias (registradas).
WE4.4.2 Si comunicamos a las partes interesadas relevantes del movimiento (incluyendo las comunidades de las wiki y los funcionarios globales) de forma clara y oportuna, podremos implementar cambios en todas las wikis restantes, reducir la carga de trabajo imprevista, y evitar tener que hacer reversiones de implementación.
WE4.4.5 Si reducimos la fricción para que los patrulleros identifiquen a malos actores que usan cuentas temporales para vandalizar, entonces podremos prevenir un aumento en el vandalismo al no medir aumentos en la tasa de reversión en todas las wikis con cuentas temporales.
WE4.4.6 Si retiramos la extensión LiquidThreads, podremos desbloquear el despliegue de las Cuentas Temporales en todos los proyectos que aún usan dicha extensión.
WE4.6.1 Si automatizamos el proceso de sincronización de cuentas dentro de Zendesk para reestablecer contraseñas, esto reducirá la carga de trabajo del equipo de Confianza y Seguridad y les permitirá manejar más solicitudes entrantes de reestablecimiento de 2 Factores de Autenticación.
WE4.6.3 Si le permitimos a todas las personas usuarias con una cuenta confirmada de correo electrónico el poder habilitar 2FA en sus cuentas, pero no anunciamos este cambio de forma proactiva a las personas usuarias, la carga de trabajo de nuestro equipo de servicio se mantendrá en niveles sustentables.
WE4.6.4 Si continuamos nuestra revisión de la experiencia de usuario en el sistema 2FA y agregamos soporte para claves de acceso, entonces más personas podrán registrar múltiples factores de autenticación y estarán mejor protegidas contra la pérdida de acceso a dicha cuenta.
WE4.6.5 Si diseñamos y construimos un marco general para especificar requisitos que deben cumplir los integrantes de un grupo local o global, podremos usar este marco para validar que los integrantes del grupo que puede ver las direcciones IP de las cuentas temporales cumplen en verdad los requisitos de política existentes.
WE4.6.6 Si investigamos cómo las personas con derechos extendidos (UWER por sus siglas en inglés) dependen de los User Scripts, entonces podremos proponer un plan, que la comunidad UWER podría apoyar, para realizar una o más intervenciones técnicas significativas que podrían asegurar de forma significativa el sistema de User Scripts.
WE4.6.7 Si evaluamos la experiencia de usuario y los retos técnicos que las aplicaciones móviles necesitan para alinear la experiencia de inicio de sesión con la plataforma web, mediante la exploración de mecanismos alternativos como OAuth, podremos determinar la viabilidad de la integración, en pos de ofrecer una experiencia más segura y consistente para las personas usuarias.
WE4.6.8 Si monitoreamos el impacto de los formularios de Zendesk y MediaWiki que hicimos en el primer trimestre, entonces podremos proponer intervenciones técnicas para los siguientes cuatrimestres que puedan automatizar mejor el resto del proceso de recuperación de cuentas.
WE5.1.2b Si integramos mútiples métodos de identificación y autenticación de desarrolladores en la gateway de la API, entonces podremos asignar un límite de uso apropiado a cada solicitud, identificando correctamente las solicitudes que vienen de distinos grupos de usuarios.
WE5.1.3b Si realizamos un simulacro de limitación de acceso en al menos 3 rutas de la gateway REST, esto nos permitirá verificar la viabilidad de limitar el acceso con respecto al consumo de recursos y definir un conjunto inicial de límites que puedan hacerse cumplir con un impacto mínimo a las personas usuarias.
WE5.1.4b Si validamos los mecanismos de segmentación de usos de la API con conjuntos de datos más amplios y revisiones manuales de los grupos identificados, entonces podremos finalizar las cohortes de usuarios, refinar las metodologías de cálculos y entenderemos mejor su eficacia.
WE5.1.5 Si colaboramos con el equipo de Plataforma de MediaWiki en la identificación de tráfico y limitación de velocidad, entonces podremos implementar los límites de acceso en simulacros en ambientes productivos, al apoyar al equipo de Plataforma en la creación y despliegue de esta funcionalidad.
WE5.2.1b Si involucramos a los posibles usuarios del nuevo Explorador de la API REST, esto nos ayudará a identificar ideas clave de usabilidad que indicarán si el nuevo diseño es fácil de usar y está alineado con el modelo mental de los desarrolladores.
WE5.2.2b Si enrutamos la API de Acción a través de la gateway de la API central, podremos comenzar a medir constantemente los patrones de tráfico y uso para obtener perspectivas que informarán nuestras decisiones y acciones futuras.
WE5.2.4 Si implementamos patrones estándar de documentación para 2 APIs, podremos refinar los lineamientos de contenido, entender lo que los dueños de las APIs requieren para adoptar dichos lineamientos, y cuantificar el esfuerzo necesario para implementar dichos lineamientos en la documentación restante de las APIs de Wikimedia.
WE5.2.5 Si experimentamos con la definición y aplicación de reglas de escritura de especificaciones de OpenAPI a las APIs REST de MediaWiki, entonces demostraremos una forma de hacer cumplir programáticamente las guías de estilo de APIs para mejorar la calidad y consistencia de APIs publicadas en todo Wikimedia y nuestras comunidades.
WE5.3.1 Si aumentamos y optimizamos los lineamientos de atribución de UX a medida que actualizamos los lineamientos existentes, podremos establecer un conjunto central de lineamientos mejorados listos para ser probados internamente y refinados en iteraciones subsecuentes en preparación al uso del público en general.
WE5.3.1b Si publicamos e iteramos los lineamientos y demostraciones piloto de UX, podremos establecer un marco central listo para ser probado internamente y perfeccionada en interaciones subsecuentes en preparación al uso del público en general.
WE5.3.2 Si creamos una presentación que demuestre a terceros y usuarios finales los beneficios de atribuir a Wikipedia al reusar su contenido, podremos apoyar WME4.1 y WME4.2 al habilitar que al menos un socio adicional de reuso acepte aparecer aparecer en un caso de estudio o demostración de atribución para el final del primer trimestre.
WE5.4.2b Si construimos una forma escalable de identificar a clientes conocidos, podemos hacer excepciones a las limitantes de velocidad para los bots de origen verificado, y avanzar así hacia la aplicación sistemática de nuestras reglas.
WE5.4.5 Si comenzamos a hacer cumplir los límites de velocidad establecidos par distintas clases de clientes individuales, reduciremos la carga de trabajo de rastreo de sitios en nuestra infraestructura.
WE5.4.6 Si para finales del segundo trimestre hemos clasificado los principales N arañas como bots conocidos, podremos restringir la cantidad de recursos que están usando.
WE5.4.7 Si establecemos un conjunto estándar de tamaños permitidos de miniaturas de imagen en nuestra infraestructura de medios, y pre-generamos las más costosas a medida que establecemos límites de velocidad a la generación de imágenes de distintos tamaños, podremos reducir la carga en la infraestructura de servicios de medios.
WE6.1.2 Si agregamos servicios de alojamiento de wikis a un ambiente de pruebas previo a la fusión esto permitirá a los equipos de desarrollo que trabajan en producción y requieren múltiples wikis, que tengan múltiples wikis en las que puedan probar sus parches de forma aislada, lo cual les dará una mayor confianza previa a la producción y resultará en una reducción de fallos que pasan desapercibidos.
WE6.2.1 Si revisamos y publicamos nuestra Lista de Control de Preparación de la Producción que defina claramente los pre-requisitos para que un servicio pueda considerarse listo para entrar en producción, junto con tareas autoservicibles, podremos alinear las expectativas entre los equipos de SREs y de desarrollo, mejorando nuestra eficiencia y escalabilidad operativas.
WE6.2.2 Si anunciamos la creación de librerías de Golang y nodejs que abstraiga muchas tareas laboriosas de desarrollo, entonces estos equipos responderán ofreciendo retroalimentación y mostrando interés.
WE6.2.4 Si solicitamos y apoyamos activamente la revisión de diseño de Persistencia de Datos, podremos identificar vías apropiadas a la producción.
WE6.3.2 Si desarrollamos nuevas métricas, mejoramos la infraestructura del caché de Parsoid y desplegamos en dos de las diez Wikipedias más grandes, podremos desarrolar criterios de desempeño que nos ayudarán a validar nuestra preparación para la implementación en otras wikis de gran tamaño y demostrarán nuestra habilidad de manejar grandes volúmenes de tráfico a gran escala.
WE6.3.3 Si implementamos mejoras críticas de apoyo a las Variaciones de Idiomas, e implementamos Parsoid exitosamente a al menos 3 wikis con variaciones de idiomas en el segundo trimestre, podremos identificar y resolver los retos técnicos clave necesarios para implementar en todas las demás Wikis con Variaciones de Idioma.
WE6.4.6 Si SRE nos proporciona asistencia a los equipos de ingeniería de MediaWiki—mediante la gesticón de capacidad y tráfico, preparación y revisión de cambios de configuración, y colaboración para investigar y solucionar problemas—entonces podremos completar juntos la actualización a PHP 8.3 en el segundo trimestre y documentaremos un conjunto de recomendaciones para minimizar las dependencias de ruta crítica en SER para las futuras actualizaciones. T360995
WE6.4.7 Si migramos al menos al 90% de usuarios y usuarios con acceso global a la raíz para que usen una clave SSH respaldada por hardware para acceder a servidores de producción de Wikimedia, reduciremos el riesgo de que una laptop comprometida cause una grave violación de seguridad.
WE6.4.8 Si el equipo de Ingeniería de MediaWiki monitorea activamente y resuelve problemas en MediaWiki relacionados con la actualización de PHP, esto permitirá al equipo SRE completar la actualización de producción a PHP 8.3 para noviembre de 2025. T360995
Hipótesis sobre los Servicios de Señales y Datos (SDS)

[ Resultados clave de SDS ]

Discusión

Abreviatura de la hipótesis Texto del segundo trimestre Detalles y discusión
SDS1.2.1 Si migramos el proceso de Volteado de XML de la infraestructura actual 'Dumps 1' a un canal de datos que aproveche los Canales de Contenido de Mediawiki, podremos garantizar el cumplimiento de los SLOs y desactivar la exportación de datos XML basada en 'Dumps 1'.
SDS1.2.2 Si hacemos un recorrido y revisión de los SLOs para el Historial de Contenidos y Plataforma de Eventos / Puerta de Eventos de Wikimedia, podremos validar a los clientes, métricas y partes interesadas dependientes, además de poder identificar mejoras que podrían ser necesarias para entregar los SLOs, lo cual nos ayudará a aclarar cualquier brecha en nuestras garantías semanales de entrega.
SDS1.3.1 Si introducimos señales del lado del cliente y las auditamos en comparación con los registros de solicitudes web del lado del servidor, podremos encontrar patrones adicionales de bots que puedan ser caracterizados.
SDS1.3.2 Si asumimos a la distribución actual de bots vs humanos como base y creamos alertas automatizadas para cambios en dicha distribución, disminuiremos los tiempos de detección del siguiente patrón imprevisto de tráfico automatizado, reduciéndolo de semanas a minutos.
SDS1.3.3 Si automatizamos el mecanismo de retroalimentación para las solicitudes web y lo usamos en los registros de mayo, disminuiremos el tiempo de remediación de incidentes futuros, reduciéndolo de meses a días, y resolveremos el incidente de "aumento de vistas de página en mayo".
SDS1.3.4 Si creamos un proceso regular de auditoría interna operativa para los resultados de clasificación de bots, podremos construir confianza en nuestras soluciones y anticiparemos cambios a los patrones de tráfico que no sean detectados automáticamente.
SDS1.3.5 Si analizamos las señales básicas del lado del cliente y las incorporamos en nuestra heurística, podremos detectar patrones de bots adicionales en la Plataforma de Datos.
SDS1.3.6 Si importamos, analizamos e incorporamos la reputación de IPs de Spur.us a nuestras heurísticas, detectaremos patrones de bot adicionales en la Plataforma de Datos.
SDS1.3.7 Si importamos, analizamos e incorporamos a nuestras heurísticas una señal del borde, detectaremos patrones de bot adicionales en la Plataforma de Datos.
SDS1.4.1 Si reconfirmamos el análisis existente de tendencias dentro del ecosistema Wikimedia—vistas de página, métricas de contribución y lectura, tráfico, etc.—podremos apoyar con condianza los puntos de discusión salientes para nuestras perspectivas de movimiento más importantes.
SDS1.4.2 Si reconfirmamos el análisis existente de tendencias dentro del ecosistema Wikimedia—vistas de página, métricas de contribución y lectura, tráfico, etc.—podremos apoyar con ocnfianza los puntos de discusión salientes para nuestras perspectivas de movimiento más importantes.
SDS2.1.1 Si colaboramos estrechamente con los equipos que llevan a cabo experimentos, aprenderemos cómo hacer que el sistema sea más autónomo en el futuro y qué retos conceptuales o técnicos se pueden encontrar.
SDS2.1.2 Si podemos implementar una mejor depuración para el registro de eventos, entonces los equipos de productos sabrán que sus experimentos recolectan datos de eventos según lo previsto, aumentando la confianza de los responsables de dichos experimentos.
SDS2.1.3 Si mejoramos los registros y observabilidad del componente de sistema de pruebas A/B (xLab) de la plataforma de experimentación, y de sus partes relacionadas a MediaWiki, entonces podremos establecer líneas de base de desempeño del sistema y podremos responder a los fallos relacionados con los experimentos.
SDS2.1.4 Si compartimos las historias y resultados de experimentos con toda la organización una vez al mes (a través de las reuniones de Operaciones de Producto, de equipos de Diseño, y presentaciones entre equipos), entonces crearemos una adopción orgánica de la plataforma de experimentación.
SDS2.1.5 Si le informamos a la población de usuarios que su instrumento, si fue creado en xLab, contiene un conjunto de atributos que cambia la categoría de riesgo, disuadiremos a quienes usen instrumentos para recopilar datos en exceso y aumentaremos la claridad acerca de qué combinación de atriburos requiere una revisión de privacidad.
SDS2.1.6 Si los equipos de Crecimiento trabajan en instrumentar dos casos de uso (uno con una prueba A/B para ganar perspectivas acerca de las capacidades de segmentación, y uno con instrumentación a largo plazo para aprender sobre el apoyo para métricas similares a los KPIs) con el Laboratorio de Experimentos, entonces podremos evaluar sise cumplen con suficiencia los requisitos para reemplazar nuestro sistema de experimentos en GrowthExperiments.
Hipótesis de Audiencias Futuras (FA)

[ Resultados Clave de FA ]

Discusión

Abreviatura de la hipótesis Texto del segundo trimestre Detalles y discusión
FA1.1.4 [Continuado del último Año Fiscal] Si construimos una nueva experiencia de Wikipedia en Roblox, aprenderemos si esta es una forma efectiva de presentar nuestra marca a un público más joven (generación Alfa).
FA1.1.2 Si construimos un sitio centralizado para nuevas experiencias de Wikipedia en itch.io, entonces podremos hacer crecer una audiencia de al menos 50 personas no-Wikipedistas interesadas que nos darán retroalimentación, lo que nos ayudará a aprender qué funciona y qué no en cuanto a juegos.
FA2.2.1 Si invertimos en gestión comunitaria en varias plataformas de videos cortos, entonces para el final del segundo trimestre (diciembre 2025) veremos un aumento del 30% inter-trimestral en el porcentaje de vistas de Nuevas Visitas en TikTok—y en todas las plataformas de videos cortos, lograremos 50,000 involucramientos totales (likes y comentarios) en comentarios de marca dejados en contenidos externos, lo cual nos ayudará a aumentar nuestra visibilidad e impulsará el involucramiento con públicos a los que actualmente no estamos alcanzando.
FA2.2.2 Si desarrollamos y aprobamos una estrategia interna del Programa Wikipedia de Alianzas de Creadores, así como sus datos compartibles externos (incluyendo un resumen de nuestro valor a creadores de contenido, criterios de alianzas, proveso de contratación, y cómo los contenidos creados se mostrarán en varios canales), entonces podremos establecer una estrategia robusta de creación que nos permitirá alcanzar nuevos públicos en varios sitios de redes sociales con nuestros contenidos de conocimiento.
Hipótesis de Soporte de Producto e Inteniería (PES)

[ Resultados Clave de PES ]

Discusión

Abreviatura de la hipótesis Texto del segundo trimestre Detalles y discusión
PES1.1.5 Si incorporamos los Objetivos de Nivel de Servicio (SLOs) para el Historial de Contenidos de MediaWiki y Wikifunciones en Sloth/Pyrra, podremos poner 2 SLOs más en producción.
PES1.1.6 Si realizamos una prueba piloto de Sloth con datos retroactivos de SLOs existentes, entenderemos si Pyrra o Sloth (o algo más) son la herramienta adecuada para nuestro enfoque basado en ventanas fijas para las ventanas de presupuesto de errores. Aprenderemos cómo apoyar a los responsables de servicios con un enfoque de autoservicio a las métricas de SLOs, y a usarlas en la toma de decisiones.
PES1.2.4 Si realizamos una prueba piloto y un proceso de revisión de deseos y señales de la comunidad con 3 equipos en el primer trimestre, podremos involucrar a Gerentes de Productos para integrar dichas señales de la comunidad a sus procesos de planeación trimestrales y anuales.
PES1.2.5 Si agregamos la capacidad de filtrar y ordenar deseos en la extensión Wishlist a las mejoras que permiten categorizar mediante etiquetas y votos, entonces las 3 mejoras verán al menos 30% más participantes únicos en la Lista de Deseos.
PES1.3.3 Si creamos al menos 5 intervenciones de deleite en las plataformas que ocurran de acuerdo a interacciones de un usuario o usuaria, podremos definir cuáles serán las acciones que desencadenen dichas intervenciones en la página del portal y el gadget de Modo Cumpleaños. Las pruebas de usabilidad nos dirán cuáles intervenciones crean asociaciones positivas con nuestra marca. Esta hipótesis está limitada en tiempo para finalizar para cuando se celebre la WikiConferencia Norteamérica al final de octubre.
PES1.3.4 Si creamos un sitio web inmersivo que explore el pasado, presente y futuro de Wikipedia, en colaboración con integrantes del departamento de Comunicaciones, enfocado a audiencias en línea entre 18-34 años en áreas objetivo de la campaña, esto simulará una mayor conexión con Wikipedia a través de acciones sociales y otras actividades en línea. Esto apoyará al Resultado Clave de Comunicaciones de aumentar la presencia de la marca por 10 puntos porcentuales, a la vez que nos dice si este enfoque dinámico sobre el contenido realmente mejora la aceptación de la marca.

Q3

The third quarter (Q3) of the WMF annual plan covers January-March 2026.

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Discusión

Hypothesis shortname Q3 text Details & Discussion
WE1.1.3 If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
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.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.14 If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17 If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18 If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task 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.19 If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20 If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21 If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22 If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24 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 ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6 If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
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.3.4 If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
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.3 If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4 If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20 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.21 If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22 If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23 If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24 If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25 If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26 If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4 If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5 If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6 If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1 If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2 If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3 If we define a cohort of user personas to test our new backend system, we will be prepared for the pilot and subsequent phases of the Blazegraph cutover.
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5 If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
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.12 If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18 If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
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.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.2 If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
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.
WE3.6.7 If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8 If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1 If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1 If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1 If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3 If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
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.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.3c If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5 If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6 If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8 If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9 If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10 If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11 If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
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.2b If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
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.8 If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9 If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11 If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12 If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
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.1.3 If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4 If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5 By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6 By piloting the production readiness checklist on the hCaptcha proxy service against launch and high-importance items, we will identify untracked technical debt and create a visible work backlog, which will demonstrate the framework's value, while shaping a repeatable process for consistent adoption across services.
WE6.2.7 By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8 By analysing feedback from our collaboration with the SLO group, hCaptcha proxy pilot, and SRE collaboration, we will identify which checklist items and process steps require clearer guidance or supporting resources, and determine the next steps for streamlining the framework to make adoption achievable before the December break.
WE6.2.9 If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
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.3.4 If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5 If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
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 SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
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.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

Discusión

Hypothesis shortname Q3 text Details & Discussion
SDS1.5.1 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.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
Future Audience (FA) Hypotheses

[ FA Key Results ]

Discusión

Hypothesis shortname Q3 text Details & Discussion
FA1.1.1 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.
FA1.1.2 If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3 If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6 If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
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 ]

Discusión

Hypothesis shortname Q3 text Details & Discussion
PES1.3.5 If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6 If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1 If we meet with 4-5 teams that are not primarily using Codex (including, but not limited to, teams primarily using OOUI), we will be able to document blockers to those teams adopting Codex for current and future projects.
PES1.4.2 If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.1 If we upgrade Sloth from a prototype to a replacement for Pyrra, by onboarding existing services, we can converge on a unified set of SLO dashboards, refine our alerts, and streamline the SLO onboarding experience.
PES1.5.2 If we continue to onboard SLI metrics for Wikifunctions and MediaWiki Content History, and check metrics for WikiData Query Service and EditCheck, we will debug issues with both dashboard reporting and service-owner engagement on loud-but-unaddressed SLO reports.

Q4

The fourth quarter (Q4) of the WMF annual plan covers April-June 2026.

Wiki Experiences (WE) Hypotheses

[ WE Key Results ]

Discusión

Hypothesis shortname Q4 text Details & Discussion
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.5.1a If we add new metrics to the Contributors dashboard using DBT we will enable contributor product teams to get more actionable insights into editing trends
WE1.5.5 If we automate updates of DBT models with Airflow on a fixed schedule, we will allow Movement Insights to build analyses and reports on those models using up-to-date information.
WE1.5.6 If we document workflows and establish per-team default output locations and access controls for dbt models, we will allow dbt usage to scale across team members in Movement Insights and other teams.
WE1.5.7 If we extend the MAM dashboard as specified, then we will have a more complete picture of moderator pipeline health that can inform decisions in the Contributor strategy.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE1.7.2 By testing a design prototype of the in-app webview editing flow with newcomers on the mobile apps, we will identify the highest-risk friction points that could cause abandonment before publishing - specifically around context shift, editor comprehension, and edit attribution - so that we can prioritize what must be resolved before this approach can successfully onboard new editors at scale.
WE1.7.4 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.7.5 If we replace the unstructured Copyedit task with the Revise Tone structured task in a controlled experiment, then the task completion rate for Revise Tone edits made by junior editors will be higher than the completion rate for edits made through the Copyedit task.
WE1.7.6 If we test 2 structured workflows via design prototypes that align contribution opportunities with what readers arrive motivated to learn, and frame contributions as ways to act on curiosity or share knowledge they already possess, then concept testing will help us identify approaches that inspire readers to imagine themselves as contributors.
WE1.7.7 If we present an exit survey to users with ≤100 cumulative edits who abandon mobile editing sessions after spending ≥2 seconds in either the mobile visual or source editor, we will discover patterns in the reasons behind this behavior and be able to decide what interventions we will prioritize to increase the mobile web edit completion rate.
WE1.7.8 If we present junior contributors who enter the mobile VisualEditor with immediately actionable edit suggestions, then the proportion of edit sessions that result in someone publishing a constructive edit will increase by ≥10%.
WE1.7.9 If we publish a proposal on-wiki to enable VisualEditor by default for newcomers on mobile web at en.wiki, we will define the steps needed to make this happen.
WE1.8.2 If we improve the logged out edit warning, the account creation rate among newcomers on mobile exposed to the warning will increase by at least 2% relative to the control group.
WE1.8.3 If we improve the account creation form, the registration completion rate among mobile users who land on the form will increase by at least 2% relative to the control group.
WE1.8.4 If we add a user account button to the header on mobile web, then the number of new accounts created on mobile will increase by at least 2% relative to the control group.
WE1.8.5 If we surface Reading Lists to logged-out readers on mobile web, the registration rate will increase by at least 2% relative to the control group.
WE1.9.2

If we introduce key questions about factors that impact editor motivations [i] into the 2026 Community Insights survey, by the end of Q4 we will be able to provide ≥5 research insights which can inform our Contributors strategy implementation, with a focus on editor progression and recognition.

[i] Defined through the lens of competence (ability to use tools and resources), autonomy (ability to navigate the platform and make informed decisions), and relatedness (ability to join the community, feel supported and valued).

WE1.9.3 If we co-design guidance for mobile-first onboarding with at least two affiliates, by the end of June we will be able to identify which gaps are perceived by organizers as most detrimental to the retention of mobile-first newcomers.
WE1.10.3 If we work with a few selected communities to customize the Article Guidance workflow for their wikis, editors will get guidance that’s tailored to each community’s content and policies.
WE1.10.5 If we complete all path-to-production requirements for the Article Guidance A/B test (including security review, legal consultation, instrumentation, community outline review and translation, and experiment configuration) we will launch the experiment for it to run to completion before the end of Q4 and start generating statistically meaningful data on the impact of Article Guidance on the 30-day survival rate of articles created by junior editors.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.3.7 If we identify and address small but frequent friction points in contribution workflows together with early contributors, we can support and sustain the engaged core community that is building the foundational building blocks for Abstract Wikipedia.
WE2.3.8 If we implement the capabilities for article-level opt-in integration of Abstract Wikipedia content into local Wikipedias, we can demonstrate how the model works in practice and be ready to engage pilot communities in Q1.
WE2.3.9 If we implement basic instrumentation for Abstract Wikipedia (in addition to existing MediaWiki instrumentation), we will better understand how users interact with Abstract Wikipedia and identify areas for improvement.
WE2.3.10 If we support displaying images from Commons in Abstract articles via Wikifunctions, we enable communities to incorporate visual elements commonly used in Wikipedia articles.
WE2.3.13 If we build an analytical capability to map content availability, production, and consumption against a flexible topic taxonomy, then we'll have greater visibility to content trends that we can derive insights from.
WE2.3.16 If the Rust evaluator is brought to feature parity with the Node evaluator and the Node evaluator phased out, we will eliminate a huge maintenance burden and free up engineering resources.
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.6 If we develop the capability to automate output comparison between WDQS v1 and v2 for selected sets of queries, we will be able to improve confidence in the correctness of the new service.
WE2.5.7 If we assemble a plan for messaging about our migration, we will experience a smoother transition to the new endpoints by aligning with the Wikidata community on when to expect changes and how to prepare for them.
WE2.5.8 If we start to build the decoupled architecture described in our design doc, we should be able incrementally deliver value throughout the quarter and stand by a service that is able to support the pilot cohort by FY27 Q1.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention.
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
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.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.3 If we implement consent-based donor segment storage in MediaWiki and establish a reliable CiviCRM → MW sync, Product and Fundraising will be able to successfully identify and differentiate donor segments on-platform across web and apps by the end of the quarter.
WE3.5.5 If we offer logged-out donors on mobile web a persistent Thank You badge by default that triggers a brief delightful interaction upon tap (C), then we will see a 1% improvement in 21-day cumulative retention rate compared to having a badge with a simple popover message (B), and users who do not get a badge at all post-donation (A). We will also track whether a larger percentage of donors in group (C) tap on the badge again in at least one future return session compared to those in (B), to inform whether playful interactions create a re-engagement loop.
WE3.6.9 If we coordinate across identified stakeholders, we will gather the necessary information on development needs, dependencies, and timeline to create a decision brief on the consumer strategy measurement plan that gets signed off by all relevant stakeholders.
WE3.6.10 If we run an A/A test on retention rate for logged-in readers, we will establish a baseline for retention rate we can use for future quarters.
WE3.6.11 If we analyze existing data to see what user factors or actions correlate with retention, we can document our understanding of what product interventions/levers might increase retention.
WE3.6.12 If we experiment with measuring whether increasing the amount of translated Wikipedia content leads to a direct increase in pageviews, we will be able to make a recommendation on future strategic investment into translations.
WE3.7.2 If we roll out the new “heart” donate button design to all projects with a header donate link on desktop, based on the positive results of the previous clickthrough rate experiment, the total number of donations coming from that entry point will not decrease.
WE3.8.2 If we provide reading lists on web as an opt-in beta feature, as well as opt-in all new user accounts, at least 50% of users will rate the feature as useful when surveyed.
WE3.8.3 If we add a temporary 25th Birthday reading challenge widget on the apps that motivates users to meet a reading goal, we'll see a 5% higher conversion rate from casual (2-week return) to active (2-day returned) for users who joined the challenge in the first 14 days, compared to our baseline of 16.8%.
WE3.9.3 If we widely roll out the image browsing carousel and detail view on mobile web, then we will maintain CTR > 5% on the carousel.
WE3.9.4 If we test the addition of the “Which came first” daily-play trivia game to the iOS App, we’ll see 15% of engaged logged-out readers return to play the game on multiple days.
WE3.10.3 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.10.5 If we give readers an enhanced sharing option then [33%] of readers who see the dialog will complete the enhanced share action without harming logged-out reader retention.
WE3.10.6 If we redesign the mobile apps Explore Feed, we'll see a 10% practically significant increase in Explore Feed engagement over multiple days per unique logged-out reader within 14 days of release.
WE3.10.7 If we identify the most frequent and important unmet needs for casual users (as rated by them) as well as which early-stage concept ideas are most desirable and useful, we will be able to prioritize which concepts to put into A/B testing in FY26-27 to give us the best shot at increasing retention.
WE3.10.8 If we test adding Page Previews on Minerva, we will see practically significant improvement to logged-out reader retention.
WE4.6.13 If we encourage users with an unconfirmed email address to confirm their email address, then 10% of active users who receive this notification will attempt to confirm their email address.
WE4.6.16 If we build support for enforcing group membership restrictions on global groups, we will be able to use this to enforce a 2FA requirement for global groups.
WE4.6.17 If we announce and enforce 2FA requirements for an additional set of groups, the number of users who have sensitive rights but don't have 2FA will drop to 0.
WE4.6.18 If we build support for enforcing 2FA on private wikis, we will be able to use this to secure user accounts who have access to private information.
WE4.6.19 If we require reauthentication for sensitive actions and implement other hardening measures, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.20 If we proactively scan user scripts for malicious code, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.21 If we reduce the number of staff accounts with advanced rights and how long they have those rights for, attacks targeting staff accounts are less likely to cause damage.
WE4.8.1 If we introduce a mechanism that detects and surfaces related temporary accounts, including a connected-accounts panel on Special:Contributions, then patrollers will identify abusive temporary-account activity faster and more accurately.
WE4.8.3 If we investigate recent complaints about patrolling taking longer than before, we would be able to determine whether or not they are correlated with the introduction of Temporary Accounts.
WE4.10.1 If we roll out hCaptcha to more wikis (Special:CreateAccount, wikitext editor on desktop) in stages, we will increase bot detection coverage across all projects.
WE4.10.2 If we deploy the hCaptcha bot detection in the visual editing, discussion tools, file upload wizard, and mobile editing pathways on pilot wikis, we will see an increase of 35% in the percentage of actions on Wikimedia Foundation wikis that were verified by hCaptcha.
WE4.10.3 If we deploy an hCaptcha risk score collection for blocked edit notices, we will better understand collateral damage impacts of IP range blocks.
WE4.11.1 If we roll out the Incident Reporting System (IRS) on enwiki through a staged deployment, starting small and scaling to at least 50% of logged-in users, then we will have enough data from our newly instrumented metrics to determine if IRS should be adopted on enwiki.
WE4.12.1 If we optimize and compare the performance of at least 2 content policy models with a community-vetted dataset of oversighted (WP:Oversight) content from English Wikipedia, we will be able to recommend a model or combination of models for automatic oversighting or flagging of content that very likely should be oversighted.
WE4.12.2 If we host the gpt-oss-safeguard-20b, CoPE-A-9B, and CoPE-b-12b models on LiftWing and optimize each model's performance to meet the PSI team's initial evaluation requirements, then the PSI team will be able to test the three models and compare their behavior.
WE5.1.3e If we create a data product for analysis of API requests, we'll simplify analysis and segmentation of API requests, and allow Product Analytics to prototype the API Analytics Dashboard by further segmenting and aggregating this new data.
WE5.1.3f If we reduce API rate limits for requests that only provide a User-Agent, we will increase the number of authenticated and known clients, by encouraging UA-only users to move to a more responsible pathway.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.5b If we finalize the linter architecture and a core set of linting rules, we can improve the quality of OpenAPI descriptions and start introducing programmatic guarantees of their compliance into CI workflows in API development processes.
WE5.2.8b If we onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform.
WE5.2.11b If we complete API Portal documentation migration, we will be able to fully deprecate the API Portal system, which will simplify API documentation discovery, increase documentation consistency, and reduce the number of API support systems.
WE5.2.12 If we iterate on the design and discovery work required for building the unified front-door for developers early, we will be able to effectively expedite engineering work in FY26-27.
WE5.2.13 If we begin enforcing existing user-agent policies on the dumps website, we can better understand dumps users and use cases while ensuring more consistent access expectations across developer pathways.
WE5.3.2b If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.3.3 If we provide content reusers with canonical, low-friction retrieval paths, we will lower the effort required to adopt trust signals from Wikimedia’s Attribution Framework, avoid the standardization of suboptimal retrieval paths, and unlock our ability to reliably measure attribution adoption.
WE5.3.3b If we build a data pipeline to compute unique contributor counts and develop a method to serve it to MediaWiki, we will be able to surface contributor counts as a signal to Attribution API users.
WE5.3.3c If we design and implement an API and event stream offering a naive, pageviews-based "relative trending" metric for pages, we will allow the Attribution API to use it as a Trust & Engagement metric and enable prototyping for the mobile apps.
WE5.3.4 If we define “qualified traffic” (specific outcomes of interest) and distinguish referrers by platform and surface, then we will observe systematic differences in downstream engagement and contribution outcomes that are relevant for product and partnership decisions.
WE5.3.4b If we establish a consistent set of traffic health indicators, then we can reliably detect and explain meaningful shifts in Wikimedia’s incoming traffic over time and by referrer beyond raw pageview counts.
WE5.3.4c If we analyze real-world visibility shocks as natural experiments, then we will see measurable changes in content quality and maintenance outcomes, supporting the relationship between visibility and content health.
WE5.4.2c If we can identify the official Wikimedia mobile apps on iOS and Android in the CDN using their application-layer fingerprints, we can add them as a known-client in requestctl, allowing us to set exceptions and custom rate-limits on them to ensure a smooth user experience.
WE5.4.8b If we rate limit requests for multimedia files based on a tally of response sizes, we will increase fairness in allocating the available bandwidth to users.
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure.
WE5.4.12 If we create signals to distinguish on-site media traffic from external reuse, SRE can prioritize on-site traffic when under load by rate-limiting expensive media requests from external sources.
WE5.4.12b If we can get the image provenance information from MediaWiki, we can use that in conjunction with other identifiers such as referrers and the assigned X-Is-Browser score to relax or vary the rate-limits for on-wiki users.
WE5.4.13 If we establish regular processing and reporting of WE5 objective indicator metrics (request rate, bandwidth, and User-Agent compliance), it will help us track progress across the KRs and assess the effectiveness of blocking high-volume scraping and enforcing the User-Agent policy.
WE5.4.14 If we make our WAF software less tied to our CDN infrastructure, it will be able to serve more use-cases, internal or not.
WE5.4.15 If we can identify and categorize known large-scale NATs containing wiki users, we can use this information to fine-tune ratelimits and other defenses more-strictly on a per-IP level to blunt some of the impact of scraping.
WE5.4.16 If we create a threat model for selected operators of automated traffic, including their intentions, level of investment and techniques employed, we will be able to advance the SRE teams’ ability to identify scrapers and other actors.
WE5.4.17 If we can do near-real time analysis on webrequest traffic to detect one kind of persistent scraping campaign, it will allow us to export rules from the data lake that we can push out to the edge automatically to block/throttle that scraping.
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.5.1 If we investigate and audit the performance concerns and catalog the content-caching fragility for logged-in users, informed by the Readers' strategy for readership retention, we can plan ST6.4 confidently with the right prioritisation framework by observing which cataloged concerns deliver the most value.
WE6.5.2 If we experiment with a platform for cross-wiki code collaboration, testing on at least 4 Indian communities, we will learn how to empower community developers to reuse modules across wikis, and receive positive feedback of these findings at the Hackathon the first week of May. This will be scoped to Lua Modules only, and integrated with WMF's GitLab infrastructure.
WE6.6.1 If we reduce the runtime of the Browser Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
WE6.6.2 If we reduce the runtime of the Unit Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

Discusión

Hypothesis shortname Q4 text Details & Discussion
SDS1.5.1 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.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 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.5.4 If we move our heuristics to a private repository, we will protect the exact logic and data sources we use from motivated attackers.
SDS1.5.5 If we add a numerical score to our pageview metric based on 2 of the signals we’ve evaluated, we will provide a more complete and nuanced view of our traffic.
SDS1.5.6 If we use hCaptcha scores collected as events on account creation and edits as trusted labels, we’ll be able to correlate them to signals and our current bot detection heuristics to evaluate both.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.2.8 If we conduct end-to-end user acceptance testing (UAT) with analyzing Reader Growth’s upcoming A/B/C test exclusively in GrowthBook, then we will learn which aspects of the experience meet production-readiness standards and which need improvement and supporting content before wider rollout.
SDS2.3.1 If we validate and adapt GrowthBook's API to our own, we can use GrowthBook as the canonical experiment control plane, and if we regularly poll GrowthBook's API, we can deliver experiments configured in GrowthBook quickly and easily.
SDS2.3.2 If we implement custom validation in GrowthBook, we’ll know people can’t accidentally misconfigure experiments in ways that violate the constraints of the platform.
SDS2.3.3 If we confirm role-based needs for GrowthBook users (humans, automation scripts from WMF, affiliates with established trust, and prospectively, vetted NDA end users), ensure automatic de-provisioning of stale users with regular report back to DPE, and update documentation to describe the role-based approach and user expectations regarding permissions and system interaction, user onboarding will be more predictable, and we'll have some additional guards to avoid exceeding our paid licensed seating.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
SDS2.4.3 If we introduce support for non-cache splitting experiments, then teams will be able to test JS-only features beyond the current traffic caps (10% all wikis, 0.1% enwiki), removing one of the primary barriers preventing teams from adopting Test Kitchen.
Product and Engineering Support (PES) Hypotheses

[ PES Key Results ]

Discusión

Hypothesis shortname Q4 text Details & Discussion
PES1.4.2 If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.3 If we enable SLO-based alerting, and make it possible to generate reports quarterly and automatically, service owners will be able to respond to service reliability data without (always) needing SRE to initiate.
PES1.5.4 If we set expectations with SRE Ambassadors about roles and responsibilities for SLOs and production readiness in FY26-27, onboard TPgMs and Objective owners to those expectations, and define how the SLO working group will operate, we will achieve buy-in and scalability for “business as usual” SLO and production readiness work starting in Q1.
PES1.6.2 If we onboard directors to the Service Catalog, they will populate it with "obvious" candidates, and we will identify and find owners for at least 2 more critical unowned services.
Future Audience (FA) Hypotheses

[ FA Key Results ]

Discusión

Hypothesis shortname Q4 text Details & Discussion
FA1.1.2 If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.6 If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
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.

Planificando juntos

Actualización de enero de 2025.

Portrait of Selena

El Plan Anual describe aquello que la Fundación Wikimedia pretende lograr en el año que empieza. Nos encontramos trabajando duro para que el plan sea participativo, aspirativo, y alcanzable. Como cada año, le hemos pedido a nuestros y nuestras contribuyentes que nos den a conocer sus perspectivas, esperanzas, y solicitudes puntuales con el objetivo de darle forma al plan. Algunas maneras de llamar a la retroalimentación son la charlas del equipo de producto con las comunidades, la Lista de Deseos de la Comunidad, y otras conversaciones como la serie de conversaciones en Commons, tanto en conferencias como en páginas wiki.

Para nuestro próximo plan anual, que cubre de julio de 2025 a junio de 2026, nos encontramos pensando en la mejor manera de aplicar una visión multigeneracional que tenga en cuenta los rápidos cambios que se producen en el mundo y en el internet, y el modo en el que afectan a nuestra misión de libre conocimiento.

Como se estableció el año pasado, es necesario que nos enfoquemos en lo que nos distingue, es decir, nuestra capacidad de brindar contenido confiable ante la proliferación de la desinformación y la información falseada en el internet, y en plataformas que compiten por la atención de las nuevas generaciones. Este enfoque implica también asegurarnos de poder cumplir nuestra misión de colectar y entregarle la suma de todo el conocimiento humano al mundo, expandiendo nuestra cobertura de información ausente, que puede faltar por causa de inequidad, discriminación, o prejuicio. Nuestro contenido debe también permanecer vital y útil en un cambiante panorama en internet controlado por la inteligencia artificial y por experiencias enriquecidas. Finalmente, requerimos encontrar maneras de financiar sosteniblemente el movimiento, diseñando una estrategia compartida para nuestros productos y para la recaudación de fondos que nos permitan respaldar nuestra labor en el largo plazo.

Para identificar las oportunidades y alternativas en las cuales podemos enfocar nuestros esfuerzos en el año venidero, hemos identificado ciertas cuestiones, y hemos pensado en el modo de distribuir los recursos limitados de los que disponemos, tratando de lograr producir el mayor impacto posible.

Si le interesan particularmente los servicios y características que el departamento de Producto y Tecnología diseñará en base a las prioridades mencionadas, habrá oportunidad en marzo de comentar sobre objetivos específicos y resultados clave. (Como referencia, vea losobjetivos y resultados clave del plan anual actual).

Para reflexionar sobre los desafíos y oportunidades existentes en nuestro entorno técnico, así como la dirección que deberíamos tomar en el próximo plan anual, por favor considere las siguientes cuestiones.

Recabaremos datos sobre estos asuntos de varias formas, de manera continua: desde conversaciones comunitarias, recolección de datos, entrevistas investigativas, y más. Esta no es la primera vez que averiguamos y conocemos sobre algunas de estas cosas. ¡Ya nos encontramos trabajando en varias de ellas! Deseamos indagar nuevamente y seguir aprendiendo, dado que estos temas son cruciales para nosotros en esta etapa de la planificación.

Asuntos:

  • Métricas y datos
    • ¿En qué formas podrían los datos y las métricas apoyarle en su trabajo de edición?¿Qué tipos de datos sobre edición, lectura, o modos de organización podrían ayudarle a escoger cómo invertir su tiempo, o bien, a determinar cuándo se requiere atención en algo? Estos datos pueden corresponder a su propia actividad, o a las actividades de otros.
  • Edición
    • Para usted, ¿En qué momento se siente más divertido y gratificante hacer ediciones?¿En qué momento es más difícil y frustrante?
    • Deseamos que nuestros y nuestras contribuyentes reciban más comentarios y reconocimientos por el trabajo que realizan, para que no se sientan como si nadie notara el esfuerzo que realizan en las wikis. ¿Qué tipo de retroalimentación y reconocimiento es el que le motiva más?¿Qué es lo que le empuja a continuar editando?
    • Dado que las wikis son tan extensas, puede ser difícil, para quienes editan, decidir a qué labor wiki es más importante dedicar su tiempo cada día. ¿Qué tipos de información o de herramientas pueden ayudar a distribuir mejor el tiempo?¿Sería útil contar con un lugar centralizado y personalizado desde el cual se pueda identificar nuevas oportunidades, gestionar labores, y comprender el impacto que hemos producido?
    • Deseamos mejorar la experiencia colaborativa en las wikis, de modo que sea más fácil encontrarse entre contribuyentes y emprender proyectos en conjunto, ya sea mediante iniciativas de reducción de pendientes, editatones, WikiProyectos, o incluso en ocasiones en que dos personas se reúnan a editar. ¿Cómo podríamos ser de ayuda para que otras personas contribuyentes se encuentren, se conecten, y trabajen juntas?
  • Lectura/Aprendizaje
    • Las wikis cargan más rápida o lentamente dependiendo del lugar del mundo en el que se acceda a ellas. ¿En qué partes del mundo se requiere una mejoría de rendimiento con mayor urgencia?
    • ¿Cómo podemos ayudar a las nuevas generaciones de lectores a que encuentren contenido interesante y apasionante en Wikipedia? En el pasado, hemos conversado sobre contenidos interactivos y videos. El año presente, nos enfocamos en tablas y en experimentar nuevos modos de hacer surgir contenidos ya presentes en Wikipedia. ¿Cómo podríamos continuar en ese trayecto, y utilizar nuestro contenido existente de modos que sean únicos en Wikimedia?
  • Moderación
    • ¿Qué es lo que podríamos modificar en Wikipedia para que más personas deseen involucrarse en funciones voluntarias avanzadas, como las de patrulleros o bibliotecarios?
    • ¿Qué información o contexto sobre ediciones o usuarios podría facilitar o acelerar la toma de decisiones sobre patrullaje o administración?
  • Tendencias Externas
    • ¿Cuáles son los principales cambios que se notan en el mundo exterior a Wikimedia? Puede mencionar tendencias en educación, tecnología, o modos de aprendizaje.
    • Fuera del movimiento Wikimedia, ¿En qué otras comunidades en línea participa usted?¿Qué lecciones podemos aprender de las herramientas y procesos que se utilizan en otras plataformas comunitarias?
    • ¿De qué modo utiliza usted herramientas de Inteligencia Artificial en su trabajo dentro y fuera de Wikimedia?¿Para qué le resulta útil la Inteligencia Artificial?
  • Commons
    • ¿Qué decisiones podríamos tomar con la comunidad de Commons, a fin de trazar un proyecto sustentable que apoye a la creación de conocimientos enciclopédicos?
  • Wikidata
    • ¿Qué evolución desearía usted ver en Wikidata en el futuro?¿Qué utilidad tiene para la construcción de contenidos enciclopédicos de confianza?

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/es&oldid=30518717"