Plan Anual de la Fundación Wikimedia/2023-2024/Metas/Infraestructura
Este documento representa la primera parte del proceso de Planeamiento Anual 2024-25 para los departamentos de Producto y Tecnología de la Fundación Wikimedia. Describe el borrador de los objetivos y resultados claves (OKRs). Esta es una continuación de la estructura del portfolio de trabajo (llamado "buckets") que comenzó el año pasado.
.jpg)
Yo hablé con todos ustedes en noviembre sobre lo que creo que es la pregunta más apremiante que enfrenta el movimiento Wikimedia: ¿cómo garantizamos que Wikipedia y todos los proyectos de Wikimedia sean multigeneracionales? Me gustaría agradecer a todos/as los/as que se tomaron el tiempo para considerar realmente esa pregunta y responderme directamente y ahora que he tenido la oportunidad de dedicar un tiempo a reflexionar sobre sus respuestas, compartiré lo que he aprendido.
En primer lugar, no hay una única razón por la que el voluntariado contribuye. Para alimentar a varias generaciones de voluntarios y voluntarias, tenemos que entender mejor las muchas razones por las que la gente contribuye con su tiempo a nuestros proyectos. A continuación, tenemos que centrarnos en lo que nos diferencia: nuestra capacidad para ofrecer contenidos fiables mientras la desinformación y la información errónea proliferan en internet y en las plataformas que compiten por la atención de las nuevas generaciones. Esto incluye garantizar que cumplimos la misión de reunir y difundir al mundo la suma de todo el conocimiento humano ampliando nuestra cobertura de la información que falta, que puede deberse a la falta de equidad, la discriminación o los prejuicios. Nuestros contenidos también tienen que servir y seguir siendo vitales en una internet cambiante impulsada por la inteligencia artificial y las experiencias enriquecedoras. Por último, tenemos que encontrar la manera de financiar nuestro movimiento de forma sostenible mediante la creación de una estrategia compartida para nuestros productos e ingresos, de modo que podamos financiar este trabajo a largo plazo.
Estas ideas se verán reflejadas en el plan anual 2024-2025 de la Fundación Wikimedia, cuya primera parte estoy compartiendo hoy con ustedes en forma de objetivos provisionales para nuestro trabajo en productos y tecnología. Al igual que el año pasado, todo nuestro plan anual estará centrado en las necesidades tecnológicas de nuestras audiencias y plataformas y nos gustaría recibir sus comentarios para saber si estamos enfocándonos en los problemas correctos. Estos objetivos se basan en ideas que hemos estado escuchando de los miembros de la comunidad durante los últimos meses a través de discusión:2024, en listas de correo, páginas de discusión y en eventos comunitarios sobre nuestra estrategia de productos y tecnología para el próximo año. Pueden ver la lista completa de objetivos provisionales a continuación.
Uno de los "objetivos" es una dirección de alto nivel que dará forma a los proyectos de producto y tecnología que emprenderemos para el próximo año fiscal. Son intencionalmente amplios, representan la dirección de nuestra estrategia y, lo que es importante, cuáles desafíos estamos proponiendo priorizar entre las muchas áreas de enfoque posibles para el año que viene. Estamos compartiendo esto ahora para que los miembros de la comunidad puedan ayudar a dar forma a nuestro pensamiento en una etapa temprana, antes de que se comprometan presupuestos y objetivos medibles para el año.
Comentario.
Una área en la que particularmente nos gustaría recibir una devolución es nuestro trabajo agrupado bajo el nombre de "experiencias en Wiki". "Experiencias en Wiki" se refiere a cómo entregamos de manera eficiente, mejoramos e innovamos en cómo las personas utilizan directamente los wikis, ya sea como colaboradores/as, consumidores/as o donantes. Esto implica un trabajo para apoyar nuestra tecnología y capacidades principales y asegurarnos de que podamos mejorar la experiencia de los/as editores/as voluntarios/as, en particular, los/as editores/as con derechos ampliados, a través de mejores características y herramientas, servicios de traducción y actualizaciones en la plataforma.
Aquí hay algunas reflexiones de nuestras recientes discusiones de planificación, y algunas preguntas para todos/as ustedes para ayudarnos a refinar nuestras ideas:
- El voluntariado en los proyectos de Wikimedia debería ser gratificante. También creemos que la experiencia de la colaboración en línea debería ser una parte importante de lo que hace que los/as voluntarios/as sigan regresando. ¿Qué se necesita para que los voluntarios y voluntarias encuentren gratificante la edición y trabajen mejor juntas y juntos para construir contenido fiable?
- La confiabilidad de nuestro contenido es parte de la contribución única de Wikimedia al mundo y lo que hace que las personas sigan viniendo a nuestra plataforma y usando nuestro contenido. ¿Qué podemos construir para colaborar más rápidamente con el crecimiento del contenido fiable pero aún dentro de los límites de calidad establecidos por las comunidades en cada proyecto?
- Para mantenerse relevante y competir con otras plataformas en línea de gran tamaño, Wikimedia necesita que una nueva generación de consumidores/as se sienta conectada con nuestro contenido. ¿Cómo podemos hacer que nuestro contenido sea más fácil de descubrir e interactuar para lectores/as y donantes?
- En una era donde el abuso en línea prospera, necesitamos asegurarnos de que nuestras comunidades, plataforma y sistema de servicio estén protegidos. También enfrentamos obligaciones de cumplimiento en constante evolución, donde los responsables de formular políticas a nivel global buscan moldear la privacidad, identidad y compartición de información en línea. ¿Qué mejoras en nuestras capacidades para combatir el abuso nos ayudarán a abordar estos desafíos?
- MediaWiki, la plataforma de software e interfaces que permiten el funcionamiento de Wikipedia, necesita un apoyo continuo durante la próxima década para proporcionar la creación, moderación, almacenamiento, descubrimiento y consumo de contenido abierto y multilingüe a gran escala. ¿Qué decisiones y mejoras en la plataforma podemos tomar este año para asegurar que MediaWiki sea sostenible?
Borrador de objetivos
En la actualidad se publica el nivel de planificación más elevado: los "Objetivos".
El siguiente nivel: el borrador de Resultados Clave (KR) para cada objetivo finalizado estará disponible para su debate aquí en marzo.
Las Hipótesis' subyacentes de cada KR se actualizarán en las páginas wiki del proyecto/equipo correspondiente a lo largo del año para ir actualizándolas a medida que se vayan aprendiendo lecciones.
| Wiki Experiencias (WE) borrador de objetivos | ||||
|---|---|---|---|---|
| Objetivo | Área objetivo | Objetivo | Contexto objetivo | Propietario |
| WE1 | Experiencia del colaborador | Tanto colaboradores experimentados como nuevos se unen en línea para construir una enciclopedia fiable, con más facilidad y menos frustración. | Para que Wikipedia sea vibrante en los próximos años, debemos hacer un trabajo que nutra a múltiples generaciones de voluntarios y haga que contribuir sea algo que las personas quieran hacer. Las distintas generaciones de voluntarios necesitan distintas aportaciones: los colaboradores más experimentados necesitan que se racionalicen y reparen sus potentes flujos de trabajo, mientras que los colaboradores más nuevos necesitan nuevas formas de editar que tengan sentido para ellos. Y a través de estas generaciones, "todos" los colaboradores necesitan poder conectarse y colaborar entre sí para hacer su trabajo más impactante. Con este objetivo, realizaremos mejoras en los flujos de trabajo críticos para los colaboradores experimentados, reduciremos las barreras a las contribuciones constructivas para los recién llegados e invertiremos en formas de que los voluntarios puedan encontrarse y comunicarse entre sí en torno a intereses comunes. | Marshall Miller |
| WE2 | Contenido enciclopédico | El aumento del contenido enciclopédico se consigue mediante herramientas y recursos a los que sea más fácil acceder, reutilizar y mejorar, y que puedan garantizar de forma fiable la fiabilidad del contenido según las políticas y los resguardos utilizados en los proyectos Wikimedia. | El contenido enciclopédico principalmente en Wikipedia puede aumentarse y mejorarse mediante el compromiso y la innovación continuas. Las herramientas y recursos (tanto técnicos como no técnicos) que están a disposición de los colaboradores para que los utilicen según sus necesidades pueden hacerse más detectables y fiables. Estas herramientas deberían estar mejor respaldadas por la WMF, a través de mejoras de las funciones alcanzables en ciclos cortos. En vista de las recientes tendencias en torno a la generación de contenidos asistida por IA y el cambio en el comportamiento de los usuarios, también exploraremos las bases para cambios sustanciales (por ejemplo, Wikifunciones) que puedan ayudar al crecimiento a escala en la creación y reutilización de contenidos. Los mecanismos para identificar las lagunas de contenido deberían ser más fáciles de descubrir, y de planificar con ellos. Los recursos que apoyan el crecimiento del contenido enciclopédico, incluido el contenido de proyectos hermanos, proyectos como la Biblioteca Wikipedia y campañas, pueden integrarse mejor con los flujos de trabajo de contribución. Al mismo tiempo, los métodos utilizados para el crecimiento deben tener salvaguardas contra las amenazas crecientes, que puedan garantizar que haya una confianza continuada en el proceso, al tiempo que se mantienen fieles a los principios básicos del contenido enciclopédico tal y como se reconocen en todos los proyectos Wikimedia.
Audiencia: editores y traductores |
Runa Bhattacharjee |
| WE3 | Experiencia del consumidor (lectura y medios de comunicación) | Una nueva generación de consumidores llega a Wikipedia para descubrir un destino preferido para descubrir, involucrarse y construir una conexión duradera con el contenido enciclopédico. | Metas:
Mantener a las generaciones existentes y nuevas de consumidores y donantes. Aumentar la relevancia para las generaciones existentes y nuevas de consumidores, facilitando la búsqueda y interacción de nuestros contenidos. Trabajar en todas las plataformas para adaptar nuestras experiencias y el contenido existente, de modo que el contenido enciclopédico pueda ser explorado y curado por y para una nueva generación de consumidores y donantes. |
Olga Vasileva |
| WE4 | Confianza y seguridad | Mejorar nuestra infraestructura, herramientas y procesos de modo que estemos bien equipados para proteger a las comunidades, la plataforma y nuestros sistemas de servicio frente a distintos tipos de ataques escalados y dirigidos, manteniendo al mismo tiempo el cumplimiento de un entorno normativo en evolución. | Algunas facetas de nuestras capacidades de lucha contra el abuso necesitan una mejora. La mitigación del abuso basada en la IP es cada vez menos eficaz, varias herramientas de administración necesitan mejoras de eficiencia y tenemos que elaborar una estrategia unificada que nos ayude a combatir el abuso a gran escala utilizando las distintas señales y mecanismos de mitigación (captchas, bloqueos, etc.) de forma concertada. A lo largo de este año, empezaremos a avanzar en los mayores problemas de este espacio. Además, esta inversión en la protección contra el abuso tiene que equilibrarse con una inversión en la comprensión y mejora de la salud de la comunidad, varios de cuyos aspectos están incluidos en diversos requisitos normativos. | Suman Cherukuwada |
| WE5 | Plataforma del conocimiento I (Evolución de la plataforma) | Desarrollar la plataforma MediaWiki y sus interfaces para satisfacer mejor las necesidades básicas de Wikipedia. | MediaWiki se ha construido para permitir la creación, moderación, almacenamiento, descubrimiento y consumo de contenido abierto y multilingüe a escala. En este segundo año de la Plataforma del Conocimiento, echaremos un vistazo al sistema y comenzaremos a trabajar en mejoras de la plataforma para apoyar eficazmente las necesidades centrales de los proyectos de Wikimedia a lo largo de la próxima década, comenzando con Wikipedia. Esto incluye continuar trabajando para definir nuestra plataforma de producción de conocimiento, fortalecer la sostenibilidad de la plataforma, centrarse en el sistema de extensiones/hooks para aclarar y agilizar el desarrollo de características, y continuar invirtiendo en el intercambio de conocimientos y permitir que las personas contribuyan a MediaWiki. | Birgit Müller |
| WE6 | Plataforma de conocimiento II (Servicios para desarrolladores) | El personal técnico y los desarrolladores voluntarios tienen las herramientas que necesitan para apoyar eficazmente los proyectos de Wikimedia. | Continuaremos el trabajo iniciado para mejorar (y ampliar) los flujos de trabajo de desarrollo, pruebas y despliegue en la Producción Wikimedia y ampliaremos la definición para incluir servicios para desarrolladores de herramientas. También pretendemos mejorar nuestra capacidad para responder a las preguntas más frecuentes en el campo de los flujos de trabajo de desarrollo/ingeniería y las audiencias y hacer accesibles los datos relevantes para permitir una toma de decisiones informada. Parte de este trabajo consiste en examinar las prácticas (o la falta de ellas) que actualmente suponen un reto para nuestro ecosistema. | Birgit Müller |
| Servicios de Señales y Datos (SDS) proyecto de objetivos | ||||
|---|---|---|---|---|
| Objetivo | Área objetivo | Objetivo | Contexto objetivo | Propietario |
| SDS1 | Shared insights | Nuestras decisiones sobre cómo apoyar la misión y el movimiento de Wikimedia están informadas por métricas y ideas de alto nivel. | Para que podamos construir tecnología de forma eficaz y eficiente, apoyar a los voluntarios y defender políticas que protejan y promuevan el acceso al conocimiento, necesitamos comprender el ecosistema Wikimedia y ponernos de acuerdo sobre qué significa el éxito. Esto significa hacer un seguimiento de un conjunto común de métricas que sean fiables, comprensibles y estén disponibles en el momento oportuno. También significa sacar a la luz investigaciones e ideas que nos ayuden a comprender los porqués y los comos de nuestras mediciones. | Kate Zimmerman |
| SDS2 | Plataforma de experimentación | Los gerentes de productos pueden evaluar rápidamente, fácilmente y con confianza los impactos de las características del producto. | Para permitir y acelerar la toma de decisiones basadas en datos sobre el desarrollo de características del producto, los jefes de producto necesitan una plataforma de experimentación en la que puedan definir características, seleccionar audiencias de usuarios de tratamiento y ver mediciones del impacto. Acelerar el tiempo desde el lanzamiento hasta el análisis es fundamental, ya que acortar el plazo de aprendizaje acelerará la experimentación y, en última instancia, la innovación. Las tareas manuales y los enfoques a medida de la medición se han identificado como barreras a la velocidad. El escenario ideal es que los gestores de producto puedan pasar del lanzamiento del experimento al descubrimiento con poca o ninguna intervención manual de ingenieros y analistas. | Tajh Taylor |
| Público Futuro (FA) objetivo del proyecto | ||||
|---|---|---|---|---|
| Objetivo | Área objetivo | Objetivo | Contexto objetivo | Propietario |
| FA1 | Hipótesis de prueba | Proporcionar recomendaciones sobre inversiones estratégicas para que la Fundación Wikimedia siga - basándose en ideas de experimentos que agudicen nuestra comprensión de cómo se comparte y se consume el conocimiento en línea - que ayuden a nuestro movimiento a servir a nuevos públicos en una internet cambiante. | Debido a los cambios continuos en la tecnología y el comportamiento de los usuarios en línea (por ejemplo, la creciente preferencia por obtener información a través de aplicaciones sociales, la popularidad del video educativo corto, el aumento de la IA generativa), el movimiento Wikimedia enfrenta desafíos en la atracción y retención de lectores y colaboradores. Estos cambios también brindan oportunidades para servir a nuevos públicos mediante la creación y la entrega de información de nuevas maneras. Sin embargo, nosotros como movimiento no tenemos una imagen clara y basada en datos de los beneficios y los compromisos de las diferentes estrategias potenciales que podríamos seguir para superar los desafíos o aprovechar nuevas oportunidades. Por ejemplo, ¿deberíamos...
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. |
Maryana Pinchuk |
| Apoyo a Productos e Ingeniería (PES) proyecto de objetivo | ||||
|---|---|---|---|---|
| Objetivo | Área objetivo | Objetivo | Contexto objetivo | Propietario |
| PES1 | Eficiencia de las operaciones | Hacer que el trabajo de la Fundación sea más rápido, más barato y más impactante. | El personal hace mucho en su trabajo regular para hacer que nuestras operaciones sean más rápidas, más baratas y más impactantes. Este objetivo destaca iniciativas específicas que a) lograrán ganancias sustanciales hacia una velocidad más rápida, más barata o más eficaz; y b) realizarán esfuerzos coordinados y cambiarán las prácticas formales e informales en la Fundación. En esencia, los KR incluidos en este objetivo son las mejoras más difíciles y mejores que podemos hacer este año en la eficiencia operativa de los trabajos que afectan a nuestros productos y tecnología. | Amanda Bittaker |
Resultados clave del proyecto
El borrador de "Resultados Clave" (KR) para cada objetivo finalizado estará disponible para su debate aquí en marzo.
Las Hipótesis' subyacentes de cada KR se actualizarán en las páginas wiki del proyecto/equipo correspondiente a lo largo del año para ir actualizándolas a medida que se vayan aprendiendo lecciones.
| Esbozo de resultados clave de Wiki Experiencies (WE) | |||
|---|---|---|---|
| Resultados clave shortname | Resultados clave texto | Resultados clave contexto | Propietario |
| WE1.1 | Desarrollar o mejorar un flujo de trabajo que ayude a los colaboradores con intereses comunes a conectar entre sí y a contribuir juntos. | Creemos que los espacios comunitarios e interacciones en los wiki hacen que las personas sean más felices y productivas como colaboradores. Además, los espacios comunitarios ayudan a los recién llegados a bordo y a mentores, modelan las mejores prácticas de contribución y ayudan a abordar las brechas de conocimiento. Sin embargo, los recursos, herramientas y espacios existentes que apoyan la conexión humana en los wiki son inferiores y no satisfacen los desafíos y necesidades de la mayoría de los editores de hoy. Mientras tanto, el trabajo del equipo de Campaigns ha demostrado que muchos organizadores están ansiosos por adoptar y experimentar con nuevas herramientas con flujos de trabajo estructurados que los ayuden en su trabajo comunitario. Por estas razones, queremos centrarnos en alentar y promover un sentido de pertenencia entre los colaboradores en los wiki. | Ilana Fried |
| WE1.2 | Actividad constructiva: #% Aumento anual en el porcentaje de recién llegados que publican ≥1 edición constructiva en el espacio principal desde un dispositivo móvil. |
Las experiencias actuales de edición a página completa requieren demasiado contexto, paciencia y prueba y error para que muchos recién llegados contribuyan de manera constructiva. Para apoyar a una nueva generación de voluntarios, aumentaremos la cantidad y la disponibilidad de flujos de trabajo de edición más pequeños, estructurados y más específicos de tareas (por ejemplo, Edit Check y Tareas estructuradas).
Nota: Las líneas de base solo se establecerán hacia el final del cuarto trimestre del año fiscal actual, después de lo cual nuestro porcentaje métrico objetivo de KR también será establecido. |
Peter Pelberg |
| WE1.3 | Incrementar en un X% la satisfacción del usuario en 4 productos de moderación. | Los editores con derechos extendidos utilizan una amplia gama de características, extensiones, herramientas y scripts existentes para realizar tareas de moderación en los proyectos Wikimedia. Este año queremos centrarnos en mejorar esta herramienta, en lugar de emprender proyectos para construir nuevas funcionalidades en este espacio. Nuestro objetivo es tocar varios productos a lo largo del año, y queremos hacer mejoras impactantes en cada uno. Al hacerlo, esperamos mejorar la experiencia de moderar el contenido en general. Definiremos X% al medir las líneas de base de algunas herramientas de moderador comunes que podemos apuntar con este flujo de trabajo. La lista de deseos de la Comunidad contribuirá en gran medida a la decisión de las prioridades de este proyecto. We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR. |
Sam Walton |
| WE2.1 | Para finales del segundo trimestre, apoyar a los organizadores, colaboradores e instituciones con herramientas, ideas y enfoques de organización específicos que aumenten la cobertura de contenido de calidad en áreas temáticas clave [TBD] en un X%. | Esta serie de estudios se trata de mejorar la cobertura de los temas para reducir las brechas de conocimiento existentes. Hemos establecido que las comunidades se benefician de herramientas efectivas combinadas con campañas dirigidas a aumentar la calidad del contenido en nuestros proyectos. Este año queremos centrarnos en mejorar las herramientas existentes y experimentar nuevas formas de priorizar las áreas temáticas clave que abordan las brechas de conocimiento. Nuestro objetivo de aumento del X% en la cobertura se determinará analizando las líneas de base existentes de creación de contenido de calidad. Además, las áreas temáticas en las que nos centraremos con las comunidades e instituciones se determinarán para el próximo trimestre. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | Para finales del segundo trimestre, se implementarán y se probarán dos recomendaciones, tanto sociales como técnicas, para apoyar la incorporación de idiomas para las pequeñas comunidades lingüísticas, con una evaluación para analizar la retroalimentación de la comunidad. | Hay ediciones de Wikipedia en unos 300 idiomas. Y, sin embargo, hay muchos más idiomas hablados por millones de personas, en los que no existe Wikipedia ni ningún proyecto Wiki. Esto es un obstáculo para hacer realidad nuestra visión: que cada ser humano pueda compartir libremente la suma de todo el conocimiento. La Incubadora Wikimedia es donde se pueden organizar, escribir, probar y demostrar que los wikis potenciales de proyectos Wikimedia en versiones de nuevos idiomas son dignos de ser alojados por la Fundación Wikimedia. The Incubator se lanzó en 2006 con la suposición de que sus usuarios tendrían conocimientos previos de edición wiki. Este problema se ve exacerbado por el hecho de que se supone que este proceso lo realizan principalmente personas que son las más nuevas y las menos experimentadas en nuestro movimiento. Si bien la edición en los wikis de Wikimedia ha mejorado significativamente desde entonces, la Incubadora no ha recibido estas actualizaciones debido a a limitaciones técnicas. Actualmente, un wiki tarda varias semanas en salir de la Incubadora y sólo se crean alrededor de 12 wikis cada año, lo que muestra un importante cuello de botella.
La investigación y los materiales existentes revelan desafíos técnicos en cada fase de la incorporación de idiomas: agregar nuevos idiomas a la Incubadora, complejidades en el desarrollo y revisión de contenido y un proceso lento en la creación de un sitio wiki cuando un idioma sale de la Incubadora. Cada fase es lenta, manual y compleja, lo que indica la necesidad de mejorar. Abordar este problema permitirá crear wikis en nuevos idiomas de forma más rápida y sencilla, y permitirá que más humanos compartan conocimientos. Diversas partes interesadas, investigaciones y recursos existentes han destacado las recomendaciones propuestas tanto sociales como técnicas. Este resultado clave propone probar dos recomendaciones tanto sociales como técnicas y evaluar los comentarios de la comunidad. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | A finales del segundo trimestre, 2 nuevas características guiarán a los colaboradores a añadir contenido referenciado que cumpla con las directrices del proyecto, y 3-5 socios han contribuido a fuentes en los que se abordan las brechas lingüísticas y geográficas. | Para aumentar el acceso al material de calidad que se necesita para cerrar las brechas de contenido estratégico, vamos a:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | Para finales del segundo trimestre, habilitar las llamadas de Wikifunctions en al menos un idioma más pequeño, Wikipedia, para proporcionar una forma más escalable de generar contenido nuevo. | Para reducir eficazmente las brechas de conocimiento, necesitamos mejorar los flujos de trabajo que apoyen el crecimiento escalable de contenido de calidad, especialmente en comunidades lingüísticas más pequeñas. | Amy Tsay |
| WE3.1 | Lanzar dos experiencias de navegación y aprendizaje seleccionadas, accesibles e impulsadas por la comunidad para wikis representativos, con el objetivo de aumentar en un 5 % la retención de lectores desconectados de los usuarios de la experiencia. | Este KR se centra en aumentar la retención de una nueva generación de lectores en nuestro sitio web, permitiendo a una nueva generacion construir una conexión duradera con Wikipedia, explorando oportunidades para que los lectores descubran y aprendan más fácilmente de contenido que les interesa. Esto incluirá la exploración y el desarrollo de nuevas experiencias de navegación y aprendizaje seleccionadas, personalizadas y orientadas a la comunidad (por ejemplo, feeds de contenido relevante, recomendaciones y sugerencias de contenido actual, oportunidades de exploración de contenido seleccionado por la comunidad, etc.).
Planeamos comenzar el año fiscal experimentando con una serie de experimentos de experiencias de navegación para determinar cuál queremos escalar para el uso de producción y en qué plataforma (web, aplicaciones o ambas). A continuación, nos centraremos en ampliar estos experimentos y probar su eficacia en el aumento de la retención en entornos de producción. Nuestro objetivo es lanzar al menos dos experiencias en wikis representativos y medir con precisión un aumento del 5% en la retención de lectores para los lectores que participan en estas experiencias. Para ser óptimamente eficaces en lograr este KR, requeriremos la capacidad de realizar pruebas A/B con usuarios desinscritos, así como instrumentos capaces de medir la retención del lector. También podríamos necesitar nuevas APIs o servicios necesarios para presentar recomendaciones y otros mecanismos de curadoria. |
Olga Vasileva |
| WE3.2 | Aumento del 50% en el número de donaciones a través de puntos de contacto fuera del banner anual y de los llamamientos por correo electrónico por plataforma. | Nuestro objetivo es proporcionar una diversidad de fuentes de ingresos al tiempo que reconocemos a nuestros donantes existentes. Basándonos en la retroalimentación y los datos, nuestro enfoque es aumentar el número de donaciones más allá de los métodos en los que la Fundación se ha basado en el pasado, específicamente en las llamadas anuales de banners. Queremos demostrar que mediante la inversión en experiencias de donantes más integradas, podemos sostener nuestro trabajo y ampliar nuestro impacto al proporcionar una alternativa a los donantes y potenciales donantes que no responden a los llamamientos de banners. El 50% es una estimación inicial basada en la disminución de la visibilidad del botón de donación en la Web como resultado de Vector 2022, y el aumento en el número de donaciones del proyecto piloto del año fiscal 2023-2024 en las aplicaciones de Wikipedia para mejorar las experiencias de los donantes (50,1% de aumento en las donaciones). Evaluar esta métrica por plataforma nos ayudará a entender las tendencias en las plataformas y si se deben implementar diferentes tácticas en el futuro basadas en una diferencia en el comportamiento basada en la audiencia de la plataforma. | Jazmin Tanner |
| WE3.3 | By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE3.4 | Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy. |
The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them. |
Kwaku Ofori |
| WE4.1 | Proporcionar una propuesta de 3 contramedidas al acoso y al contenido nocivo con apoyo de datos y de acuerdo con el entorno regulatorio en constante evolución para el tercer trimestre. | La seguridad y el bienestar de los usuarios es una responsabilidad fundamental de las plataformas en línea. Muchas jurisdicciones tienen leyes y regulaciones que exigen que las plataformas en línea tomen medidas contra el acoso, el acoso cibernético y otros contenidos dañinos. Si no se abordan estos problemas, las plataformas pueden ser expuestas a la responsabilidad legal y a sanciones regulatorias.
En este momento no tenemos muy buena idea de la magnitud de estos problemas ni de las razones que están detrás de ellos. En este sentido, la Comisión ha decidido que la Comisión debe adoptar medidas para garantizar que los Estados miembros puedan adoptar medidas de seguridad y que no se impidan la adopción de medidas de seguridad. Necesitamos construir una cultura fuerte de medir la incidencia de acoso y contenido nocivo e implementar de manera proactiva las contramedidas. |
Madalina Ana |
| WE4.2 | Desarrollar al menos dos señales para su uso en los flujos de trabajo contra el abuso para mejorar la precisión de las acciones contra los actores nocivos en el tercer trimestre. | Los wikis dependen en gran medida del bloqueo de IP como mecanismo para evitar el vandalismo, el spam y el abuso. Pero las direcciones IP son cada vez menos útiles como identificadores estables de un actor individual, y bloquear las direcciones de IP tiene efectos negativos no deseados en los usuarios de buena fe que comparten la misma dirección IP que los malos actores. La combinación de la disminución de la estabilidad de las direcciones IP y nuestra fuerte dependencia del bloqueo de IP resulta en una menor precisión y eficacia en la orientación hacia los actores malos, en combinación con un aumento de los niveles de daño colateral para los usuarios de buena fe. Queremos ver la situación opuesta: disminución de los niveles de daños colaterales y mayor precisión en las medidas de mitigación dirigidas a los malos actores.
Para respaldar mejor el trabajo anti-abuso de los funcionarios y proporcionar elementos básicos para su reutilización en herramientas existentes (por ejemplo, CheckUser, Special:Block) y nuevas, en este KR proponemos explorar formas de asociar de manera confiable a un individuo con sus acciones (mitigación del uso de títeres) y combinar señales existentes (por ejemplo, direcciones IP, historial de cuentas, atributos de solicitud) para permitir una orientación más precisa de las acciones hacia los malos actores. |
Kosta Harlan |
| WE4.3 | Reducir la eficacia de un ataque distribuido a gran escala en un 50%, medido por el tiempo que nos toma adaptar nuestras medidas y el volumen de tráfico que podemos mantener en una simulación. | La evolución del panorama de Internet, incluido el aumento de botnets a gran escala y ataques más frecuentes, han hecho obsoletas nuestros métodos tradicionales de limitar el abuso a gran escala. Tales ataques pueden hacer que nuestros sitios no estén disponibles inundando nuestra infraestructura con solicitudes, o abrumar la capacidad de nuestra comunidad para combatir el vandalismo a gran escala. Esto también pone una presión irracional sobre nuestros editores de alto privilegio y nuestra comunidad técnica.
Necesitamos mejorar nuestra capacidad de detectar, resistir y mitigar o detener automáticamente tales ataques. Para medir nuestras mejoras, no podemos confiar únicamente en la frecuencia/intensidad de los ataques reales, ya que dependeríamos de acciones externas y sería difícil obtener una imagen cuantitativa clara de nuestro progreso. Al establecer múltiples ataques simulados de naturaleza/complejidad/duración variable para ejecutarse de forma segura contra nuestra infraestructura, y ejecutarlos cada trimestre, podremos probar nuestras nuevas contramedidas sin estar bajo un ataque real, y informarnos objetivamente sobre nuestras mejoras. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | Para el tercer trimestre, completar al menos cinco intervenciones destinadas a aumentar la sostenibilidad de la plataforma. | La sostenibilidad de la plataforma MediaWiki es un esfuerzo permanente importante para nuestra capacidad de escalar, aumentar o evitar la degradación de la satisfacción de los desarrolladores y hacer crecer nuestra comunidad técnica. Esto es difícil de medir y depende de factores técnicos y sociales. Sin embargo, tenemos conocimiento tácito sobre áreas específicas de mejora que son estratégicas para la sostenibilidad. Las intervenciones planificadas pueden ayudar a aumentar la sostenibilidad y mantenibilidad de la plataforma o evitar su degradación. Planeamos evaluar el impacto de este trabajo en el cuarto trimestre con recomendaciones para los objetivos de sostenibilidad en el futuro. Ejemplos de intervenciones de sostenibilidad son: simplificar dominios de código complejos que son fundamentales para MediaWiki pero que sólo un puñado de personas saben cómo funciona; aumentar el uso de herramientas de análisis de código para informar la calidad de nuestro código base; agilizar procesos como el empaquetado y los lanzamientos. | Mateus Santos |
| WE5.2 | Identificar antes del segundo trimestre y completar antes del cuarto trimestre una o más intervenciones para evolucionar las interfaces de programación del ecosistema MediaWiki para potenciar el desarrollo de características desconectadas, más simples y más sostenibles. | El objetivo principal de KR 5.2 es mejorar y aclarar la interacción entre la plataforma central de MediaWiki y sus extensiones, skins y otras partes. Nuestra intención es proporcionar mejoras funcionales a la arquitectura de MediaWiki que permitan la modularidad y la capacidad de mantenimiento prácticas, para las cuales es más fácil desarrollar extensiones, y potenciar los requisitos de la visión de producto MediaWiki más amplia. Este trabajo también tiene como objetivo informar lo que debería existir (o no) dentro del núcleo, las extensiones o las interfaces entre ellas. El año se dividirá en dos fases: una fase de investigación y experimentación de 5 meses que informará la segunda fase en la que se implementarán intervenciones específicas. | Jonathan Tweed |
| WE5.3 | Para finales del segundo trimestre, completar una iniciativa de recopilación de datos y un experimento de mejora de rendimiento para informar las intervenciones de seguimiento de productos y plataformas para aprovechar las capacidades desbloqueadas por la modelación de una página como una composición de fragmentos estructurados por MediaWiki. | El objetivo principal aquí es capacitar a los desarrolladores y gerentes de productos para aprovechar las nuevas capacidades de la plataforma MediaWiki para satisfacer las necesidades actuales y futuras de contenido enciclopédico mediante la creación de nuevas ofertas de productos que actualmente son difíciles de implementar, así como mejorar el rendimiento y la resiliencia de la plataforma.
Específicamente, a nivel de la plataforma MediaWiki, queremos cambiar el modelo de procesamiento de MediaWiki de tratar una página como una unidad monolítica a tratar una página de una composición de unidades de contenido estructuradas. Las vistas de lectura basadas en parsoides, la integración de Wikidata y la integración Wikifunctions en wikis son todos movimientos implícitos hacia eso. Como parte de este KR, queremos experimentar y recopilar datos con más intención para informar futuras intervenciones basadas en estas nuevas capacidades para asegurarnos de que podemos lograr los impactos de la infraestructura y los productos previstos. |
Subramanya Sastry |
| WE5.4 | By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management. |
Mateus Santos |
| WE6.1 | Resolver cinco preguntas para permitir la eficiencia y las decisiones informadas sobre los flujos de trabajo y servicios de desarrolladores e ingenieros y hacer accesibles los datos pertinentes a finales del cuarto trimestre. | "Es complicado" es una respuesta frecuente a preguntas como "qué repositorios se implementan en la producción de Wikimedia". En este KR exploraremos algunos de nuestros “elementos de hoja perenne” en el campo de la productividad y la experiencia en ingeniería: preguntas recurrentes que parecen fáciles pero difíciles de responder, preguntas que podemos responder, pero los datos no son accesibles y requieren consultas personalizadas por tema. expertos en la materia, o preguntas sobre las cuales es complicado obtener una respuesta debido a brechas en el proceso u otras razones. Definiremos qué significa "resolver" para cada una de las preguntas: para algunos, esto puede significar simplemente hacer accesibles los datos existentes y precisos. Otras preguntas requerirán más tiempo de investigación e ingeniería para abordarlas. El objetivo general de este trabajo es reducir el tiempo, las soluciones alternativas y el esfuerzo necesarios para obtener información sobre aspectos clave de la experiencia del desarrollador y permitirnos realizar mejoras en los flujos de trabajo y servicios de ingeniería y desarrollo. | [TBD] |
| WE6.2 | Para el cuarto trimestre, mejorar un proyecto existente y realizar al menos dos experimentos destinados a proporcionar entornos sostenibles y dirigidos que nos conduzcan hacia una entrega segura y semicontinua. | Los desarrolladores y usuarios dependen del Cluster Beta de Wikimedia (beta) para detectar errores antes de que afecten a los usuarios en la producción. Con el tiempo, los usos de la beta han crecido y han entrado en conflicto: los usos son demasiado diversos para encajar en un solo entorno. Mejoraremos un entorno alternativo existente y realizaremos experimentos destinados a reemplazar una única necesidad de pruebas de alta prioridad que actualmente se cumple con la versión beta con un entorno alternativa sostenible que sirva mejor a las necesidades de cada caso de uso. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | Toolforge, la plataforma clave para las herramientas construidas por voluntarios de Wikimedia, juega un papel crucial desde la edición hasta el anti-vandalismo. Nuestro objetivo es mejorar la usabilidad de Toolforge, reducir las barreras para la contribución, mejorar las prácticas comunitarias y promover el cumplimiento de las políticas establecidas. Para ello, introduciremos un sistema de puntuación para el segundo trimestre para evaluar la sostenibilidad de la plataforma Toolforge, centrándose en los aspectos técnicos y sociales. Utilizando este sistema como guía, nuestro objetivo es mejorar un factor técnico clave en un 50%. | Slavina Stefanova |
| Resultados clave del proyecto de servicios de señales y datos (SDS) | |||
|---|---|---|---|
| Resultados clave shortname | Resultados clave texto | Resultados clave contexto | Propietario |
| SDS1.1 | Los líderes de 2 programas o iniciativas impulsadas por KR han producido documentación ampliamente compartida que explica el vínculo lógico entre el trabajo de su equipo e impacto en una o más métricas básicas de la Fundación. | Nuestras métricas organizativas básicas sirven como base para evaluar el progreso de la Fundación hacia sus objetivos. A medida que asignamos recursos a programas y a flujos de trabajo orientados al diseño de resultados clave (KR), estas métricas de alto nivel deben guiar la forma en que vincular estas inversiones con los objetivos generales de la Fundación según se definen en el plan anual. El trabajo realizado en este resultado clave reconoce que la Fundación en su conjunto se encuentra en una etapa temprana en su capacidad de vincular cuantitativamente los impactos de todas las intervenciones planificadas con métricas de alto nivel o básicas. En la búsqueda de ese objetivo final, este KR tiene como objetivo desarrollar el proceso por el cual compartimos los vínculos lógicos y teóricos entre nuestras iniciativas y nuestras métricas de alto nivel. En la práctica, esto significa asociarse con los propietarios de iniciativas en toda la Fundación para comprender cómo el resultado de su trabajo a nivel de proyecto está vinculado a nuestras métricas centrales a nivel de la Fundación e impacta en ella. Se emplearán marcos y ejercicios de mapeo de impacto como "mapeo de teoría del cambio" y construcción de gráficos causales para garantizar la coherencia y el rigor en la documentación del impacto potencial del trabajo. Para ejecutar este resultado clave, también necesitaremos desarrollar materiales de apoyo que ayuden a los propietarios de iniciativas a comprender las métricas organizacionales y a entender cómo construir teorías de cambio asociadas con su trabajo. |
Omari Sefu |
| SDS1.2 | Responder a 2 preguntas de investigación abierta de carácter estratégico para el mes de diciembre de 2024 con el fin de proporcionar recomendaciones o informar sobre la planificación anual del ejercicio fiscal 26. | Hay muchas preguntas de investigación abiertas en el ecosistema Wikimedia, y responder algunas de esas preguntas es estratégico para WMF o sus afiliados. Las respuestas a estas preguntas pueden informar el desarrollo futuro de productos o tecnologías o pueden apoyar la toma de decisiones/la promoción en el espacio político. Si bien algunas de estas preguntas se pueden responder utilizando experiencia puramente en investigación o ingeniería de investigación, dada la naturaleza sociotécnica de los proyectos de WM, llegar a conocimientos confiables a menudo requiere la colaboración entre equipos para la recopilación de datos, la creación de contexto, la interacción del usuario y el diseño cuidadoso de experimentos y más. A través de este KR pretendemos priorizar algunos de nuestros recursos para responder una o más de estas preguntas.
El trabajo en este KR incluye priorizar una lista de preguntas abiertas estratégicas, así como hacer trabajo experimental para encontrar una respuesta para el número X (actualmente estimado en 2) de ellas. El tipo ideal de preguntas que abordamos en este KR son preguntas que una vez respondidas pueden tener un efecto desbloqueador al permitir que varios otros equipos o grupos realicen (mejor informados) trabajo de producto, tecnología o política. La intención es que el trabajo en este KR sea complementario a los siguientes KR:
|
Leila Zia |
| SDS1.3 | Conseguir una reducción de al menos un 50% en el tiempo medio requerido para que las partes interesadas en los datos comprendan y rastreen los flujos de datos para 3 métricas principales y esenciales | Requerimientos para los estándares de Gobernanza de Datos.
El rastreo de la transformación y la fuente de los conjuntos de datos es difícil y requiere conocimiento de diferentes repositorios y sistemas. Debemos facilitar la comprensión de cómo fluyen los datos en nuestros sistemas para que los interesados puedan trabajar de una manera más autosuficiente. Este trabajo apoyará los flujos de trabajo en los que se transforman y utilizan datos para análisis, características, API y trabajos de calidad de datos. Habrá un seguimiento de KR en torno a la documentación de métricas. |
Luke Bowmaker |
| SDS2.1 | Para finales del segundo trimestre, podremos apoyar a un equipo de productos para evaluar una característica o producto a través de pruebas básicas A/B que reducen su tiempo a los datos de interacción del usuario en un 50%. | Creemos que el uso de herramientas compartidas aumentará la confianza de los equipos de productos en la toma de decisiones basada en datos, mejorará la eficiencia y la productividad, y mejorará la estrategia e innovación de productos. Vamos a ver la adopción del tiempo individual del equipo a las líneas de base de datos de interacción del usuario y mejorarlo en un 50%. También investigaremos cómo podemos contextualizar estas ganancias en el contexto más completo de todos los equipos de productos. Esperamos aprender cómo podemos mejorar la experiencia e identificar y priorizar las mejoras de capacidad en función de los comentarios del equipo de adopción y los resultados de SDS2.2. |
Virginia Poundstone |
| SDS2.2 | Para finales del segundo trimestre, tendremos 2 métricas esenciales para analizar los experimentos (tesos A/B) para apoyar las hipótesis de prueba de productos/características relacionadas con los KRF24-25. | Cuando un gerente de producto (o diseñador) tiene la hipótesis de que un producto/característica abordará un problema/necesidad de los usuarios o de la organización, un experimento es la forma en que prueba esa hipótesis y aprende sobre el impacto potencial de su idea en una métrica. Los resultados del experimento informan al gerente de producto y lo ayudan a tomar una decisión sobre qué acción tomar a continuación (abandonar esta idea y probar una hipótesis diferente, continuar el desarrollo si el experimento se realizó temprano en el ciclo de vida de desarrollo, o lanzar el producto/función a más usuarios). Los gerentes de producto deben poder tomar esa decisión con confianza, respaldada por evidencia en la que confían y comprenden.
Un obstáculo importante para esto es que los equipos de producto actualmente forman sus hipótesis con métricas específicas de proyectos personalizadas que requieren apoyo de analistas dedicados para definir, medir, analizar e informar sobre ellas. Si se cambiara a un conjunto de métricas esenciales para formular todas las afirmaciones de hipótesis de producto/características verificables, se lograría:
Creemos que un conjunto de métricas esenciales que sean ampliamente comprendidas y utilizadas de forma consistente - e informadas/influenciadas por las métricas estándar de la industria - también mejoraría la alfabetización de datos organizacionales y promovería una cultura de revisión, experimentación y aprendizaje. Nos centramos en métricas esenciales que (1) son necesarias para la mejor medición y evaluación del éxito/impacto de productos/características relacionadas con 2 Wiki Experiences KRs - WE3.1 y WE1.2 - y (2) reflejan o mapean métricas estándar de la industria utilizadas en análisis web. |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| Resultado clave del borrador de Future Audiences (FA) | |||
|---|---|---|---|
| Resultados clave shortname | Resultados clave texto | Resultados clave contexto | Propietario |
| FA1.1 | Como resultado de los conocimientos y recomendaciones experimentales de Future Audiences, a finales del tercer trimestre al menos un objetivo o resultado clave propiedad de un equipo de Audiences no de Future Audience estará presente en el proyecto del plan anual del año siguiente. | Desde 2020, la Fundación Wikimedia ha estado rastreando tendencias externas que pueden afectar nuestra capacidad de servir a las generaciones futuras de consumidores y contribuyentes de conocimiento y seguir siendo un próspero movimiento de conocimiento libre para las generaciones venideras. Future Audiences, un pequeño equipo de I+D, hará lo siguiente:
|
Maryana Pinchuk |
| Borrador de resultados clave Soporte de productos e ingeniería (PES) | |||
|---|---|---|---|
| Resultados clave shortname | Resultados clave texto | Resultados clave contexto | Propietario |
| PES1.1 | Cultura de la revisión: Mejorar incrementalmente las puntuaciones para el sentimiento del personal de P+T relacionado con nuestra entrega, alineación, dirección y salud del equipo en una encuesta trimestral. | Una cultura de revisión es una cultura de desarrollo de productos basada en ciclos más cortos de iteración, aprendizaje y adaptación. Esto significa que nuestra organización puede fijarse metas anuales, pero lo que hacemos para alcanzar esas metas cambiará y se adaptará a lo largo del año a medida que aprendamos. Hay dos componentes para construir una cultura de revisión: procesos y comportamientos. Este KR se centra en este último. Los cambios en el comportamiento pueden crecer y fortalecer nuestra cultura de revisión. Esto implica cambios en los hábitos y rutinas individuales a medida que avanzamos hacia un desarrollo de productos más iterativo. Esta evaluación se basará en cambios autoinformados en los comportamientos individuales y en medir los cambios resultantes, si los hay, en el sentimiento del personal. | Amy Tsay |
| PES1.2 | Para finales del segundo trimestre, la nueva Lista de deseos conecta mejor las ideas y solicitudes de movimientos con las actividades de P+T de la Fundación: los elementos de la lista de deseos pendientes se abordan a través de un KR 2024-5, la Fundación ha completado 10 Deseos más pequeños y la Fundación se ha asociado con voluntarios para identificar más de 3 áreas de oportunidad para el año fiscal 2025-26. | La Lista de deseos de la comunidad representa una pequeña porción del movimiento; Participan aproximadamente 1.000 personas, la mayoría de las cuales son contribuyentes o administradores. La gente suele pasar por alto la lista de deseos escribiendo solicitudes de funciones e informes de errores a través de Phabricator, donde es difícil discernir las solicitudes de WMF o de la comunidad. Para los participantes, la lista de deseos es una inversión de tiempo costosa con una recompensa mínima. Todavía interactúan con la lista de deseos porque sienten que es el único vehículo para llamar la atención sobre errores impactantes y mejoras de funciones, o señalar la necesidad de oportunidades estratégicas más amplias. Los deseos a menudo se escriben como soluciones y no como problemas. Las soluciones pueden parecer sensatas sobre el papel, pero no necesariamente consideran la complejidad técnica o las implicaciones de la estrategia de movimiento.
El alcance y la amplitud de los deseos a veces exceden el alcance y la capacidad de Community Tech o de un solo equipo, lo que perpetúa la frustración y genera RFC y llamadas para desmantelar la lista de deseos. Mientras que los miembros de la comunidad prefieren usar la Lista de deseos para ideas de proyectos, los equipos de la Fundación miran la Lista de deseos y otros procesos de admisión para priorizar, en parte porque los deseos no son oportunos para la planificación anual y son difíciles de incorporar en las hojas de ruta/OKR. La Future Wishlist debe ser un puente entre la comunidad y la Fundación, donde las comunidades brinden aportes de manera estructurada, para que podamos tomar medidas y, a su vez, hacer felices a los voluntarios. Estamos creando un nuevo proceso de admisión para que cualquier voluntario que haya iniciado sesión envíe un deseo, los 365 días del año. Los deseos pueden informar o resaltar un error, solicitar una mejora o idear una nueva característica. Cualquiera puede comentar, realizar talleres o apoyar un deseo para influir en la priorización. La Fundación no clasificará los deseos como “demasiado grandes” o “demasiado pequeños”. Los deseos que se asignan temáticamente a un área problemática más amplia pueden influir en la planificación anual y las hojas de ruta del equipo, ofreciendo direcciones y oportunidades estratégicas. Los deseos serán visibles para el Movimiento en un panel que los clasifica por proyecto, producto/área problemática y tipo de deseo. La Fundación responderá a los deseos de manera oportuna y se asociará con la Comunidad para categorizar y priorizar los deseos. Nos asociaremos con Wikimedians para identificar y priorizar tres áreas de mejora, incorporadas en el Plan Anual 2025-26 de la Fundación, que deberían mejorar la tasa de adopción y el cumplimiento de deseos impactantes. Señalaremos deseos bien definidos para la comunidad de desarrolladores voluntarios y los equipos de la Fundación, lo que generará una mayor participación del equipo y de los desarrolladores y más deseos cumplidos, lo que conducirá a la satisfacción de la comunidad. Atender más deseos mejora la felicidad, la eficacia y la retención de los contribuyentes, lo que debería generar más ediciones de calidad, contenido de mayor calidad y más lectores. |
Jack Wheeler |
| PES1.3 | Ejecutar y concluir dos experimentos a partir de productos/características exploratorias existentes que nos proporcionen datos/ideas sobre cómo hacemos crecer Wikipedia como un destino de conocimiento para nuestras audiencias actuales de consumidores y voluntarios en el primer y segundo trimestre. Complete y comparta aprendizajes y recomendaciones para una posible adopción para futuros trabajos de OKR en el grupo de Experiencias Wiki para finales del tercer trimestre. | Este trabajo es una contraparte del objetivo de Audiencias futuras, pero se centra en descubrir oportunidades para aumentar y profundizar la participación de nuestras audiencias existentes (de consumidores y contribuyentes de Wikipedia) mediante pruebas más ágiles de más ideas de productos en la plataforma.
Forma parte de PES1 ya que es un energizante y multiplicador: canaliza el tiempo que los individuos y los equipos "ya" han dedicado a hackear/experimentar en proyectos paralelos para enfocar características más prometedoras. En lugar de que estos proyectos paralelos languidezcan (no es un buen uso de nuestros recursos limitados), este KR proporciona un camino para que algunas de estas ideas se conviertan potencialmente en un entorno de APP más amplio a través de experimentos probados, utilizando así de manera más eficiente el tiempo del personal y motivando su creatividad y productividad. Al poner en marcha más de estos proyectos más pequeños y breves, también diversificamos nuestra gama de "apuestas" para obtener más aprendizajes y pruebas de ideas que puedan transformar Wikipedia en línea con las necesidades y expectativas cambiantes de nuestras audiencias actuales. Esto hará que nuestro trabajo tenga más impacto y sea más rápido, ya que ayuda a la base a alinearse con el objetivo correcto en menos tiempo. |
Rita Ho |
| PES1.4 | Aprenda a: establecer, monitorear y tomar decisiones sobre SLO. Elija al menos una cosa nueva para definir los SLO cuando lo lancemos. Colaborar con los equipos respectivos (normalmente: producto, equipos de desarrollo, SRE) para definir ese SLO. Reflexionar y documentar directrices sobre qué versiones deberían tener SLO en el futuro y cómo establecerlos. | FUTURO KR:
Configure procesos y herramientas rudimentarias para configurar y monitorear SLO para nuevas versiones. Informe trimestralmente y utilícelo para tomar decisiones sobre cuándo (y no) priorizar el trabajo para solucionar algo. Compartir informe con la comunidad. PORQUÉ: No sabemos cuándo debemos priorizar el trabajo para solucionar algo. Y tenemos mucho código. A medida que esta huella continúa creciendo, hay más situaciones en las que es posible que tengamos que decidir entre abordar problemas o centrarnos en la innovación, y más incertidumbre sobre cuándo hacerlo. Además, no queda claro para el personal y la comunidad cuál es nuestro nivel de soporte/compromiso con la confiabilidad y el rendimiento para todas las diferentes características y funcionalidades con las que interactúan. Si definimos un nivel esperado de servicio, podemos saber cuándo debemos asignarle recursos o no. |
Mark Bergsma |
| PES1.5 | Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department. | After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department. | Mark Bergsma |
Hypotheses
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
Q1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | |
| WE3.2.1 | If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year | phab:T368765 |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.3.1 | If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs. | |
| WE4.1.1 | If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take. | |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | phab:T368388 |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | WE4.2.9 Talk page |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts | WE4.2.2 Talk page |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | phab:T368389 |
| WE4.3.2 | If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.4 | If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool. | phab:T369480 |
| WE4.4.1 | If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully. | |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.2 | If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress. | |
| WE5.1.3 | If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1. | phab:T344944 |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers. | |
| WE5.2.1 | If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful. | [1] |
| WE5.2.2 | If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. | [2] |
| WE5.3.1 | If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform. | T371713 |
| WE5.3.2 | On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits. | T363421 |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.1 | If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests. | |
| WE6.1.2 | If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers. | tarea T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | mw: New Engagement Experiments#PES_1.3.3:_Incubator_space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
Q2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator_Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024_Moderator_Tools_project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024_Reader_and_Donor_Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | https://meta.wikimedia.org/wiki/Incident_Reporting_System# |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia_Technical_Documentation_Team/Doc_metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container. | T379683 |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data_Platform_Engineering/Data_Products/work_focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | tarea T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| PES1.5.1 | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
Explicación de los cubos
Wiki Experiencias
El objetivo de este cubo es proporcionar, mejorar e innovar de forma eficiente experiencias wiki que permitan la distribución de conocimiento libre en todo el mundo. Este cubo se alinea con las recomendaciones de la estrategia del movimiento #2 (Mejorar la Experiencia del Usuario) y #3 (Proporcionar Seguridad e Inclusión). Nuestro público incluye a todos los colaboradores de nuestros sitios web, así como a los lectores y otros consumidores de conocimiento libre. Damos soporte a un sitio web global de los 10 mejores y a muchos otros importantes recursos de cultura libre. Estos sistemas tienen unos requisitos de rendimiento y tiempo de actividad equiparables a los de las mayores empresas tecnológicas del mundo. Proporcionamos interfaces de usuario para wikis, traducción, API para desarrolladores (¡y mucho más!) y aplicaciones e infraestructura de apoyo que forman una sólida plataforma para que los voluntarios colaboren en la producción de conocimiento libre en todo el mundo. Nuestros objetivos para este cubo deben permitirnos mejorar nuestra tecnología y capacidades básicas, garantizar que mejoramos continuamente la experiencia de los editores y moderadores voluntarios de nuestros proyectos, mejorar la experiencia de todos los colaboradores técnicos que trabajan para mejorar o potenciar las experiencias wiki, y garantizar una gran experiencia para los lectores y consumidores de conocimiento libre de todo el mundo. Lo haremos a través del trabajo en productos y tecnología, así como a través de la investigación y el marketing. Esperamos tener como máximo cinco objetivos para este cubo.
¡El conocimiento es construido por las personas! Y como resultado nuestro plan anual se centrará en el contenido así como en las personas que contribuyen al contenido y aquellos que acceden y leen.
Nuestro objetivo es elaborar un plan operativo basado en la estrategia existente, principalmente en nuestras hipótesis sobre el contribuidor, consumidor y "volante" de contenidos. El cambio principal que pido es un énfasis en la parte de contenido de "volante", y la exploración de lo que nuestros moderadores y funcionarios pueden necesitar de nosotros ahora, con el objetivo de identificar las métricas de salud de la comunidad en el futuro.
Servicios de Señales y Datos
Para cumplir las Recomendaciones de la Estrategia del Movimiento para Garantizar la Equidad en la Toma de Decisiones (Recomendación #4), Mejorar la Experiencia del Usuario (Recomendación #2), y Evaluar, Iterar y Adaptar (Recomendación #10), los responsables de la toma de decisiones de todo el Movimiento Wikimedia deben tener acceso a datos, modelos, perspectivas y herramientas fiables, relevantes y oportunos que puedan ayudarles a evaluar el impacto (tanto real como potencial) de su trabajo y del trabajo de sus comunidades, permitiéndoles tomar mejores decisiones estratégicas.
En el cubo de Servicios de Señales y Datos, hemos identificado cuatro públicos principales: El personal de la Fundación Wikimedia, los afiliados y grupos de usuarios de Wikimedia, los desarrolladores que reutilizan nuestro contenido y los investigadores de Wikimedia, y priorizamos y abordamos las necesidades de datos y conocimientos de estos públicos. Nuestro trabajo abarcará una serie de actividades: definición de brechas, desarrollo de métricas, construcción de canalizaciones para calcular métricas, y desarrollo de experiencias y vías de exploración de datos y señales que ayuden a los responsables de la toma de decisiones a interactuar de forma más eficaz y amena con los datos y las percepciones.
Públicos futuros
.svg)
El propósito de este cubo es explorar estrategias para expandirnos más allá de nuestras audiencias actuales de consumidores y contribuyentes, en un esfuerzo por llegar realmente a todo el mundo como infraestructura esencial del ecosistema del conocimiento libre. Este cubo se alinea con la Recomendación nº 9 de la Estrategia del Movimiento (Innovar en el Conocimiento Libre). Cada vez más, las personas consumen información en experiencias y formas que divergen de nuestra oferta tradicional de un sitio web con artículos: las personas utilizan asistentes de voz, pasan tiempo con el vídeo, interactúan con la IA y mucho más. En este cubo, propondremos y probaremos hipótesis en torno a posibles futuros a largo plazo para el ecosistema del conocimiento libre y cómo seremos su infraestructura esencial. Lo haremos a través del trabajo en productos y tecnología, así como a través de la investigación, las asociaciones y el marketing. A medida que identifiquemos futuros escenarios prometedores, los aprendizajes de este cubo influirán y se ampliarán a través de los cubos nº 1 y nº 2 en los sucesivos planes anuales, impulsando nuestras ofertas de productos y tecnología hacia donde deben estar para servir a los buscadores de conocimiento del futuro. Nuestros objetivos para este cubo deben impulsarnos a experimentar y explorar mientras enfocamos una visión del futuro del conocimiento libre.
Sub-cubos
También tenemos otros dos "sub-cubos" que consisten en áreas de funciones críticas, que deben existir en la Fundación para apoyar nuestras operaciones básicas, y algunas de las cuales tenemos en común con cualquier organización de software. Estos "sub-cubos" no tendrán objetivos propios de nivel superior, sino que aportarán y apoyarán los objetivos de nivel superior de los otros grupos. Son:
- Fundamentos de la Infraestructura. Este cubo abarca los equipos que sostienen y hacen evolucionar nuestros centros de datos, nuestras plataformas de cálculo y almacenamiento, los servicios para hacerlos funcionar, las herramientas y procesos que permiten el funcionamiento de nuestros sitios y servicios de cara al público.
- Apoyo de productos e ingeniería. Este cubo incluye equipos que operan "a escala" prestando servicios a otros equipos que mejoran la productividad y las operaciones de otros equipos.