Plan Annuel de la Fondation Wikimédia/2024-2025/Objectifs et résultats clés des produits et technologies
Ce document représente la première partie du processus de planification annuelle 2024-2025 pour les départements Produit et Technologie de la Fondation Wikimedia. Il décrit les «le brouillon des objectifs et résultats clés» (OKRs). Il s'agit de la continuation de la structure des dossiers de travail (appelés « buckets » et traduits par «paniers») introduits l'an passé.
.jpg)
En novembre dernier, j'ai discuté avec vous toutes et tous de ce que je crois être la question la plus urgente à laquelle est confronté le mouvement Wikimédia : comment s'assurer que Wikipédia et tous les projets Wikimédia soient multi-générationnels ? J'aimerais remercier toutes celles et ceux qui ont pris le temps de réfléchir à cette question et de me répondre directement. Maintenant que j'ai eu l'occasion de prendre le temps de réfléchir à vos réponses, je vais partager ce que j'ai appris.
Tout d'abord, il n'y a pas qu'une seule raison pour laquelle les bénévoles apportent leur contribution. Afin d'encourager plusieurs générations de bénévoles, nous devons mieux comprendre les nombreuses raisons pour lesquelles les gens consacrent du temps à nos projets. Ensuite, nous devons nous concentrer sur ce qui nous distingue : notre capacité à fournir un contenu digne de confiance alors que la désinformation et les fausses informations prolifèrent sur l'internet et sur les plateformes qui se disputent l'attention des nouvelles générations. Il s'agit notamment de s'assurer que nous remplissons notre mission, qui est de rassembler et de transmettre au monde la somme de toutes les connaissances humaines, en élargissant notre couverture des informations manquantes, qui peuvent être dues à l'iniquité, à la discrimination ou aux préjugés. Notre contenu doit également servir et rester vital dans un internet en pleine mutation, mû par l'intelligence artificielle et les expériences enrichies. Enfin, nous devons trouver des moyens de financer durablement notre mouvement en élaborant une stratégie commune pour nos produits et nos revenus afin de pouvoir financer ce travail à long terme.
Ces idées seront reflétées dans le plan annuel 2024-2025 de la Fondation Wikimédia, dont je partage la première partie avec vous aujourd'hui sous la forme d'un projet d'objectifs pour notre travail sur les produits et la technologie. Comme l'année dernière, l'ensemble de notre plan annuel sera centré sur les besoins technologiques de nos publics et de nos plateformes, et nous aimerions connaître votre avis pour savoir si nous nous concentrons sur les bons problèmes. Ces objectifs s'appuient sur les idées que les membres de la communauté nous ont communiquées au cours des derniers mois par le biais de Talking:2024, sur les listes de diffusion et les pages de discussion, ainsi que lors d'événements communautaires, concernant notre stratégie produit et technologique pour l'année à venir. Vous pouvez consulter la liste complète des objectifs provisoires ci-dessous.
Un « objectif » est une orientation de haut niveau qui déterminera les produits et les projets technologiques que nous entreprendrons au cours de l'exercice suivant. Ils sont volontairement larges, représentent l'orientation de notre stratégie et, surtout, les défis que nous proposons de traiter en priorité parmi les nombreux domaines d'intervention possibles pour l'année à venir. Nous partageons ces informations dès maintenant afin que les membres de la communauté puissent contribuer à façonner notre réflexion préliminaire, et ce avant que des budgets et des objectifs mesurables ne soient engagés pour l'année.
Retours
L'un des domaines dans lesquels nous aimerions particulièrement recevoir un retour d'information est notre travail regroupé sous le nom de « Wiki Experiences ». Ce dernier porte sur la manière dont nous fournissons, améliorons et innovons efficacement la façon dont les gens utilisent directement les wikis, que ce soit en tant que contributeurs, consommateurs ou donateurs. Cela implique de soutenir notre technologie et nos capacités de base et de s'assurer que nous pouvons améliorer l'expérience des rédacteurs et rédactrices bénévoles — en particulier les personnes avec des droits étendus — grâce à de meilleures fonctionnalités et outils, des services de traduction et des mises à niveau de la plateforme.
Voici quelques réflexions de nos récentes discussions sur la planification, et quelques questions pour vous toutes et tous pour nous aider à affiner nos idées :
- Le bénévolat sur les projets Wikimédia devrait être gratifiant. Nous pensons aussi que l'expérience de la collaboration en ligne devrait être une partie importante de ce qui fait que les bénévoles reviennent. Qu'est-ce qui est nécessaire pour que les volontaires trouvent l'édition gratifiante et travaillent mieux ensemble pour créer du contenu digne de confiance?
- La fiabilité de notre contenu fait partie de la contribution unique de Wikimedia au monde, et c'est ce qui permet aux gens de venir sur notre plateforme et d'utiliser notre contenu. Qu'est-ce que nous pouvons construire qui aidera à développer un contenu fiable plus rapidement, mais toujours dans les limites de qualité fixées par les communautés sur chaque projet ?
- Pour rester pertinents et rivaliser avec d'autres grandes plateformes en ligne, Wikimédia a besoin d'une nouvelle génération de consommateurs et consommatrices pour se sentir en connexion avec notre contenu. Comment pouvons-nous rendre notre contenu plus facile à découvrir et à interagir avec les personnes constituant le lectorat et les personnes faisant des dons ?
- À une époque où les abus en ligne prospèrent, nous devons nous assurer que nos communautés, notre plateforme et notre système de service sont protégés. Nous sommes également confrontés à l’évolution des obligations de conformité, où les décideurs politiques du monde entier cherchent à façonner la vie privée, l'identité et le partage d'informations en ligne. Quelles améliorations apportées à notre capacité à lutter contre les abus nous aideront à relever ces défis ?
- MediaWiki, la plateforme logicielle et les interfaces qui permettent à Wikipédia de fonctionner, a besoin d'un soutien continu pour la prochaine décennie afin de fournir la création, la modération, le stockage, la découverte et la consommation de contenu ouvert et multilingue à grande échelle. Quelles décisions et quelles améliorations de la plateforme pouvons-nous faire cette année pour assurer la durabilité de MediaWiki ?
Projet d'objectifs
Le niveau de planification le plus élevé - les « Objectifs » - est actuellement publié.
Le niveau suivant - l'ébauche des «Résultats clés» (RC) pour chaque objectif finalisé sera disponible ci-dessous.
Les « Hypothèses » sousjacentes à chaque RC seront mises à jour sur les pages wiki du projet/de l'équipe concerné(e) tout au long de l'année, au fur et à mesure que des enseignements sont tirés.
| Projet d'objectifs Wiki Experiences (WE) | ||||
|---|---|---|---|---|
| Objectif | Champ de l'objectif | Objectif | Contexte de l'objectif | Titulaire |
| WE1 | Expérience des contributeurs | Des contributeurs expérimentés et novices se rassemblent en ligne pour construire une encyclopédie fiable, avec plus de facilité et moins de frustration. | Pour que Wikipédia soit dynamique dans les années à venir, nous devons travailler à l'épanouissement de plusieurs générations de bénévoles et faire en sorte que les gens aient envie de contribuer. Les différentes générations de bénévoles ont besoin d'investissements différents - les contributeurs plus expérimentés ont besoin que leurs flux de travail puissants soient rationalisés et réparés, tandis que les nouveaux contributeurs ont besoin de nouvelles façons de modifier qui leur conviennent. Et à travers ces générations, « tous » les contributeurs doivent être en mesure de se connecter et de collaborer les uns avec les autres afin d'accomplir leur travail le plus efficace. Dans cette optique, nous améliorerons les flux de travail essentiels pour les contributeurs expérimentés, nous réduirons les obstacles aux contributions constructives pour les nouveaux venus et nous investirons dans des moyens permettant aux bénévoles de se trouver et de communiquer entre eux autour d'intérêts communs. | Marshall Miller |
| WE2 | Contenu encyclopédique | Les communautés sont soutenues pour combler efficacement les lacunes de connaissances grâce à des outils et des systèmes de soutien qui sont plus faciles à accéder, à adapter et à améliorer, ce qui assure une croissance accrue du contenu encyclopédique fiable. | Le contenu encyclopédique principalement sur Wikipédia peut être augmenté et amélioré par un engagement continu et une innovation. Les outils et ressources (techniques et non techniques) qui sont disponibles pour les contributeurs pour les utiliser pour leurs besoins peuvent être rendus plus découverts et fiables. Ces outils devraient être mieux soutenus par le FSM, grâce à des améliorations des fonctionnalités pouvant être réalisées en courts cycles. Compte tenu des tendances récentes en matière de génération de contenu assisté par l'IA et de changement du comportement des utilisateurs, nous allons également explorer les bases pour des changements substantiels (par exemple Wikifunctions) qui peuvent aider à une croissance à l'échelle de la création et de la réutilisation de contenu. Les mécanismes permettant d'identifier les lacunes en matière de contenu devraient être plus faciles à découvrir et à planifier. Les ressources qui soutiennent la croissance du contenu encyclopédique, y compris le contenu sur les projets sœurs, des projets tels que la bibliothèque de Wikipédia et des campagnes peuvent être mieux intégrées aux flux de travail de contribution. En même temps, les méthodes utilisées pour la croissance devraient avoir des barreaux contre les menaces croissantes, qui peuvent assurer qu'il y a une confiance continue dans le processus tout en restant fidèle aux principes de base du contenu encyclopédique comme reconnu dans les projets Wikimedia.
Publics visés : rédacteurs, traducteurs |
Runa Bhattacharjee |
| WE3 | L'expérience des consommateurs (Lecture et médias) | Une nouvelle génération de consommateurs arrive sur Wikipédia pour découvrir une destination préférée permettant de découvrir, engager et établir une connexion durable avec le contenu encyclopédique. | Objectifs :
Retenir les générations actuelles et nouvelles de consommateurs et de donateurs. Accroître la pertinence pour les générations de consommateurs existantes et nouvelles en facilitant la découverte et l'interaction avec notre contenu. Travailler sur plusieurs plateformes pour adapter nos expériences et le contenu existant, afin que le contenu encyclopédique puisse être exploré et géré par et pour une nouvelle génération de consommateurs et de donateurs. |
Olga Vasileva |
| WE4 | Confiance et sécurité | Améliorer notre infrastructure, nos outils et nos processus afin d'être bien équipés pour protéger les communautés, la plateforme et nos systèmes de service contre différents types d'abus ciblés et à grande échelle, tout en restant en conformité avec un environnement réglementaire en constante évolution. | Certains aspects de nos capacités de lutte contre les abus ont besoin d'être améliorés. L'atténuation des abus basés sur l'IP devient moins efficace, plusieurs outils d'administration ont besoin d'être améliorés, et nous devons mettre en place une stratégie unifiée qui nous aide à combattre les abus à grande échelle en utilisant de concert les différents signaux et mécanismes d'atténuation (captchas, blocages, etc.). Au cours de cette année, nous commencerons à progresser sur les problèmes les plus importants dans ce domaine. En outre, cet investissement dans la protection contre les abus doit être équilibré par un investissement dans la compréhension et l'amélioration de la santé communautaire, dont plusieurs aspects sont inclus dans diverses exigences réglementaires. | Suman Cherukuwada |
| WE5 | Plate-forme de connaissances I (évolution de la plate-forme) | Faire évoluer la plateforme MediaWiki et ses interfaces pour mieux répondre aux besoins fondamentaux de Wikipédia. | MediaWiki a été construit pour permettre la création, la modération, le stockage, la découverte et la consommation de contenu ouvert et multilingue à grande échelle. Dans cette deuxième année de la Plateforme de la connaissance, nous examinerons le système et commencerons à travailler sur des améliorations de la plateforme pour soutenir efficacement les besoins fondamentaux des projets Wikimedia au cours de la prochaine décennie, à commencer par Wikipédia. Cela inclut la poursuite des travaux visant à définir notre plateforme de production de connaissances, le renforcement de la durabilité de la plateforme, l'accent mis sur le système d'extensions/crochets pour clarifier et rationaliser le développement des fonctionnalités, et la poursuite de l'investissement dans le partage des connaissances et la possibilité pour les gens de contribuer à MediaWiki. | Birgit Müller |
| WE6 | Plate-forme de connaissances II (Services aux développeurs) | Le personnel technique et les développeurs bénévoles ont les outils dont ils ont besoin pour soutenir efficacement les projets Wikimedia. | Nous continuerons les travaux commencés pour améliorer (et élargir) les flux de travail de développement, de test et de déploiement dans Wikimedia Production et étendre la définition pour inclure des services pour les développeurs d'outils. Nous visons également à améliorer notre capacité à répondre aux questions fréquemment posées dans le domaine des flux de travail et des publics de développeurs/ingénieurs et à rendre les données pertinentes accessibles pour permettre une prise de décision éclairée. Une partie de ce travail consiste à examiner les pratiques (ou l'absence de telles pratiques) qui présentent actuellement un défi pour notre écosystème. | Birgit Müller |
| Services de signaux et de données (SDS) projets d'objectifs | ||||
|---|---|---|---|---|
| Objectif | Champ de l'objectif | Objectif | Contexte de l'objectif | Titulaire |
| SDS1 | perspectives partagées | Nos décisions sur la façon de soutenir la mission et le mouvement Wikimédia sont informées par des mesures et des informations de haut niveau. | Pour que nous puissions construire efficacement et efficacement la technologie, soutenir les bénévoles et défendre des politiques qui protègent et favorisent l'accès au savoir, nous devons comprendre l'écosystème Wikimedia et nous aligner sur ce que le succès ressemble. Cela signifie suivre un ensemble commun de mesures fiables, compréhensibles et disponibles en temps opportun. Cela signifie aussi faire apparaître des recherches et des idées qui nous aident à comprendre les raisons et les moyens de mesurer. | Kate Zimmerman |
| SDS2 | Plateforme d'expérimentation | Les gestionnaires de produits peuvent évaluer rapidement, facilement et avec confiance les impacts des caractéristiques du produit. | Pour permettre et accélérer la prise de décision informée sur le développement des caractéristiques des produits, les gestionnaires de produits ont besoin d'une plateforme d'expérimentation dans laquelle ils peuvent définir les caractéristiques, sélectionner les audiences de traitement des utilisateurs et voir les mesures d'impact. Accélérer le temps de lancement à l'analyse est essentiel, car raccourcir le calendrier d'apprentissage accélérera l'expérimentation et, en fin de compte, l'innovation. Les tâches manuelles et les approches de mesure sur mesure ont été identifiées comme des obstacles à la vitesse. Le scénario idéal est que les gestionnaires de produits puissent passer du lancement d'expériences à la découverte avec peu ou pas d'intervention manuelle des ingénieurs et des analystes. | Tajh Taylor |
| Objectif provisoire de Audiences futures (FA) | ||||
|---|---|---|---|---|
| Objectif | Champ de l'objectif | Objectif | Contexte de l'objectif | Titulaire |
| FA1 | Hypothèses de test | Fournir des recommandations sur les investissements stratégiques à la Fondation Wikimedia à poursuivre - basées sur des informations provenant d'expériences qui affinent notre compréhension de la façon dont les connaissances sont partagées et consommées en ligne - qui aident notre mouvement à servir de nouveaux publics dans une internet en évolution. | En raison des changements continus de la technologie et du comportement des utilisateurs en ligne (par exemple, une préférence croissante pour obtenir des informations via des applications sociales, la popularité de l'éducation vidéo courte, la montée de l'IA générative), le mouvement Wikimedia fait face à des défis pour attirer et retenir des lecteurs et des contributeurs. Ces changements offrent également des opportunités de servir de nouveaux publics en créant et en diffusant de nouvelles informations. Cependant, nous ne disposons pas d'une image claire et basée sur des données des avantages et des compromis des différentes stratégies potentielles que nous pourrions poursuivre pour surmonter les défis ou saisir de nouvelles opportunités. Par exemple, devrions-nous...
Pour que Wikimedia devienne un projet multi-générationnel, nous testerons les hypothèses pour mieux comprendre et recommander des stratégies prometteuses - pour la Fondation Wikimedia et le mouvement Wikimedia - à poursuivre pour attirer et retenir les futurs publics. |
Maryana Pinchuk |
| Objectif provisoire de Support produit et ingénierie (SPI) | ||||
|---|---|---|---|---|
| Objectif | Champ de l'objectif | Objectif | Contexte de l'objectif | Titulaire |
| PES1 | Efficacité des opérations | Faire le travail de la Fondation plus rapide, moins cher et plus efficace. | Le personnel fait beaucoup dans son travail régulier pour rendre nos opérations plus rapides, moins chères et plus efficaces. Cet objectif met en évidence des initiatives spécifiques qui a) réaliseront des gains substantiels vers des résultats plus rapides, moins chers ou plus efficaces; et b) entreprendront des efforts coordonnés et changeront les pratiques formelles et informelles de la Fondation. Les RK inclus dans cet objectif sont essentiellement les améliorations les plus difficiles et les plus efficaces que nous puissions apporter cette année à l'efficacité opérationnelle des travaux touchant nos produits et notre technologie. | Amanda Bittaker |
Résultats clés de l'appel d'offres
Le brouillon des «Résultats clés» (RC) pour chaque objectif finalisé est ici. Ils correspondent à chacun des objectifs ci-dessus.
Les "hypothèses" sous-jacentes pour chaque RC seront mises à jour sur les pages wiki du projet/de l'équipe concernée tout au long de l'année, au fur et à mesure que des enseignements sont tirés.
| Brouillon des résultats clés de Wiki Experiences (WE) | |||
|---|---|---|---|
| Abbreviation du résultat clé | Texte du résultat clé | Contexte du résultat clé | Responsable |
| WE1.1 | Développer ou améliorer un flux de travail qui aide les contributeurs ayant des intérêts communs à se connecter et à contribuer ensemble. | Nous pensons que les espaces communautaires et les interactions sur les wikis rendent les gens plus heureux et plus productifs en tant que contributeurs. De plus, les espaces communautaires aident à introduire et guider les nouveaux arrivants, modélisent les meilleures pratiques de contribution et aident à combler les lacunes de connaissances. Cependant, les ressources, outils et espaces existants qui soutiennent la connexion humaine sur les wikis sont de mauvaise qualité et ne répondent pas aux défis et aux besoins de la majorité des rédacteurs aujourd'hui. Entre-temps, le travail de l'équipe des campagnes a démontré que de nombreux organisateurs sont impatients d'adopter et d'expérimenter de nouveaux outils avec des flux de travail structurés qui les aident dans leur travail communautaire. Pour ces raisons, nous voulons nous concentrer sur l'encouragement et la promotion d'un sentiment d'appartenance parmi les contributeurs sur les wikis. | Ilana Fried |
| WE1.2 | Activation constructive: #% Augmentation annuelle du pourcentage de nouveaux arrivants qui publient ≥1 modification constructive dans l'espace de noms principal sur un appareil mobile. |
Les expériences actuelles d’édition de pleine page nécessitent trop de contexte, de patience et d’essais et d’erreurs pour que de nombreux nouveaux arrivants puissent contribuer de manière constructive. Pour soutenir une nouvelle génération de bénévoles, nous augmenterons le nombre et la disponibilité de flux de travail d'édition plus petits, structurés et plus spécifiques à des tâches (par exemple, Edit Check et Structured Tasks).
Remarque: Les références ne seront établies que vers la fin du quatrième trimestre de l'exercice en cours, après quoi notre pourcentage de mesure cible RC sera également établi. |
Peter Pelberg |
| WE1.3 | Augmenter la satisfaction des utilisateurs avec 4 produits de modération de X%. | Les rédacteurs avec des droits étendus utilisent une large gamme de fonctionnalités, d'extensions, d'outils et de scripts existants pour effectuer des tâches de modération sur les projets Wikimedia. Cette année, nous voulons nous concentrer sur l'amélioration de ces outils plutôt que sur des projets visant à créer de nouvelles fonctionnalités dans cet espace. Nous avons l'intention de toucher un certain nombre de produits au cours de l'année, et nous voulons améliorer chacun d'eux de manière significative. Nous espérons ainsi améliorer l'expérience globale de la modération du contenu. Nous définirons X% lors de la mesure des lignes de base pour certains outils de modérateur communs que nous pouvons cibler avec ce flux de travail. La liste des souhaits de la communauté contribuera de manière substantielle à la décision des priorités de ce programme. 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 | À la fin du deuxième trimestre (Q2), soutenir les organisateurs, les contributeurs et les institutions avec des outils, des idées et des approches spécifiques pour augmenter la couverture du contenu de qualité dans les domaines thématiques clés [à déterminer] de X%. | Ce RC vise à améliorer la couverture thématique afin de réduire les lacunes existantes dans les connaissances. Nous avons établi que les communautés bénéficient d'outils efficaces associés à des campagnes visant à améliorer la qualité du contenu de nos projets. Cette année, nous souhaitons nous concentrer sur l’amélioration des outils existants et expérimenter de nouvelles façons de prioriser les domaines thématiques clés qui comblent les lacunes dans les connaissances. Notre objectif de croissance de la couverture de X% sera déterminé en examinant les bases existantes de création de contenu de qualité. De plus, les sujets sur lesquels nous nous concentrerons avec les communautés et les institutions seront déterminés d’ici le prochain trimestre. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | D'ici la fin du deuxième trimestre, mettre en œuvre et tester deux recommandations, à la fois sociales et techniques, pour soutenir l'intégration des langues dans les petites communautés linguistiques, avec une évaluation pour analyser les commentaires de la communauté. | Il y a environ 300 éditions linguistiques de Wikipédia. Et pourtant, il existe de nombreuses autres langues parlées par des millions de personnes, dans lesquelles il n’existe ni Wikipédia ni aucun projet Wiki. Cela fait obstacle à la réalisation de notre vision: Que chaque être humain puisse partager librement la somme de toutes les connaissances. L'incubateur Wikimédia est l'endroit où les wikis potentiels de projets Wikimedia dans des versions dans une nouvelle langue peuvent être organisés, écrits, testés et prouvés dignes d'être hébergés par la Fondation Wikimedia. L'Incubateur a été lancé en 2006, avec l'hypothèse que ses utilisateurs auraient des connaissances préalables en matière d'édition de wiki. Ce problème est accentué par le fait que ce processus est censé être principalement effectué par les personnes les plus récentes et les moins expérimentées dans notre mouvement. Bien que l'édition sur les wikis Wikimedia se soit considérablement améliorée depuis, l'incubateur n'a pas reçu ces mises à jour en raison de limitations techniques. Actuellement, il faut plusieurs semaines pour qu'un wiki sorte de l'Incubateur. Seulement 12 wikis sont créés en moyenne chaque année, ce qui montre un blocage important.
Les recherches et documents existants révèlent des défis techniques à chaque phase de l'intégration des langues: Ajout de nouvelles langues à l'incubateur, complexités liées au développement et à la révision du contenu, et lenteur du processus de création d'un site wiki lorsqu'une langue sort de l'incubateur. Chaque phase est lente, manuelle et complexe, indiquant la nécessité d'une amélioration. Résoudre ce problème permettra de créer des wikis dans de nouvelles langues plus rapidement et plus facilement, et permettra à davantage de personnes de partager leurs connaissances. Plusieurs parties prenantes, recherches et ressources existantes ont mis en évidence les recommandations proposées à la fois sociales et techniques. Ce résultat clé propose de tester deux recommandations à la fois sociales et techniques et d'évaluer les retours de la communauté. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | À la fin du deuxième trimestre, 2 nouvelles fonctionnalités guideront les contributeurs à ajouter des documents sources conformes aux directives des projets, et 3-5 partenaires auront contribué à des documents sources qui abordent les lacunes linguistiques et géographiques. | Pour accroître l’accès au matériel source de qualité nécessaire pour combler les lacunes stratégiques en matière de contenu, nous allons:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | À la fin du Q2, activer les appels Wikifunctions sur au moins une langue d'une Wikipédia de petite taille pour fournir un moyen plus évolutif de semer de nouveaux contenus. | Afin de réduire efficacement nos lacunes en matière de connaissances, nous devons améliorer les flux de travail qui soutiennent une croissance évolutive du contenu de qualité, en particulier dans les petites communautés linguistiques. | Amy Tsay |
| WE3.1 | Libérer deux expériences de navigation et d'apprentissage organisées, accessibles et pilotées par la communauté, sur des wikis représentatives, dans le but d'augmenter de 5% la rétention des lecteurs déconnectés des utilisateurs expérimentés. | Ce RC porte sur l'augmentation de la rétention d'une nouvelle génération de lecteurs sur notre site Web, permettant à une nouvelle génération d'établir une connexion durable avec Wikipedia, en explorant les opportunités pour les lecteurs de découvrir et d'apprendre plus facilement du contenu qui les intéresse. Cela comprendra l'exploration et le développement de nouvelles expériences de navigation et d'apprentissage organisées, personnalisées et axées sur la communauté (par exemple, un flux de contenu pertinent, des recommandations et des suggestions de contenu actuels, des opportunités d'exploration de contenu organisées par la communauté, etc.).
Nous prévoyons de commencer l'année fiscale en expérimentant une série d'expériences de navigation pour déterminer celle que nous souhaitons adapter à une utilisation en production et sur quelle plateforme (web, applications ou les deux). Nous nous concentrerons ensuite sur la mise à l'échelle de ces expériences et tester leur efficacité dans l'augmentation de la rétention dans les environnements de production. Notre but d'ici la fin de l'année est de lancer au moins deux expériences sur des wikis représentatives et de mesurer avec précision une augmentation de 5% de la rétention des lecteurs engagés dans ces expériences. Pour être efficace de manière optimale dans la réalisation de ce RC, nous aurons besoin de pouvoir effectuer des tests A/B avec des utilisateurs déconnectés, ainsi que d'instruments capables de mesurer la rétention des lecteurs. Nous pourrions également avoir besoin de nouvelles API ou services nécessaires pour présenter des recommandations et d'autres mécanismes de curation. |
Olga Vasileva |
| WE3.2 | Une augmentation de 50% du nombre de dons via les points de contact en dehors de la bannière annuelle et des appels par email par plateforme. | Notre objectif est de fournir une diversité de sources de revenus tout en reconnaissant nos donateurs existants. Sur la base des commentaires et des données, nous nous efforçons d'augmenter le nombre de dons au-delà des méthodes sur lesquelles la Fondation s'est appuyée dans le passé, en particulier les appels de bannières annuels. Nous voulons montrer qu’en investissant dans des expériences de donateurs plus intégrées, nous pouvons rendre notre travail plus durable, et étendre notre impact en offrant une alternative aux donateurs actuels et potentiels qui ne répondent pas aux appels de bannières. 50% est une première estimation basée sur la diminution de la visibilité du bouton de don sur le Web suite à Vector 2022, et l'augmentation du nombre de dons du projet pilote de l'exercice 2023-2024 sur les applications Wikipédia pour améliorer l'expérience des donateurs (50,1% d'augmentation de dons). L'évaluation de cette mesure par plateforme nous aidera à comprendre les tendances des plateformes, et si différentes tactiques devraient être déployées à l'avenir en fonction d'une différence de comportement dépendant de l'audience de la plateforme. | 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 | Fournir une proposition de 3 contre-mesures face au harcèlement et le contenu nocif, en fonction des données et de l'évolution du contexte réglementaire d'ici le troisième trimestre. | Garantir la sécurité et le bien-être des utilisateurs est une responsabilité fondamentale des plateformes en ligne. De nombreuses juridictions ont des lois et des règlements qui exigent que les plateformes en ligne prennent des mesures contre le harcèlement, le cyberintimidation et d'autres contenus nuisibles. En cas de non-respect de ces problèmes, les plateformes pourraient être soumises à des sanctions légales et réglementaires.
Nous ne savons pas encore à quel point ces problèmes sont importants, ni les raisons qui les ont causés. Nous nous appuyons fortement sur des preuves anecdotiques et des processus manuels qui nous exposent à des risques juridiques ainsi qu'à d'autres conséquences de grande portée: Sous-estimation du problème, escalade des préjudices, dommages à la réputation et érosion de la confiance des utilisateurs. Nous devons construire une culture forte de mesure de l'incidence du harcèlement et du contenu nocif, et mettre en œuvre des contre-mesures de manière proactive . |
Madalina Ana |
| WE4.2 | Développer au moins deux signaux à utiliser dans les flux de travail anti-abus pour améliorer la précision des actions contre les mauvais acteurs d'ici le troisième trimestre. | Les wikis s'appuient fortement sur le blocage IP comme mécanisme pour bloquer le vandalisme, le spam et les abus. Mais les adresses IP sont de moins en moins utiles en tant qu’identifiants stables d’un acteur individuel, et le blocage des adresses IP a des effets négatifs involontaires sur les utilisateurs de bonne foi qui partagent la même adresse IP que celle des acteurs malveillants. La combinaison de la stabilité décroissante des adresses IP et de notre forte dépendance au blocage IP se traduit par une précision et une efficacité moindres dans le ciblage des acteurs malveillants, en même temps que les dommages collatéraux augmentent pour les utilisateurs de bonne foi. Nous souhaitons voir la situation inverse: Une diminution des niveaux de dommages collatéraux et une précision accrue dans les mesures d’atténuation ciblant les mauvais acteurs.
Pour mieux soutenir le travail des fonctionnaires en matière de lutte contre les abus, et fournir des éléments de base pour la réutilisation des outils existants (par exemple, CheckUser, Special:Block) et nouveaux, dans ce rapport, nous proposons d'explorer des moyens d'associer de manière fiable un individu à ses actions (atténuation des problèmes de faux-nez), et de combiner les signaux existants (par exemple adresses IP, historique de compte, attributs de requête) pour permettre un ciblage plus precis des actions sur les acteurs malveillants. |
Kosta Harlan |
| WE4.3 | Réduire l'efficacité d'une attaque distribuée à grande échelle de 50% en fonction du temps nécessaire pour adapter nos mesures et le volume de trafic que nous pouvons maintenir dans une simulation. | L'évolution du monde d'Internet, notamment la montée des botnets à grande échelle et les attaques plus fréquentes, ont rendu obsolètes nos méthodes traditionnelles de limitation des abus à grande échelle. De telles attaques peuvent rendre nos sites inaccessibles en inondant nos infrastructures de requêtes ou en submergeant la capacité de notre communauté à lutter contre le vandalisme à grande échelle. Cela exerce aussi une pression excessive sur nos éditeurs hautement privilégiés et sur notre communauté technique.
Nous devons de toute urgence améliorer notre capacité à détecter, résister et atténuer ou arrêter de telles attaques. Pour mesurer nos améliorations, nous ne pouvons pas nous fier uniquement à la fréquence/intensité des attaques réelles, car nous dépendrions d'actions extérieures, et il serait difficile d'avoir une image quantitative claire de nos progrès. En mettant en place plusieurs attaques simulées de nature/complexité/durée variables à exécuter en toute sécurité contre notre infrastructure, et en les exécutant tous les trimestres, nous serons en mesure à la fois de tester nos nouvelles contre-mesures sans être attaqués, et de rendre compte objectivement de nos améliorations. |
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 | Pour le troisième trimestre, compléter au moins 5 interventions visant à accroître la durabilité de la plateforme. | La durabilité de la plateforme MediaWiki est un effort permanent important pour notre capacité à évoluer, augmenter ou éviter la dégradation de la satisfaction des développeurs, et à développer notre communauté technique. Ceci est difficile à mesurer et dépend de facteurs techniques et sociaux. Cependant, nous disposons de connaissances tacites sur des domaines spécifiques d’amélioration qui sont stratégiques pour la durabilité. Les interventions prévues peuvent contribuer à accroître la durabilité et la maintenabilité de la plateforme ou à éviter sa dégradation. Nous prévoyons d'évaluer l'impact de ce travail au quatrième trimestre avec des recommandations sur les objectifs de développement durable à l'avenir. Voici des exemples d'interventions en matière de durabilité: Simplifier les domaines de code complexes qui sont au cœur de MediaWiki, mais seule une poignée de personnes savent comment cela fonctionne; accroître l'utilisation d'outils d'analyse de code pour informer sur la qualité de notre base de code; rationaliser les processus tels que le packaging et le versionnage. | Mateus Santos |
| WE5.2 | Identifier d'ici le 2e trimestre, et compléter d'ici le 4e trimestre, une ou plusieurs interventions pour évoluer les interfaces de programmation de l'environnement MediaWiki, afin de permettre le développement de fonctionnalités déconnectées, plus simples et plus durables. | L'objectif principal du RC 5.2 est d'améliorer et de clarifier l'interaction entre la plateforme de base de MediaWiki et ses extensions, les habillages et autres parties. Notre intention est de fournir des améliorations fonctionnelles à l'architecture de MediaWiki qui permettent une modularité pratique et une meilleure maintenance, pour lesquelles il est plus facile de développer des extensions, et de renforcer les exigences de la vision plus générale du produit MediaWiki. Ce travail vise également à informer ce qui devrait exister (ou non) dans le noyau, les extensions ou les interfaces entre elles. L'année sera divisée en deux phases: Une phase de recherche et d'expérimentation de 5 mois qui informera la deuxième phase, où des interventions spécifiques seront mises en œuvre. | Jonathan Tweed |
| WE5.3 | À la fin du deuxième trimestre (Q2), compléter une initiative de collecte de données et une expérience d'amélioration des performances pour informer les interventions de suivi des produits et des plateformes afin de tirer parti des capacités activées par la modélisation d'une page par MediaWiki en tant que composition de fragments structurés. | L'objectif principal ici est de permettre aux développeurs et aux chefs de produit d'exploiter les nouvelles capacités de la plateforme MediaWiki pour répondre aux besoins actuels et futurs en matière de contenu encyclopédique, en rendant possible de nouvelles offres de produits qui sont actuellement difficiles à mettre en œuvre, ainsi qu'en améliorant les performances et la résilience de la plateforme.
Plus précisément, au niveau de la plateforme MediaWiki, nous voulons transformer le modèle de traitement de MediaWiki, d'un modèle qui traite une page comme une unité monolithique, à un qui traite une page comme une composition d'unités de contenu structurées. Les vues de lecture basées sur des parsoïdes, l'intégration de Wikidata et l'intégration de Wikifunctions dans les wikis sont tous des actions implicites vers cela. Dans le cadre de ce RC, nous voulons expérimenter et collecter plus intentionnellement des données pour informer les interventions futures basées sur ces nouvelles capacités afin de nous assurer de pouvoir atteindre l'infrastructure et les impacts des produits envisagés. |
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 | Résoudre 5 questions pour permettre l'efficacité et des décisions éclairées sur les flux de travail et les services de développement et d'ingénierie et rendre les données pertinentes accessibles d'ici la fin du quatrième trimestre (Q4). | «C'est compliqué» est une réponse fréquente à des questions telles que «Quels référentiels sont déployés pour la production Wikimédia». Dans ce RC, nous explorerons certains de nos «feuilles persistantes» dans le domaine de la productivité et de l'expérience en ingénierie: Des questions récurrentes qui semblent faciles mais auxquelles il est difficile de répondre, des questions auxquelles nous pouvons répondre, mais les données ne sont pas accessibles et nécessitent des requêtes personnalisées de la part d'experts en la matière, ou des questions difficiles à répondre en raison d'une lacune dans le processus ou pour d'autres raisons. Nous définirons ce que «résoudre» signifie pour chacune des questions: Pour certaines, cela peut simplement signifier rendre accessibles des données existantes et précises, alors que pour d’autres, cela nécessitera davantage de temps de recherche et d’ingénierie pour y répondre. L'objectif principal de ce travail est de réduire le temps, les solutions de contournement et les efforts nécessaires pour obtenir des informations sur les aspects clés de l'expérience des développeurs et nous permettre d'apporter des améliorations aux flux de travail et aux services d'ingénierie et de développement. | [TBD] |
| WE6.2 | D’ici le quatrième trimestre (Q4), améliorer un projet existant et réaliser au moins deux expériences visant à fournir des environnements ciblés et maintenables nous orientant vers une livraison sûre et semi-continue. | Les développeurs et les utilisateurs dépendent du cluster Wikimedia Beta (bêta) pour détecter les bugs avant qu'ils n'affectent les utilisateurs en production. Au fil du temps, les utilisations de la version bêta se sont développées et sont entrées en conflit: Les utilisations sont trop diverses pour s'intégrer dans un seul environnement. Nous améliorerons un environnement alternatif existant et réaliserons des expériences visant à remplacer un seul besoin de test hautement prioritaire actuellement satisfait par la version bêta par un environnement alternatif maintenable qui répond mieux aux besoins de chaque cas d'utilisation. | 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 plate-forme clé pour les outils créés par des bénévoles de Wikimédia, joue un rôle crucial de la rédaction jusqu'à la lutte contre le vandalisme. Notre objectif est d'améliorer l'utilisation de Toolforge, de réduire les obstacles à la contribution, d'améliorer les pratiques communautaires et de promouvoir le respect des politiques établies. À cet effet, nous introduirons un système de notation d'ici le deuxième trimestre pour évaluer la durabilité de la plateforme Toolforge, en nous concentrant sur les aspects techniques et sociaux. En utilisant ce système comme référence, nous viserons à améliorer de 50% l’un des facteurs techniques clés. | Slavina Stefanova |
| Brouillon des résultats clés des services de signaux et de données (SDS) | |||
|---|---|---|---|
| Abbreviation du résultat clé | Texte du résultat clé | Contexte du résultat clé | Responsable |
| SDS1.1 | À la fin du Q2, un programme ou initiative basée sur le RC démontre l'utilisation complète des mesures organisationnelles en intégrant un contenu, des contributeurs ou des mesures de lecteurs dans la conception, l'exécution et l'évaluation de l'initiative. | Nos mesures organisationnelles de base servent de référence à l'évaluation des progrès de la Fondation vers ses objectifs. Au fur et à mesure que nous allouons des ressources aux programmes et concevons des axes de travail basés sur les résultats clés (RC), ces mesures devraient guider la manière avec laquelle nous lions ces investissements aux objectifs primordiaux de la Fondation tels que définis dans le plan annuel. Le travail dans ce RC se concentre sur l'identification d'une initiative, qu'il s'agisse d'un programme ou d'un RC, et sur le partenariat avec ses dirigeants pour intégrer une mesure organisationnelle de base dans la mise en œuvre de l'initiative, du début à la fin. En pratique, cela implique de permettre aux gérants d’initiatives d’intégrer des mesures dans leur travail à travers trois étapes: Conception, exécution et évaluation. Pendant la phase de conception, cela peut impliquer de documenter minutieusement les théories du changement axées sur les métriques ou de définir des références et des objectifs métriques. Lors de la phase d'exécution, les dirigeants pourraient suivre les progrès et ajuster leur approche stratégique à l'aide d'observations métriques. Enfin, les responsables d'initiatives pourraient utiliser les mesures pour évaluer les résultats finaux de leur travail et déterminer si de futurs investissements sont nécessaires. Une grande partie du travail au cours des premier et deuxième trimestres de l'exercice fiscal 2024/2025 sera axée sur la préparation de documents de référence et de ressources pour informer les responsables d'initiatives, sur la sélection d'une initiative appropriée et sur la collaboration avec d'autres responsables pour intégrer des mesures dans leur travail. The work in this key result acknowledges that the Foundation as a whole is at an early stage in its ability to quantitively link the impacts of all planned interventions to high-level, or core metrics. In pursuit of that eventual goal, this KR aims to develop the process by which we share the logical and theoretical links between our initiatives and our high-level metrics. In practice, this means partnering with initiative owners throughout the Foundation to understand how the output of their work at a project level is linked to and impacts our core metrics at a Foundation level. Currently, the Foundation is in an early stage in its goal of being able to execute program or product-driven initiatives and attribute the impact of those activities on Core Foundation level metrics. In pursuit of this goal, this KR aims to do the following: identify at least two candidate program or product driven initiatives, design an evaluation strategy to assess core metric impacts, and execute this evaluation strategy. Starting with two initiatives will help us quickly understand the challenges of performing analyses that allow us to attribute the impact of our work to observable changes in our core metrics. Learnings from this KR will inform a broader strategy to apply this measurement strategy to a wider range and quantity of Foundation initiatives. |
Omari Sefu |
| SDS1.2 | Répondre à 2 questions stratégiques ouvertes de recherche d'ici décembre 2024, afin de fournir des recommandations ou d'informer la planification annuelle de l'année fiscale 2026 | Il existe de nombreuses questions de recherche ouvertes dans l'écosystème Wikimédia. Répondre à certaines d'entre elles est stratégique pour la WMF ou les affiliés. Les réponses à ces questions peuvent éclairer le développement futur de produits ou de technologies, ou peuvent soutenir la prise de décision/le plaidoyer dans l’espace politique. Bien que certaines de ces questions puissent être résolues en utilisant uniquement une expertise en recherche ou en ingénierie de recherche, étant donné la nature socio-technique des projets Wikimédia, parvenir à des informations fiables nécessite souvent une collaboration entre les équipes pour la collecte de données, la création de contexte, l'interaction avec les utilisateurs, la conception minutieuse des expériences, et plus encore. À travers ce RC, nous visons à donner la priorité à certaines de nos ressources pour répondre à une ou plusieurs de ces questions.
Le travail dans ce RC comprend la priorisation d'une liste de questions stratégiques ouvertes, ainsi que la réalisation d'un travail d'expérimentation pour trouver une réponse à un nombre X (actuellement estimé 2) d'entre elle. Le type idéal de questions que nous abordons dans ce RC sont des questions qui, une fois répondues, peuvent avoir un effet débloquant en permettant à plusieurs autres équipes ou groupes de faire un travail (meilleur? mieux informé) sur les produits, la technologie ou les politiques. Nous souhaitons que le travail de ce RC soit complémentaire aux RCs suivants:
|
Leila Zia |
| SDS1.3 | Réduire d'au moins 50% le temps moyen nécessaire aux parties prenantes des données pour comprendre et suivre les flux de données pour trois métriques de base et essentielles | Requis pour les normes de gouvernance des données.
Retracer la transformation et la source des ensembles de données est difficile et nécessite une connaissance des différents repositoires et systèmes. Nous devons faciliter la compréhension de la façon dont les données circulent dans nos systèmes afin que les parties prenantes des données puissent travailler de manière plus autonome. Ce travail soutiendra les flux de travail où les données sont transformées et utilisées pour des tâches d'analyse, de fonctionnalités, d'API et de qualité des données. Il y aura un RC de suivi autour de la documentation des mesures. |
Luke Bowmaker |
| SDS2.1 | À la fin du 2e trimestre (Q2), nous pourrons aider une équipe de produits à évaluer une fonctionnalité ou un produit à travers des tests A/B basiques qui réduisent de 50% le temps nécessaire pour obtenir les données d'interaction avec les utilisateurs. | Nous pensons que l'utilisation d'outils partagés augmentera la confiance des équipes produit dans la prise de décision basée sur les données, améliorera l'efficacité et la productivité, et améliorera la stratégie et l'innovation des produits. Nous examinerons l'adoption du temps individuel de l'équipe pour les données d'interaction des utilisateurs et de l'améliorer de 50%. Nous étudierons également comment contextualiser ces gains dans le contexte plus complet de toutes les équipes produit. Nous espérons apprendre comment améliorer l'expérience et identifier et prioriser les améliorations de capacités en fonction des commentaires de l'équipe adoptante et des résultats de SDS2.2. |
Virginia Poundstone |
| SDS2.2 | D'ici la fin du deuxième trimestre (Q2), nous aurons 2 mesures essentielles pour analyser les expériences (tests A/B) afin de soutenir les hypothèses de test de produits/fonctionnalités liées aux RC de l'exercice fiscal 2024-25. | Lorsqu'un chef de produit (ou un concepteur) donne l'hypothèse qu'un produit/une fonctionnalité répondra à un problème/un besoin pour les utilisateurs ou l'organisation, cette hypothèse est testée par le biais d'une expérience pour découvrir l'impact potentiel de cette idée sur une métrique. Les résultats de l'expérience informent le/a chef de produit et l'aident à prendre une décision sur l'action à entreprendre ensuite (abandonner cette idée et essayer une hypothèse différente, poursuivre le développement si l'expérience a été réalisée au début du cycle de vie du développement, ou publier le produit/la fonctionnalité à davantage d'utilisateurs). Les chefs de produit doivent être capables de prendre une telle décision en toute confiance, grâce à des preuves auxquelles ils font confiance et qu'ils comprennent.
Un obstacle majeur à cela est que les équipes produit formulent actuellement leurs hypothèses avec des mesures personnalisées spécifiques au projet. Ces mesures nécessitent le soutien d'un analyste dédié pour les définir, les mesurer, les analyser et en rendre compte. Passer à un ensemble de mesures essentielles pour formuler toutes les hypothèses testables sur les produits/caractéristiques rendrait:
Nous pensons qu’un ensemble de mesures essentielles qui sont largement comprises et utilisées de manière cohérente – et informées/influencées par les mesures standard de l’industrie – améliorerait également la maîtrise des données organisationnelles et favoriserait une culture de révision, d’expérimentation et d’apprentissage. Nous nous concentrons sur les mesures essentielles qui (1) sont nécessaires pour une meilleure mesure et évaluation du succès/de l'impact des produits/fonctionnalités liées aux 2 RC de Wiki Expériences – WE3.1 et WE1.2 – et (2) reflètent ou cartographient les métriques standard de l'industrie utilisées dans l’analyse 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 |
| Brouillon des résultats clés des public futurs (FA) | |||
|---|---|---|---|
| Abbreviation du résultat clé | Texte du résultat clé | Contexte du résultat clé | Responsable |
| FA1.1 | Grâce aux informations et recommandations expérimentales des publics futurs, à la fin du troisième trimestre (Q3), au moins un objectif ou un résultat clé appartenant à une équipe non-liée aux publics futurs sera présent dans le projet de plan annuel de l'année suivante. | Depuis 2020, la Fondation Wikimédia est en train de suivre les tendances externes qui pourraient avoir un impact sur notre capacité à servir les générations futures de consommateurs et de contributeurs de connaissances et à rester un mouvement de connaissances libre et florissant pour les générations à venir. L'équipe des publics futurs, une petite équipe de R&D, va:
|
Maryana Pinchuk |
| Brouillon des résultats clés de Support Produits et Ingénierie (PES) | |||
|---|---|---|---|
| Abbreviation du résultat clé | Texte du résultat clé | Contexte du résultat clé | Responsable |
| PES1.1 | Culture d'évaluation: Améliorer progressivement les scores du sentiment du personnel P+T concernant notre prestation, notre alignement, notre orientation et la santé de notre équipe dans le cadre d'une enquête trimestrielle. | Une culture d'évaluation est une culture de développement de produits basée sur des cycles plus courts d’itération, d’apprentissage et d’adaptation. Cela signifie que notre organisation peut fixer des objectifs annuels, mais que ce que nous faisons pour atteindre ces objectifs changera et s'adaptera au cours de l'année, à mesure que nous apprenons. La création d’une culture d’évaluation comporte deux éléments: Les processus et les comportements. Ce RC se concentre sur ces derniers. Les changements de comportement peuvent se développer et renforcer notre culture d’évaluation. Cela implique des changements dans les habitudes et routines individuelles à mesure que nous nous dirigeons vers un développement de produits plus itératif. Ce RC sera basé sur les changements auto-déclarés dans les comportements individuels et sur la mesure des changements qui en résultent, le cas échéant, dans le sentiment du personnel. | Amy Tsay |
| PES1.2 | À la fin du deuxième trimestre (Q2), la nouvelle liste de souhaits connectera mieux les idées et les demandes du mouvement aux activités P+T de la Fondation: Les éléments de la liste des souhaits en attente sont traités via un CR 2024-5. La Fondation a réalisé 10 souhaits plus petits et s'est associée à des volontaires pour identifier plus de 3 domaines d’opportunités pour l’exercice 2025-2026. | La Liste de souhaits de la communauté représente une tranche étroite du mouvement. Environ 1 000 personnes participent, dont la plupart sont des contributeurs ou des administrateurs. Les gens contournent souvent la liste de souhaits en écrivant des demandes de fonctionnalités et des rapports de bugs via Phabricator, où il est difficile de discerner les demandes venant de la WMF ou de la communauté. Pour les participants, la liste de souhaits représente un investissement de temps coûteux avec un gain minime. Ils continuent de s'intéresser à la liste de souhaits parce qu'ils estiment que c'est le seul moyen d'attirer l'attention sur des bugs importants et des améliorations de fonctionnalités, ou de signaler le besoin d'opportunités stratégiques plus larges. Les souhaits sont souvent rédigés sous forme de solutions plutôt que de problèmes. Les solutions peuvent sembler raisonnables sur le papier, mais ne tiennent pas nécessairement compte de la complexité technique ou des implications en matière de stratégie de mouvement.
La portée et l'ampleur des souhaits dépassent parfois la portée et la capacité de l'équipe des technologies communautaires, ou d'une seule équipe, perpétuant la frustration, conduisant à des RFC et à des appels au démantèlement de la liste de souhaits. Au moment où les membres de la communauté préfèrent utiliser la liste de souhaits pour des idées de projets, les équipes de la Fondation examinent la liste de souhaits et d'autres processus de réception pour établir des priorités, en partie parce que les souhaits sont inopportuns pour la planification annuelle et sont difficiles à intégrer dans les feuilles de route/OKR. La liste de souhaits de l'avenir devrait être un pont entre la communauté et la Fondation, où les communautés apportent leur contribution de manière structurée, afin que nous puissions agir et, en retour, rendre les bénévoles heureux. Nous créons un nouveau processus d'admission permettant à tout bénévole connecté de soumettre un souhait, 365 jours par an. Les souhaits peuvent signaler ou mettre en évidence un bug, demander une amélioration ou imaginer une nouvelle fonctionnalité. N’importe qui peut commenter, organiser un atelier ou soutenir un souhait pour influencer la priorisation. La Fondation ne catégorisera pas les souhaits comme «trop grands» ou «trop petits». Les souhaits qui correspondent thématiquement à un problème plus large peuvent influencer la planification annuelle et les feuilles de route des équipes, offrant des orientations et des opportunités stratégiques. Les souhaits seront visibles pour le Mouvement dans un tableau de bord qui les classe par projet, produit/domaine à problème et type de souhait. La Fondation répondra aux souhaits en temps opportun et s'associera à la communauté pour les catégoriser et les hiérarchiser. Nous nous associerons aux Wikimédiens pour identifier et prioriser trois domaines d’amélioration, intégrés dans le plan annuel 2025-26 de la Fondation, qui devraient améliorer le taux d’adoption et la réalisation des souhaits avec impact. Nous signalerons les souhaits bien définis pour la communauté des développeurs bénévoles et les équipes de la Fondation, conduisant à un engagement accru des équipes et des développeurs et à davantage de souhaits exaucés, ce qui mènera à la satisfaction de la communauté. Répondre à davantage de souhaits améliore le bonheur, l'efficacité et la rétention des contributeurs, ce qui devrait générer davantage de modifications de qualité, un contenu de meilleure qualité et plus de lecteurs. |
Jack Wheeler |
| PES1.3 | Exécuter et conclure deux expériences à partir de produits/fonctionnalités exploratoires existants qui nous fournissent des données/informations sur la façon dont nous développons Wikipédia en tant que destination de connaissances pour nos publics actuels de consommateurs et de bénévoles au premier et au deuxième trimestre.
Compléter et partager les enseignements et les recommandations en vue d'une adoption potentielle pour les futurs travaux CRs dans la catégorie Wiki Experiences d'ici la fin du troisième trimestre (Q3). |
Ce travail est une contrepartie de l'objectif publics futurs, mais se concentre plutôt sur la découverte d'opportunités d'augmenter et d'approfondir l'engagement de nos audiences existantes (des consommateurs et des contributeurs de Wikipédia) en testant plus rapidement davantage d'idées de produits sur la plateforme.
Ce résultat fait partie de PES1 car il est énergisant et multiplicateur - canalisant le temps que les individus et les équipes ont déjà consacré au piratage/expérimentation sur des projets parallèles pour mettre en avant des fonctionnalités plus prometteuses. Au lieu que ces projets parallèles disparaissent (ce qui n'est pas une bonne utilisation de nos ressources limitées), ce RC fournit une voie pour que certaines de ces idées puissent potentiellement être intégrées dans un cadre APP plus large grâce à des expériences éprouvées, utilisant ainsi plus efficacement le temps du personnel et motivant leur créativité et productivité. En mettant en œuvre davantage de ces projets plus petits et plus courts, nous diversifions également notre éventail de «paris» pour plus d’apprentissages et d’essais d’idées susceptibles de transformer Wikipédia en fonction des besoins et des attentes changeants de nos publics actuels. Cela rendra notre travail plus efficace et plus rapide, car il aidera la fondation à s'aligner sur le bon objectif en moins de temps. |
Rita Ho |
| PES1.4 | Apprendre à: Définir, surveiller et prendre des décisions sur les SLOs. Choisir au moins une nouvelle chose pour définir les SLO au fur et à mesure que nous la publions. Collaborer avec la ou les équipes respectives (généralement: Produit, équipes de développement, SRE) pour définir ce SLO. Réfléchir et documenter les directives sur les versions qui devraient avoir des SLOs à l'avenir et sur la manière de les définir. | RC futur:
Mettre en place des processus et des outils rudimentaires pour définir et surveiller les SLOs pour les nouvelles versions. Rapporter sur une base trimestrielle et utiliser ce rapport pour prendre des décisions sur quand il faudra (ou pas) prioriser le travail pour résoudre quelque chose. Partager le rapport avec la communauté. POURQUOI: Nous ne savons pas quand nous devons prioriser le travail pour réparer quelque chose. Et nous avons beaucoup de code. Au fur et à mesure que cette empreinte continue de croître, il y aura de plus en plus de situations dans lesquelles nous devrons peut-être choisir entre résoudre les problèmes ou nous concentrer sur l'innovation, et davantage d'incertitudes quant au moment où nous devrions le faire. De plus, le personnel et la communauté ne savent pas clairement quel est notre niveau de support/engagement en matière de fiabilité et de performances pour toutes les différentes caractéristiques et fonctionnalités avec lesquelles ils interagissent. Si nous définissons un niveau de service attendu, nous pouvons savoir quand nous devrions y allouer des ressources ou pas. |
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. | tâche 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. | tâche 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 | |
Explication des paniers
Expériences Wiki
L'objectif de ce panier est de fournir, d'améliorer et d'innover efficacement en matière d'expériences wiki qui permettent la distribution de connaissances libres dans le monde entier. Ce module s'aligne sur les recommandations de la stratégie du mouvement #2 (Améliorer l'expérience utilisateur) et #3 (Assurer la sécurité et l'inclusion). Notre public comprend tous les collaborateurs de nos sites web, ainsi que les lecteurs et autres consommateurs de connaissances libres. Nous soutenons un site web mondial classé parmi les 10 premiers, ainsi que de nombreuses autres ressources importantes de la culture libre. Ces systèmes ont des exigences de performance et de disponibilité comparables à celles des plus grandes entreprises technologiques du monde. Nous fournissons des interfaces utilisateur pour les wikis, la traduction, des API pour les développeurs (et plus encore !) ainsi que des applications et des infrastructures de soutien qui forment toutes une plateforme robuste permettant aux bénévoles de collaborer à la production de connaissances libres dans le monde entier. Nos objectifs pour ce budget devraient nous permettre d'améliorer notre technologie de base et nos capacités, de nous assurer que nous améliorons continuellement l'expérience des éditeurs bénévoles et des modérateurs de nos projets, d'améliorer l'expérience de tous les contributeurs techniques qui travaillent à l'amélioration des wikis, et d'assurer une grande expérience pour les lecteurs et les consommateurs de connaissances libres dans le monde entier. Nous y parviendrons en travaillant sur les produits et les technologies, ainsi qu'en menant des activités de recherche et de marketing. Nous prévoyons d'avoir au maximum cinq objectifs dans ce domaine.
La connaissance est construite par les gens ! C'est pourquoi notre plan annuel se concentrera sur le contenu ainsi que sur les personnes qui contribuent au contenu et celles qui y accèdent et le lisent.
Notre objectif est de produire un plan d'exploitation basé sur la stratégie existante, principalement nos hypothèses sur le contributeur, consommateur et roue d'inertie du contenu. Le principal changement que je demande est de mettre l'accent sur la partie contenu de la roue d'inertie, et d'explorer ce que nos modérateurs et fonctionnaires pourraient avoir besoin de nous aujourd'hui, dans le but d'identifier les mesures de santé de la communauté à l'avenir.
Signaux et services de données
Afin de répondre aux Recommandations de la Stratégie du Mouvement pour assurer l'équité dans la prise de décision (Recommandation #4), améliorer l'expérience utilisateur (Recommandation #2), et évaluer, itérer et adapter (Recommandation #10), les décideurs de l'ensemble du Mouvement Wikimédia doivent avoir accès à des données, des modèles, des idées et des outils fiables, pertinents et opportuns qui peuvent les aider à évaluer l'impact (à la fois réalisé et potentiel) de leur travail et du travail de leurs communautés, leur permettant ainsi de prendre de meilleures décisions stratégiques.
Dans le domaine des signaux et des services de données, nous avons identifié quatre publics principaux : Le personnel de la Fondation Wikimedia, les affiliés et les groupes d'utilisateurs de Wikimedia, les développeurs qui réutilisent notre contenu, et les chercheurs de Wikimedia, et nous priorisons et répondons aux besoins de données et d'informations de ces publics. Notre travail couvrira une gamme d'activités : définir les lacunes, développer des métriques, construire des pipelines pour calculer les métriques, et développer des expériences d'exploration des données et des signaux et des chemins qui aident les décideurs à interagir plus efficacement et joyeusement avec les données et les connaissances.
Publics futurs
.svg)
L'objectif de ce module est d'explorer des stratégies pour s'étendre au-delà de nos audiences existantes de consommateurs et de contributeurs, dans un effort pour vraiment atteindre tout le monde dans le monde en tant qu'infrastructure essentielle de l'écosystème de la connaissance libre. Ce module s'aligne sur la Recommandation n°9 de la stratégie du mouvement (Innover dans le domaine de la connaissance libre). De plus en plus, les gens consomment l'information dans des expériences et sous des formes qui divergent de notre offre traditionnelle d'un site web avec des articles - les gens utilisent des assistants vocaux, passent du temps avec des vidéos, s'engagent avec l'IA, et plus encore. Dans ce panier, nous proposerons et testerons des hypothèses sur les futurs potentiels à long terme de l'écosystème de la connaissance libre et sur la manière dont nous en serons l'infrastructure essentielle. Pour ce faire, nous travaillerons sur les produits et les technologies, ainsi que sur la recherche, les partenariats et le marketing. Au fur et à mesure que nous identifierons des états futurs prometteurs, les enseignements tirés de ce volet influenceront et seront développés dans les paniers 1 et 2 des plans annuels successifs, en orientant nos offres de produits et de technologies vers ce qu'elles doivent être pour répondre aux besoins des chercheurs de connaissances de l'avenir. Nos objectifs dans ce domaine devraient nous inciter à expérimenter et à explorer pour concrétiser notre vision de l'avenir de la connaissance libre.
Sous-paniers
Nous avons également deux autres « sous-paniers » qui consistent en des domaines de fonctions critiques, qui doivent exister à la Fondation pour soutenir nos opérations de base, et dont certains sont communs avec n'importe quel organisme de logiciels. Ces « sous-paniers » n'auront pas d'objectifs de haut niveau propres, mais ils contribueront aux objectifs de haut niveau des autres groupes et les soutiendront. Il s'agit de :
- Fondations des infrastructures. Cet ensemble couvre les équipes qui soutiennent et font évoluer nos centres de données, nos plateformes de calcul et de stockage, les services pour les exploiter, les outils et processus qui permettent le fonctionnement de nos sites et services publics.
- Soutien aux produits et à l'ingénierie. Ce panier comprend les équipes qui opèrent « à l'échelle » en fournissant des services à d'autres équipes qui améliorent la productivité et les opérations d'autres équipes.