Jump to content

Jahresplan der Wikimedia Foundation/2024–2025/Product & Technology OKR

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs and the translation is 52% complete.
Outdated translations are marked like this.

This is part of the Wikimedia Foundation's Product and Technology departments drafting process for the 2024–25 Annual Plan.

This document represents the first part of the 2024-25 Annual Planning process for the Wikimedia Foundation's Product & Technology department. It describes on the departments' draft "objectives and key results" (OKRs). This is a continuation of the structure of work portfolios (called "buckets") that began last year.

Portrait of Selena

Im November habe ich mit euch allen darüber gesprochen, was in meinen Augen die wichtigste Frage für die Wikimedia-Bewegung ist: Wie stellen wir sicher, dass Wikipedia und alle Wikimedia-Projekte multigenerational sind? Ich möchte allen danken, die sich die Zeit genommen haben, eingehend über diese Frage nachzudenken und mir direkt zu antworten. Nachdem ich jetzt einige Zeit hatte, über eure Antworten nachzudenken, möchte ich teilen, was ich gelernt habe.

Zunächst gibt es keinen einzelnen Grund, warum Freiwillige etwas beitragen. Um viele Generationen an Freiwilligen anzuziehen, müssen wir die vielen Gründe besser verstehen, aus denen Menschen ihre Zeit unseren Projekten widmen. Dann müssen wir uns darauf konzentrieren, was uns von anderen abhebt: unsere Fähigkeit, vertrauenswürdige Inhalte anzubieten, während Desinformation und Falschinformationen sich im Internet und auf Plattformen ausbreiten und um die Aufmerksamkeit neuer Generationen werben. Dazu gehört, dass wir unsere Mission erfüllen, die Summe allen menschlichen Wissens zu sammeln und der Welt bereitzustellen, indem wir stärker darauf hinarbeiten, Informationslücken zu schließen, die durch Ungerechtigkeit, Diskriminierung oder Voreingenommenheit entstehen können. Unsere Inhalte müssen auch in einem sich verändernden Internet, das von Künstlicher Intelligenz und vielfältigen Erfahrungen geprägt ist, noch nützlich und wesentlich sein. Zuletzt müssen wir auch Wege finden, um unser Movement nachhaltig finanziell abzusichern, indem wir eine gemeinsame Strategie für unsere Produkte und Einkünfte entwickeln, sodass wir diese Arbeit langfristig finanzieren können.

Diese Ideen werden sich im Jahresplan 2024–2025 der Wikimedia Foundation widerspiegeln, dessen ersten Teil ich heute in Form der Zielsetzungsentwürfe für unsere Arbeit im Bereich Produkt und Technologie mit euch teile. Wie schon im vergangenen Jahr wird der gesamte Jahresplan sich auf die technischen Bedürfnisse unserer Zielgruppen und Plattformen konzentrieren und wir freuen uns über euer Feedback, um zu erfahren, ob wir uns auf die richtigen Probleme ausrichten. Diese Zielsetzungen basieren auf Ideen, die wir in den vergangenen Monaten von Communitymitgliedern im Rahmen von Gespräch: 2024, in Mailinglisten und auf Diskussionsseiten sowie bei Communityveranstaltungen über unsere Produkt-und-Technologie-Strategie für das kommende Jahr gehört haben. Ihr könnt weiter unten die komplette Liste der Zielsetzungsentwürfe ansehen.

Eine Zielsetzung ist eine Richtungsvorgabe auf hoher Ebene, die prägend für die Produkt- und Technologieprojekte für das kommende Geschäftsjahr sein wird. Zielsetzungen sind bewusst breit formuliert, stehen im Einklang mit der Richtung unserer Strategie und zeigen, welche Herausforderungen wir aus vielen möglichen Schwerpunktbereichen für das kommende Jahr priorisieren möchten. Wir geben sie jetzt bekannt, damit Communitymitglieder in einem frühen Stadium mitdenken können, bevor die Budgets und messbaren Zielvorgaben für das Jahr festgelegt werden.

Feedback

Ein Bereich, in dem wir uns besonders über Feedback freuen, ist unsere Arbeit, die wir zusammenfassend „Wiki-Erfahrungen“ nennen. Bei „Wiki-Erfahrungen“ geht es darum, wie wir auf effiziente Weise die direkte Nutzung unserer Wikis durch Beitragende, Lesende oder Spendende ermöglichen, verbessern und erneuern. Dazu zählt Arbeit an unseren zentralen Technologien und Fähigkeiten sowie die Verbesserung der Erfahrung freiwilliger Beitragender – insbesondere solcher mit erweiterten Rechten – durch bessere Funktionen und Werkzeuge, Übersetzungsangebote und Erneuerungen der Plattformen.

Hier einige Überlegungen aus unseren jüngsten Planungsdiskussionen und einige Fragen für euch alle, um uns dabei zu helfen, weiter an unseren Ideen zu feilen:

  1. Es sollte sich gut und lohnend anfühlen, freiwillig in Wikimedia-Projekten tätig zu sein. Wir denken auch, dass die Erfahrung der gemeinschaftlichen Onlinearbeit ein entscheidender Grund sein sollte, warum Freiwillige wiederkommen. Was ist nötig, damit Freiwillige das Beitragen lohnend finden und besser zusammenarbeiten können, um vertrauenswürdige Inhalte zu erstellen?
  2. Die Zuverlässigkeit unserer Inhalte ist Teil des einzigartigen Beitrags, den Wikimedia zu dieser Welt leistet, und der Grund, warum Menschen unsere Plattform und unsere Inhalte nutzen. Was können wir tun, um vertrauenswürdige Inhalte schneller zu erstellen, aber weiterhin die Qualitätsrichtlinien der Community in jedem Projekt zu befolgen?
  3. Um relevant zu bleiben und mit anderen großen Internetplattformen konkurrieren zu können, braucht Wikimedia eine neue Generation von Konsument:innen, die sich mit unseren Inhalten verbunden fühlt. Wie können wir es Lesenden und Spendenden erleichtern, unsere Inhalte zu entdecken und damit zu interagieren?
  4. In einer Zeit, in der Onlinegewalt sich ausbreitet, müssen wir gewährleisten, dass unsere Communitys, Plattformen und Systeme geschützt sind. Wir haben es auch mit fortwährend weiterentwickelten rechtlichen Bestimmungen zu tun, mit denen Gesetzgeber weltweit Datenschutz, Identität und Informationsaustausch im Internet prägen. Mit welchen Verbesserungen an unseren Mechanismen gegen Missbrauch können wir diese Herausforderungen bewältigen?
  5. MediaWiki, die Software-Plattform und Oberflächen, die Wikipedia antreiben, muss auch im nächsten Jahrzehnt weiterentwickelt werden, um in großem Stil die Erstellung, Verwaltung, Speicherung, Erschließung und den Konsum mehrsprachiger Inhalte zu ermöglichen. Welche Entscheidungen und Plattformverbesserungen können wir in diesem Jahr treffen bzw. durchführen, um sicherzustellen, dass MediaWiki zukunftsfähig ist?
Diskussion

–– Selena Deckelmann

Entwurf der Zielsetzungen

Aktuell veröffentlicht sind die Zielsetzungen der höchsten Planungsebene.

Die nächste Ebene – der Entwurf der Schlüsselergebnisse zu jeder finalen Zielsetzung – wird unterhalb beschrieben.

Die zugrundeliegenden Hypothesen zu jedem zentralen Ergebnis werden im Verlauf des Jahres auf den relevanten Projekt- und Team-Wikiseiten nach gemachten Erfahrungen aktualisiert.

Zielsetzungen zu Wiki Experiences (WE)
Zielsetzung Bereich der Zielsetzung Zielsetzung Kontext der Zielsetzung Zuständigkeit
WE1

Diskussion

Erfahrung der Beitragenden Sowohl erfahrene als auch neue Beitragende finden sich online zusammen, um gemeinsam eine vertrauenswürdige Enzyklopädie aufzubauen, einfacher und mit weniger Frustration. Damit Wikipedia in den kommenden Jahren lebendig bleibt, müssen wir daran arbeiten, mehrere Generationen von Freiwilligen anzuziehen und Beitragen für Menschen attraktiver zu machen. Verschiedene Generationen Freiwilliger benötigen unterschiedliche Investitionen – erfahrenere Beitragende brauchen Reparaturen und Modernisierungen ihrer mächtigen Werkzeuge, während neuere Beitragende neue Arten des Beitragens, die für sie sinnvoll sind, erwarten. Und generationenübergreifend benötigen alle Beitragenden die Möglichkeit, sich auszutauschen und zusammenzuarbeiten, um die größte Wirkung zu erzielen. Mit dieser Zielsetzung werden wir zentrale Arbeitsabläufe für erfahrene Beitragende verbessern, die Hürden für konstruktive Beiträge von Neulingen verringern und in Möglichkeiten investieren, wie Freiwillige untereinander auf der Grundlage gemeinsamer Interessen Kontakt aufnehmen können. Marshall Miller
WE2

Diskussion

Enzyklopädische Inhalte Communitys werden unterstützt, um effektiv Wissenslücken durch Werkzeuge und Unterstützungssysteme zu schließen, die einfacher zugänglich, anpassbar und verbesserbar sind, wodurch zunehmendes Wachstum vertrauenswürdiger enzyklopädischer Inhalte gewährleistet werden kann. Enzyklopädische Inhalte, vor allem auf Wikipedia, können durch fortwährenden Einsatz und ständige Innovation vermehrt und verbessert werden. Werkzeuge und Ressourcen (technischer und anderer Natur), die Beitragenden ja nach Bedarf zur Verfügung stehen, können zugänglicher und zuverlässiger gemacht werden. Diese Werkzeuge sollten durch die WMF besser unterstützt werden, durch kurzfristig erreichbare funktionale Verbesserungen. Angesichts neuer Trends rund um die KI-gestützte Erstellung von Inhalten werden wir auch die Rahmenbedingungen für größere Veränderungen untersuchen (etwa Wikifunctions), die bei Wachstum und Weiternutzung helfen können. Mechanismen, um inhaltliche Lücken zu finden, sollten besser auffindbar sein und für Planungen genutzt werden können. Ressourcen, die das Wachstum enzyklopädischer Inhalte unterstützen, auch in Schwesterprojekten, Projekte wie die Wikipedia Library und Kampagnen können noch besser in die Beitragsworkflows integriert werden. Gleichzeitig sollten Wachstumsmethoden gegen zunehmende Bedrohungen geschützt werden, sodass Vertrauen in den Prozess bestehen bleibt und die Grundsätze enzyklopädischer Inhalte, wie sie in Wikimedia-Projekten anerkannt sind, erhalten bleiben.

Zielpublikum: Autor:innen, Übersetzer:innen

Runa Bhattacharjee
WE3

Diskussion

Erfahrung der „Konsument:innen“ (Lesen und Medien) Eine neue Generation von Konsument:innen findet zu Wikipedia, einem Lieblingsort, um enzyklopädische Inhalte zu entdecken, mit diesen zu interagieren und eine bleibende Verbindung aufzubauen. Ziele:

Aktuelle und neue Generationen von Konsument:innen und Spendenden erhalten.

Die Relevanz für aktuelle und neue Generationen von Konsument:innen steigern, indem unsere Inhalte einfacher auffindbar und interaktiver werden.

Plattformübergreifend arbeiten, um unsere Erfahrungen und bestehende Inhalte anzupassen, sodass enzyklopädische Inhalte von einer neuen Generation von Konsument:innen und Spendenden entdeckt und gepflegt werden können.

Olga Vasileva
WE4

Diskussion

Vertrauen und Sicherheit Unsere Infrastruktur, unsere Werkzeuge und Prozesse verbessern, sodass wir gut ausgerüstet sind, um die Communitys, die Plattform und unsere Systeme vor verschiedenen Arten gezielten Missbrauchs zu schützen, während wir die Einhaltung der sich weiterentwickelnden rechtlichen Rahmenbedingungen sicherstellen. Einige Facetten unserer Möglichkeiten, Missbrauch zu bekämpfen, haben ein Upgrade nötig. Vandalismusbekämpfung auf der Basis von IPs ist weniger effektiv, viele Admin-Werkzeuge müssen in ihrer Effizienz verbessert werden und wir müssen eine einheitliche Strategie für die Bekämpfung massiven Missbrauchs entwickeln, wobei die diversen Signale und Schutzmechanismen (Captchas, Sperren usw.) im Zusammenspiel genutzt werden. Im Lauf dieses Jahres werden in diesem Bereich anfangen, bei den größten Problemen Fortschritte zu machen. Zusätzlich muss dieses Investment in den Schutz vor Missbrauch von einem Investment in die Erfassung und Verbesserung der Community-Gesundheit begleitet werden, wovon mehrere Aspekte Teil gesetzlicher Vorschriften sind. Suman Cherukuwada
WE5

Diskussion

Wissensplattform I (Entwicklung der Plattform) Die MediaWiki-Plattform und ihre Oberflächen weiterentwickeln, um den Kernbedürfnissen der Wikipedia besser zu entsprechen. MediaWiki wurde entwickelt, um die Erstellung, Moderation, Speicherung, Entdeckung und den Konsum offener, mehrsprachiger Inhalte in großem Umfang zu ermöglichen. In diesem zweiten Jahr der Wissensplattform werden wir einen genauen Blick auf das System werfen und anfangen, Verbesserungen der Plattform einzuleiten, um in den kommenden zehn Jahren die Kernbedürfnisse der Wikimedia-Projekte effektiv unterstützen zu können, angefangen bei Wikipedia. Dies beinhaltet, weiter an der Definition unserer Plattform für Wissensschaffung zu arbeiten, die Nachhaltigkeit der Plattform zu stärken, einen Fokus auf das System von Hooks und Extensions zu legen, um die Entwicklung von Funktionen klarer und effizienter zu machen, und weiter in Wissensvermittlung zu investieren sowie Menschen das Beitragen zu MediaWiki zu ermöglichen. Birgit Müller
WE6

Diskussion

Wissensplattform II (Dienste für Developer) Mitarbeitende im technischen Bereich und freiwillige Developer haben die Werkzeuge, die sie benötigen, um die Wikimedia-Projekte effektiv zu unterstützen. Wir werden weiter daran arbeiten, in der Wikimedia-Produktion die Arbeitsabläufe für Entwicklung, Tests und Aktivierung zu verbessern (und auszuweiten), und die Definition um Dienste für Tool-Developer erweitern. Wir beabsichtigen auch, unsere Fähigkeit zu verbessern, häufig gestellte Fragen im Bereich der Entwicklungsworkflows und Zielgruppen zu beantworten und relevante Daten zugänglich zu machen, um bessere Entscheidungsfindung zu ermöglichen. Teil dieser Arbeit ist es, Praktiken (oder deren Abwesenheit) zu betrachten, die aktuell unser Ökosystem vor Herausforderungen stellen. Birgit Müller

Zielsetzungen zu Signals and Data Services (SDS)
Zielsetzung Bereich der Zielsetzung Zielsetzung Kontext der Zielsetzung Zuständigkeit
SDS1

Diskussion

Shared insights Unsere Entscheidungen darüber, wie wir die Wikimedia-Mission und das Movement unterstützen, sind auf hochwertige Metriken und Erkenntnisse gestützt. Damit wir effektiv und effizient Technik entwickeln, Freiwillige unterstützen und für Gesetzgebung eintreten können, die den Zugang zu Wissen schützt und stärkt, müssen wir das Wikimedia-Ökosystem verstehen und uns darauf einigen, wie Erfolg aussieht. Das bedeutet, dass wir ein gemeinsames Set an verlässlichen, verständlichen und zeitnah verfügbaren Metriken benötigen. Es bedeutet auch, Forschung und Erkenntnisse heranzuziehen, die uns dabei helfen, das Warum und Wie hinter unseren Messungen zu verstehen. Kate Zimmerman
SDS2

Diskussion

Plattform zum Testen Produktmanager:innen können die Auswirkungen von Produktfunktionen schnell, einfach und sicher beurteilen. Um datenbasierte Entscheidungsfindung zur Entwicklung von Produktfunktionen zu ermöglichen und zu beschleunigen, brauchen Produktmanager:innen eine Plattform zum Experimentieren, auf der sie Funktionen ausarbeiten, bestimmte Zielgruppen von Usern auswählen und die Auswirkungen analysieren können. Die Zeit zwischen Aktivierung und Messung zu verkürzen, ist essenziell, da dies die gesamte Experimentierphase und letztlich die Innovation beschleunigt. Manuelle Aufgaben und maßgeschneiderte Messungen wurden als Hindernisse für die Beschleunigung identifiziert. Im idealen Szenario würden Produktmanager:innen vom Beginn des Experiments bis zu den Erkenntnissen keine oder kaum Beteiligung von technischem oder Analysepersonal benötigen. Tajh Taylor

Zielsetzung Future Audiences (FA; zukünftige Zielgruppen)
Zielsetzung Bereich der Zielsetzung Zielsetzung Kontext der Zielsetzung Zuständigkeit
FA1

Diskussion

Testhypothesen Empfehlungen für strategische Investments der Wikimedia Foundation abgeben – basierend auf Erkenntnissen aus Experimenten, in denen wir besser verstehen, wie Wissen online verbreitet und konsumiert wird –, die unserem Movement dabei helfen, neue Zielgruppen in einem sich verändernden Internet anzusprechen. Aufgrund ständiger Veränderungen im technischen Bereich und im Nutzerverhalten (etwa Bevorzugung der Informationsbeschaffung über soziale Apps, Popularität von Kurzvideo-„Edutainment“, Erfolg generativer KI) steht die Wikimedia-Bewegung vor Herausforderungen, um Lesende und Beitragende anzulocken und an uns zu binden. Diese Veränderungen bringen auch Chancen mit sich, neue Zielgruppen anzusprechen, indem Informationen auf neue Arten erstellt und angeboten werden. Allerdings haben wir als Movement kein klares, datengestütztes Bild von den Vor- und Nachteilen verschiedener möglicher Strategien, mit denen wir die Herausforderungen meistern oder neue Chance ergreifen könnten. Sollten wir zum Beispiel …
  • In umfangreiche neue Funktionen wie Chatbots oder Social Video für unsere Plattform investieren?
  • Das Wissen und die Beitragsmöglichkeiten von Wikimedia auf beliebte Plattformen von Drittparteien tragen?
  • Etwas anderes tun?

Um sicherzustellen, dass Wikimedia ein multigenerationales Projekt wird, werden wir Hypothesen testen, um vielversprechende Strategien besser zu verstehen und – der Wikimedia Foundation und der Wikimedia-Bewegung – zu empfehlen, um zukünftige Zielgruppen anzulocken und an uns zu binden.

Maryana Pinchuk

Zielsetzung Product and Engineering Support (PES)
Zielsetzung Bereich der Zielsetzung Zielsetzung Kontext der Zielsetzung Zuständigkeit
PES1

Diskussion

Effizienz des Betriebs Die Arbeit der Foundation schneller, günstiger und wirkungsvoller machen. Mitarbeitende leisten bei ihrer täglichen Arbeit viel, um unsere Betriebsabläufe schneller, günstiger und wirkungsvoller zu machen. Bei dieser Zielsetzung stehen besondere Initiativen zentral, die a) substantielle Fortschritte in Richtung schneller, günstiger oder wirkungsvoller machen; und b) koordinierte Anstrengungen unternehmen und formelle sowie informelle Praktiken bei der Foundation ändern. Grundsätzlich sind die zentralen Ergebnisse dieser Zielsetzung die schwierigsten und besten Verbesserungen, die wir in diesem Jahr an der betrieblichen Effizienz der Arbeit im Bereich Produkt und Technologie vornehmen können. Amanda Bittaker


Entwurf der Schlüsselergebnisse

Dies ist der Entwurf der Schlüsselergebnisse zu allen abgeschlossenen Zielsetzungen. Sie entsprechen je einer oben genannten Zielsetzung.

Die zugrundeliegenden Hypothesen zu jedem Schlüsselergebnis werden im Verlauf des Jahres auf den relevanten Projekt- oder Team-Wikiseiten nach gemachten Erfahrungen aktualisiert.

Schlüsselergebnisse zu Wiki Experiences (WE)

[ Zielsetzungen ]

Kürzel des Schlüsselergebnisses Text des Schlüsselergebnisses Kontext des Schlüsselergebnisses Zuständigkeit
WE1.1

Diskussion

Einen Workflow entwickeln oder verbessern, der Beitragenden mit gemeinsamen Interessen dabei hilft, sich miteinander zu vernetzen und gemeinsam beizutragen. Wir glauben, dass Community-Spaces und Interaktionen in den Wikis Menschen glücklicher und als Beitragende produktiver machen. Zudem helfen Community-Spaces dabei, Neulinge einzuführen und unterstützend zu betreuen, optimale Beitragsmethoden zu entwerfen und Wissenslücken zu besprechen. Doch die bestehenden Ressourcen, Werkzeuge und Spaces, die den persönlichen Austausch erlauben, sind suboptimal und entsprechen nicht mehr den Herausforderungen und Bedürfnissen der Mehrheit der heutigen Beitragenden. Gleichzeitig hat die Arbeit des Campaigns-Team gezeigt, dass viele Organisator:innen sehr gerne mit neuen Werkzeugen mit strukturierten Workflows experimentieren, die ihnen bei ihrer Communityarbeit helfen. Deshalb möchten wir uns darauf konzentrieren, ein Zugehörigkeitsgefühl bei den Beitragenden der Wikis anzuregen und zu fördern. Ilana Fried
WE1.2

Diskussion

Konstruktive Aktivierung: #% Steigerung im Vorjahresvergleich der Neulinge, die ≥1 konstruktive Bearbeitung(en) im Artikelnamensraum über ein Mobilgerät tätigen.

Die aktuelle Bearbeitungserfahrung der vollen Seite erfordert zu viel Kontext, Geduld und Ausprobieren, als dass viele Neulinge konstruktiv beitragen könnten. Um eine neue Generation Freiwilliger zu unterstützen, werden wir die Anzahl und Verfügbarkeit kleinerer, strukturierter und aufgabenspezifischer Bearbeitungsverfahren ausweiten (bspw. Edit Check und Structured Tasks).

Anmerkung: Die genaue Ausgangslage wird erst gegen Ende des vierten Quartals des laufenden Geschäftsjahrs ermittelt, wonach wir auch unsere Zielmetriken für das Schlüsselergebnis ermitteln können.

Peter Pelberg
WE1.3

Diskussion

Die Benutzerzufriedenheit mit vier Moderationsprodukten um X% steigern.

Beitragende mit erweiterten Rechten nutzen eine Vielzahl bestehender Funktionen, Erweiterungen, Werkzeuge und Skripte, um Moderationsaufgaben in Wikimedia-Projekten zu erfüllen. In diesem Jahr möchten wir uns darauf konzentrieren, diese Ausrüstung zu verbessern, statt Projekte zu beginnen, um neue Funktionen in diesem Bereich bereitzustellen. Wir möchten im Laufe des Jahres eine Reihe von Produkten bearbeiten und alle nachhaltig verbessern. Dabei hoffen wir, die Gesamterfahrung der Inhaltsmoderation zu verbessern. Wir werden X% abhängig von der gemessenen Ausgangslage für einige häufig genutzte Moderationswerkzeuge definieren, auf die wir mit diesen Tätigkeiten abzielen können. Die Community-Wunschliste wird ein wichtiger Einflussfaktor sein, um über die Prioritäten bei diesem Schlüsselergebnis zu entscheiden.

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

Diskussion

Zum Ende des zweiten Quartals Organisator:innen, Beitragende und Institutionen mit bestimmten Werkzeugen, Erkenntnissen und Organisationsansätzen unterstützen, die den Umfang qualitativer Inhalte in zentralen Themenbereichen [TBD] um X% vergrößern.

Bei diesem Schlüsselergebnis geht es um die Verbesserung der inhaltlichen Abdeckung bestimmter Themen, um bestehende Wissenslücken zu verkleinern. Wir haben festgestellt, dass Communitys von effektiven Werkzeugen im Zusammenspiel mit Kampagnen zur qualitativen Verbesserung der Inhalte in unseren Projekten profitieren. In diesem Jahr möchten wir uns auf die Verbesserung bestehender Werkzeuge und auf das Ausprobieren neuer Möglichkeiten, zentrale Themenbereiche mit Wissenslücken zu priorisieren, konzentrieren. Unser Ziel einer Steigerung um X% wird an bestehenden Praktiken der Inhaltserstellung mit qualitativem Fokus gemessen. Die Themenbereiche, auf die wir uns mit Communitys und Institutionen konzentrieren werden, werden im Lauf des nächsten Quartals festgelegt.

Our target X articles will be determined by looking at existing baselines of quality content creation. Also, the topic areas we’ll be focusing on with communities and institutions will be determined by next quarter.

Purity Waigi & Fiona Romeo
WE2.2

Diskussion

Zum Ende des zweiten Quartals zwei Empfehlungen (sozialer und technischer Art) zur Unterstützung der Sprachinitiierung für kleine Sprachcommunitys umsetzen und testen, mit einer Auswertung, um Feedback der Community zu analysieren. Es gibt ungefähr 300 Wikipedia-Sprachversionen. Dennoch gibt es noch viele weitere Sprachen, die von Millionen Menschen gesprochen werden, in denen es aber keine Wikipedia und kein Wiki gibt. Das hindert uns daran, unsere Vision zu realisieren: dass jeder einzelne Mensch frei an der Summe allen Wissens teilhaben kann. Im Wikimedia Incubator können mögliche Wikimedia-Projektwikis in neuen Sprachversionen angelegt, geschrieben und getestet werden und sich bewähren, um als Projekt von der Wikimedia Foundation betrieben werden zu können. Der Incubator wurde 2006 lanciert und ging davon aus, dass Benutzer:innen bereits Erfahrung mit dem Bearbeiten von Wikis haben. Dieses Problem wurde dadurch verschärft, dass der Prozess besonders von Personen getragen wird, die noch neu und unerfahren in unserem Movement sind. Während seither das Bearbeiten von Wikimedia-Wikis deutlich verbessert wurde, konnte der Incubator aufgrund von technischen Einschränkungen nicht entsprechend aktualisiert werden. Aktuell braucht es mehrere Wochen, um ein Wiki aus dem Incubator zu entlassen und nur ungefähr zwölf Wikis pro Jahr werden neu erstellt, was auf eine deutliche Hürde hindeutet.

Bestehende Untersuchungen und Materialien zeigen technische Herausforderungen in allen Phasen der Spracheinführung auf: beim Hinzufügen neuer Sprachen zum Incubator, bei komplexen Problemen in der Erstellung und Wartung von Inhalten und bei der Erstellung eines Wikis, wenn eine Sprache aus dem Incubator entlassen wurde.

Jede Phase verläuft langsam und manuell und ist komplex; der Verbesserungsbedarf ist groß. Wenn dieses Problem gelöst wird, wird das Erstellen von Wikis in neuen Sprachen schneller und einfacher und mehr Menschen erhalten die Möglichkeit, Wissen zu teilen. Verschiedene Stakeholder, bestehende Untersuchungen und Ressourcen haben Empfehlungen sowohl sozialer als auch technischer Natur aufgezeigt. Für dieses Schlüsselergebnis sollen zwei dieser Empfehlungen (sozial und technisch) getestet werden und das Feedback der Community ausgewertet werden.

Satdeep Gill & Mary Munyoki
WE2.3

Diskussion

Zum Ende des zweiten Quartals werden zwei neue Funktionen Beitragende anleiten, Quellen zu ergänzen, die den Projektrichtlinien entsprechen, und drei bis fünf Partner werden Quellen zu Lücken im Bereich Sprache und Geografie beigetragen haben. Um den Zugang zu qualitativ hochwertigen Quellen zu verbessern, die benötigt werden, um strategische inhaltliche Lücken zu schließen, werden wir:
  • Partnerschaften mit der Biodiversity Heritage Library, AfLIA und dem Lernnetzwerk Wikisource Loves Manuscripts eingehen
  • Die Anwerbung und Einbindung inhaltlicher Partner durch zugänglichere Metriken zur Weiternutzung unterstützen
  • Beitragende anleiten, Bilder und Belege zu ergänzen, die den Projektrichtlinien entsprechen, und die Glaubwürdigkeit von Inhalten verbessern, indem beispielsweise beim Hochladen/Einfügen mögliche Probleme aufgezeigt werden.
Fiona Romeo & Alexandra Ugolnikova
WE2.4

Diskussion

Zum Ende des zweiten Quartals Wikifunctions-Aufrufe in mindestens einer kleineren Wikipedia-Sprachversion aktivieren, um eine bessere Möglichkeit zu bieten, neue Inhalte in großem Umfang zu erstellen. Um unsere Wissenslücken effektiv zu verkleinern, müssen wir Workflows verbessern, die umfangreiches Wachstum inhaltlich hochwertiger Inhalte ermöglichen, besonders in kleineren Sprachcommunitys. Amy Tsay
WE3.1

Diskussion

Zwei gepflegte, zugängliche und von der Community betriebene Besuchs- und Lernerfahrungen in repräsentativen Wikis veröffentlichen, mit dem Ziel, die Bindungsrate der ausgeloggten Benutzer:innen mit dieser Erfahrung um 5 % zu steigern. Bei diesem Schlüsselergebnis geht es darum, die Bindungsrate einer neuer Generation von Lesenden an unsere Website zu erhöhen, sodass eine neue Generation eine nachhaltige Verbindung mit Wikipedia aufbauen kann, indem Möglichkeiten untersucht werden, es Lesenden einfacher zu machen, Inhalte, an denen sie interessiert sind, zu entdecken und daraus zu lernen. Dazu gehören Tests und Entwicklungen neuer betreuter, personalisierter und von der Community betriebener Besuchs- und Lernerfahrungen (beispielsweise Feeds mit relevanten Inhalten, themenbezogene Vorschläge von Inhalten, von der Community betreute Optionen zum Entdecken von Inhalten usw.).

Wir planen, das Geschäftsjahr mit einer Reihe von Experimenten zu Besuchserfahrungen zu beginnen, um festzustellen, welche davon wir umsetzen wollen und für welche Plattform (Web, Apps oder beide). Wir werden uns dann darauf konzentrieren, diese Experimente auszuweiten und ihre Effektivität dabei zu testen, die Bindungsrate in einer Liveumgebung zu erhöhen. Unser Ziel ist es, zum Jahresende mindestens zwei Experimente auf zwei repräsentativen Wikis freizuschalten und bei betroffenen Lesenden einen Anstieg der Bindungsrate um 5 % zu messen.

Um dieses Schlüsselergebnis am besten zu erreichen, müssen wir die Möglichkeiten von A/B-Tests mit nicht angemeldeten Benutzer:innen nutzen und brauchen die Werkzeuge, die Bindungsrate von Lesenden zu messen. Wir brauchen möglicherweise auch neue APIs oder Dienste, um Empfehlungen oder andere Mechanismen zur Inhaltsbetreuung nutzen zu können.

Olga Vasileva
WE3.2

Diskussion

Zunahme der Spendenanzahl über Berührungspunkte außerhalb der jährlichen Spendenkampagne über Banner und E-Mails um 50 % je Plattform. Unser Ziel ist es, vielfältige Einnahmequellen zu haben und unsere bestehenden Spendenden zu würdigen. Aufgrund von Feedback und der vorliegenden Daten liegt unser Fokus darauf, die Spendenanzahl über die in der Vergangenheit von der Foundation genutzten Methoden, insbesondere die jährliche Bannerkampagne, hinaus zu steigern. Wir wollen aufzeigen, dass wir durch Investitionen in eine umfassendere Spendenerfahrung unsere Arbeit stärken und unsere Wirkung ausweiten können, indem wir (potenziellen) Spendenden, die nicht auf Banner reagieren, eine Alternative bieten. Unsere erste Schätzung ist 50 % und basiert auf der geringeren Sichtbarkeit des Spendenbuttons in der Desktopversion aufgrund von Vector 2022 und auf dem Anstieg der Spenden durch das Pilotprojekt im Geschäftsjahr 2023–2024 mit den Wikipedia-Apps, um die Spendenerfahrungen zu verbessern (Anstieg der Spenden um 50,1 %). Indem wir diese Metriken plattformabhängig untersuchen, können wir die Plattformtrends besser verstehen und entscheiden, ob in Zukunft unterschiedliche Taktiken je nach Verhalten der Plattformzielgruppe Anwendung finden sollten. Jazmin Tanner
WE3.3

Diskussion

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
WE4.1

Diskussion

Bis zum dritten Quartal einen Vorschlag für drei Maßnahmen gegen Belästigung und schädliche Inhalte machen, der datenbasiert ist und den sich entwickelnden rechtlichen Rahmenbedingungen entspricht. Die Sicherheit und das Wohlbefinden der Benutzer:innen ist eine grundlegende Verpflichtung von Onlineplattformen. In vielen Rechtssystemen gelten Gesetze und Verordnungen, die Onlineplattformen dazu verpflichten, gegen Belästigung, Cybermobbing und andere schädliche Inhalte vorzugehen. Gegen diese Verpflichtungen zu verstoßen bedeutet für Plattformen, dass sie rechtlich verfolgt werden können und Sanktionen ausgesetzt sind.

Momentan wissen wir nicht genau, wie schwerwiegend diese Probleme oder die dahinterliegenden Gründe sind. Die Belege, die uns vorliegen, sind zumeist anekdotischer Natur und die manuellen Verfahren, auf die wir uns verlassen, bergen das Risiko rechtlicher und weiterer schwerwiegender Konsequenzen: Unterschätzung des Problems, Vergrößerung des Schadens, Rufschädigung und Verlust des Vertrauens unserer Benutzer:innen.

Wir müssen eine starke Kultur entwickeln, in der Belästigungen und schädliche Inhalte gemessen und proaktiv Gegenmaßnahmen ergriffen werden.

Madalina Ana
WE4.2

Diskussion

Bis zum dritten Quartal mindestens zwei Signale zur Nutzung in Workflows gegen Missbrauch entwickeln, um die Treffsicherheit von Maßnahmen gegen Akteure mit schlechten Absichten zu verbessern. Die Wikis sind stark von der Sperrung von IP-Adressen als Werkzeug zur Vandalismus-, Spam- und Missbrauchsbekämpfung abhängig. Aber IP-Adressen werden als stabile Identifikatoren einer einzelnen Person zunehmend nutzloser und die Sperrung von IP-Adressen hat unerwünschte Nebeneffekte auf Benutzer:innen mit guten Absichten, die sich nur zufällig mit böswilligen Akteuren eine IP-Adresse teilen. Durch die abnehmende Stabilität von IP-Adressen und unsere starke Abhängigkeit von IP-Sperren können solche Akteure immer ungenauer und weniger effektiv erwischt werden, während die Kollateralschäden für Benutzer:innen mit guten Absichten größer werden. Wir wollen aber das gegenteilige Ergebnis erreichen: Weniger Kollateralschäden und mehr Genauigkeit bei Schutzmechanismen gegen Akteure mit schlechten Absichten.

Um die Arbeit von Benutzer:innen mit erweiterten Rechten besser zu unterstützen und wiederverwendbare Bausteine für bestehende (bspw. CheckUser, Spezial:Sperren) und neue Werkzeuge anzubieten, schlagen wir in diesem Schlüsselergebnis vor, Möglichkeiten zu untersuchen, wie eine Person verlässlich mit ihren Handlungen verbunden werden kann (Umgang mit Sockenpuppen), und bestehende Signale (bspw. IP-Adressen, Account-Geschichte, Merkmale von Anfragen) zu kombinieren, um Handlungen böswilliger Akteure genauer zu erwischen.

Kosta Harlan
WE4.3

Diskussion

Die Effektivität eines umfangreichen verteilten Angriffs um 50 % reduzieren, gemessen an der Zeit, die wir benötigen, um Maßnahmen zu ergreifen, und dem Traffic, den wir in einer Simulation aushalten können. Die Weiterentwicklung der Internetlandschaft, einschließlich der Zunahme großer Bot-Netzwerke und häufiger Angriffe, haben unsere traditionellen Methoden gegen umfangreichen Missbrauch nutzlos gemacht. Derartige Angriffe können unsere Websites unzugänglich machen, indem sie unsere Infrastruktur mit Anfragen überfluten, oder die Kapazitäten unserer Community zur großflächigen Vandalismusbekämpfung überlasten. Damit werden zudem unsere Benutzer:innen mit erweiterten Rechten und unsere Tech-Community übermäßig belastet.

Wir müssen dringend unsere Fähigkeiten verbessern, solche Angriffe automatisch zu erkennen, abzuwehren und abzuschwächen oder zu beenden. Um unsere Verbesserungen zu messen, können wir uns nicht rein auf die Häufigkeit/Intensität tatsächlicher Angriffe stützen, da wir uns damit von Handlungen außerhalb unseres Einflussbereichs abhängig machen würden und es schwer wäre, ein klares, quantitativ messbares Bild unserer Fortschritte zu erhalten.

Indem wir in jedem Quartal mehrere simulierte Angriffe unterschiedlicher Art/Komplexität/Dauer in geschütztem Rahmen gegen unsere Infrastruktur starten, werden wir in der Lage sein, unsere neuen Gegenmaßnahmen zu testen, ohne tatsächlich angegriffen zu werden, und über unsere Verbesserung objektiv zu berichten.

Giuseppe Lavagetto
WE4.4

Diskussion

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

Diskussion

Zum dritten Quartal mindestens fünf Maßnahmen umsetzen, die die Nachhaltigkeit der Plattform erhöhen sollen. Die Nachhaltigkeit der MediaWiki-Plattform ist eine ständig aktuelle Anstrengung, die wichtig ist, um die Abnutzung der Zufriedenheit von Developern zu vermeiden und unsere Tech-Community zu vergrößern. Die Messung davon ist schwer und hängt von technischen und sozialen Faktoren ab. Aber wir wissen von einigen bestimmten Verbesserungsbereichen, die für Nachhaltigkeit von strategischer Bedeutung sind. Die geplanten Eingriffe können die Nachhaltigkeit und Wartbarkeit der Plattform verbessern oder ihre Verschlechterung verhindern. Wir planen, die Wirkung dieser Arbeit im vierten Quartal mit Empfehlungen zu Nachhaltigkeitszielen für die Zukunft zu beurteilen. Beispiele für Nachhaltigkeitseingriffe sind: Vereinfachung komplexer Code-Teile, die für MediaWiki zentral, aber nur für wenige Personen verständlich sind; vermehrte Nutzung von Werkzeugen zur Code-Analyse, um die Qualität unserer Codebasis zu erfassen; Verbesserung von Prozessen wie Packaging und Release. Mateus Santos
WE5.2

Diskussion

Bis zum zweiten Quartal einen oder mehrere Eingriffe zur Weiterentwicklung der Programmieroberflächen des MediaWiki-Ökosystems identifizieren und bis zum vierten Quartal umsetzen, um entkoppelte, vereinfachte und nachhaltigere Funktionsentwicklung zu fördern. Das Hauptziel des Schlüsselergebnisses 5.2 ist die Verbesserung und Verdeutlichung des Zusammenspiels der zentralen MediaWiki-Plattform und ihrer Erweiterungen, Skins und anderer Bestandteile. Wir beabsichtigen, die Architektur von MediaWiki funktional zu verbessern, um Modularität und Wartbarkeit zu ermöglichen, sodass Erweiterungen einfacher entwickelt werden können, und die Voraussetzungen der breiteren MediaWiki-Produktvision zu stärken. Diese Arbeit zielt auch darauf ab, festzustellen, was in der Kernsoftware, den Erweiterungen oder den Oberflächen vorhanden oder nicht vorhanden sein sollte. Das Jahr wird in zwei Phasen unterteilt: eine fünfmonatige Phase für Untersuchungen und Experimente und eine darauf aufbauende zweite Phase, in der die Eingriffe umgesetzt werden. [TBD]
WE5.3

Diskussion

Zum Ende des zweiten Quartals unsere Datensammlungsinitiative und ein Experiment zur Performance-Verbesserung abschließen, um anschließende Eingriffe in Produkt und Plattform zu ermöglichen, um die Möglichkeiten zu nutzen, die sich durch den MediaWiki-Seitenaufbau aus strukturierten Fragmenten ergeben. Das Hauptziel hier ist es, Developern und Produktmanager:innen die Werkzeuge in die Hand zu geben, neue Möglichkeiten der MediaWiki-Plattform zu erschließen, um aktuelle und zukünftige Anforderungen an enzyklopädische Inhalte zu erfüllen, indem neue Produktangebote ermöglicht werden, die momentan nur schwer genutzt werden können, und die Performance und Resilienz der Plattform verbessert werden.

Insbesondere wollen wir auf Plattformebene das MediaWiki-Verarbeitungsmodell ändern, sodass eine Seite nicht mehr als monolithische Einheit, sondern als Zusammenstellung von Einheiten strukturierter Inhalte behandelt wird. Auf Parsoid basierte Betrachtungen sowie Wikidata- und Wikifunctions-Integrierungen in Wikis sind implizite Schritte in diese Richtung. Als Teil dieses Schlüsselergebnisses wollen wir bewusster mit Daten experimentieren und diese sammeln, um zukünftige Eingriffe auf der Grundlage dieser neuen Möglichkeiten vorzubereiten, sodass sichergestellt ist, dass wir die beabsichtigte Wirkung in Infrastruktur und Produkt erzielen.

[TBD]
WE5.4

Diskussion

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

Diskussion

Fünf Fragen beantworten, um Effizienz und fundierte Entscheidungen zu Developer- sonstigen technischen Workflows und Diensten zu ermöglichen, und relevante Daten zum Ende des vierten Quartals veröffentlichen. „Es ist kompliziert“ ist eine häufige Antwort auf Fragen wie „Welche repositories werden produktiv in Wikimedia genutzt?“. In diesem Schlüsselergebnis werden wir einige unserer ständigen Themen im Bereich der technischen Produktivität und Erfahrung untersuchen – wiederkehrende Fragen, die vermeintlich einfach, aber tatsächlich schwer zu beantworten sind; Fragen, die wir beantworten können, wofür aber erst nicht allgemein zugängliche Daten durch Personen mit Spezialwissen abgerufen werden müssen; oder Fragen, deren Beantwortung aufgrund von Verfahrenslücken oder aus anderen Gründen mühsam ist. Wir werden definieren, was „beantworten“ einer jeden Frage bedeutet: Bei einigen kann es reichen, existierende Daten zugänglich zu machen. Andere Fragen werden weitere Nachforschungen und Bearbeitung erfordern. Das Gesamtziel dieser Arbeit ist die Reduzierung der Zeit, Übergangslösungen und Mühen, die für Einsichten in zentrale Aspekte der Developer-Erfahrung notwendig sind, und die Verbesserung der technischen Workflows und Dienste. [TBD]
WE6.2

Diskussion

Bis zum vierten Quartal ein bestehendes Projekt weiterentwickeln und mindestens zwei Experimente durchführen, die wartbare, zielorientierte Umgebungen bereitstellen sollen, was uns in Richtung sicherer, halbkontinuierlicher Umsetzung führt. Developer und Benutzer:innen sind vom Wikimedia-Beta-Cluster (Beta) abhängig, um Bugs zu entdecken, bevor sie Auswirkungen in der Liveumgebung haben. Mit der Zeit hat die Nutzung von Beta zugenommen und zu Konflikten geführt – die Nutzungsarten sind zu unterschiedlich, um in eine einzelne Umgebung zu passen. Wir werden eine existierende alternative Umgebung ausbauen und Experimente durchführen, um ein einzelnes Testbedürfnis hoher Priorität, das bis jetzt von Beta erfüllt wird, durch eine wartbare alternative Umgebung zu ersetzen, das besser den Ansprüchen der unterschiedlichen Anwendungsfälle entspricht. Tyler Cipriani
WE6.3

Diskussion

Bis zum zweiten Quartal ein Bewertungssystem über verschiedenste technische und soziale Faktoren für die Zukunftsfähigkeit der Toolforge-Plattform einführen. Bis zum vierten Quartal einen zentralen technischen Bestandteil um 50 % verbessern. Toolforge, die zentrale Wikimedia-Plattform für von Freiwilligen entwickelte Werkzeuge, spielt eine zentrale Rolle, sei es beim Bearbeiten oder bei der Vandalismusbekämpfung. Unser Ziel ist es, die Benutzerfreundlichkeit von Toolforge zu verbessern, die Hürden zum Beitragen zu verringern, die Community-Praktiken zu verbessern und die Einhaltung bestehender Regeln zu befördern. Zu diesem Zweck werden wir zum zweiten Quartal ein Bewertungssystem einführen, um die Zukunftsfähigkeit der Toolforge-Plattform zu beurteilen, mit einem Fokus auf technischen und sozialen Aspekten. Geleitet von diesem System möchten wir einen zentralen technischen Faktor um 50 % verbessern. Slavina Stefanova

Schlüsselergebnisse zu Signals and Data Services (SDS)

[ Zielsetzungen ]

Kürzel des Schlüsselergebnisses Text des Schlüsselergebnisses Kontext des Schlüsselergebnisses Zuständigkeit
SDS1.1

Diskussion

Leitende Personen aus zwei Programmen oder aus von Schlüsselergebnissen angeleiteten Initiativen haben weithin verbreitete Materialien erstellt, in denen die logische Verbindung zwischen der Arbeit und den Ergebnissen ihres Teams und einer oder mehrerer zentraler Metriken der Foundation aufgezeigt wird.

Unsere zentralen organisatorischen Metriken dienen als Grundlage, um den Fortschritt der Foundation in Richtung ihrer Ziele zu messen. Wenn wir Ressourcen auf Programme verteilen und an den Schlüsselergebnissen orientierte Arbeitsabläufe entwerfen, sollten diese Metriken uns anleiten, wie wir diese Investitionen mit den übergreifenden Zielen der Foundation aus dem Jahresplan zusammenbringen.

Bei der Arbeit an diesem Schlüsselergebnis wird davon ausgegangen, dass die Foundation insgesamt sich in einer frühen Phase ihrer Fähigkeit befindet, die Auswirkungen aller geplanten Eingriffe mit übergeordneten oder zentralen Metriken quantitativ zu verknüpfen. Um dieses Ziel zu erreichen, geht es bei diesem Schlüsselergebnis darum, den Prozess zu entwickeln, mit dem wir die logischen und theoretischen Verknüpfungen zwischen unseren Initiativen und unseren übergeordneten Metriken teilen. Praktisch bedeutet das, mit Initiativnehmer:innen überall in der Foundation zusammenzuarbeiten, um zu verstehen, wie die Ergebnisse ihrer Arbeit auf Projektebene mit den zentralen Metriken auf der Ebene der Foundation zusammenhängen und diese beeinflussen.

Rahmenmethoden für Impact-Mapping und Übungen wie die Umsetzung der Theory of Change und die Erstellung von Pfadmodellen werden verwendet, um Konsistenz und Genauigkeit bei der Dokumentation der möglichen Wirkung der Arbeit sicherzustellen. Um dieses Schlüsselergebnis erreichen zu können, werden wir auch unterstützende Materialien entwickeln müssen, die Initiativnehmer:innen dabei helfen, organisatorische Metriken zu verstehen und außerdem zu verstehen, wie sie „Theories of Change“ konstruieren können, die mit ihrer Arbeit in Zusammenhang stehen.

Omari Sefu
SDS1.2

Diskussion

Zwei strategische offene Forschungsfragen bis Dezember 2024 beantworten, um Empfehlungen abzugeben oder den Jahresplan für das Geschäftsjahr 2026 vorzubereiten. Es gibt zahlreiche offene Forschungsfragen im Wikimedia-Ökosystem und die Beantwortung einiger davon ist für WMF oder die Affiliates von strategischer Bedeutung. Die Antworten auf diese Fragen können zukünftige Produkt- oder Technikentwicklung beeinflussen oder Entscheidungsfindung im Policy-Bereich unterstützen. Einige dieser Fragen können durch reine Recherche oder Forschung beantwortet werden, doch angesichts der sozio-technischen Natur der Wikimedia-Projekte ist es für vertrauenswürdige Erkenntnisse oft notwendig, teamübergreifend zusammenzuarbeiten, um Daten zu sammeln, Kontext zu schaffen, mit Benutzer:innen zu interagieren, Experimente vorsichtig aufzubauen und mehr. Durch dieses Schlüsselergebnis wollen wir Teile unserer Forschungskapazitäten auf die Beantwortung einer oder mehrerer solcher Fragen ansetzen.

Die Arbeit an diesem Schlüsselergebnis beinhaltet die Priorisierung einer Liste offener Fragen und Experimentierarbeit, um X dieser Fragen (aktuelle Schätzung: zwei) zu beantworten. Ideal für dieses Schlüsselergebnis sind Fragen, deren Beantwortung es gleich mehreren Teams oder Gruppen erlaubt, besser in den Bereichen Produkt, Technologie oder Policy zu arbeiten. Wir planen, dass die Arbeit an diesem Schlüsselergebnis die folgenden Schlüsselergebnisse ergänzt:

  • PES1.3., das darauf abzielt, mit plattformbasierten Produkt- oder Funktionsideen zu experimentieren, die auf bestehenden Produkten aufbauen
  • FA1.1., das auf Experimente mit KI und Maschinenlernen im Bereich der zukünftigen Zielgruppen abzielt
Leila Zia
SDS1.3

Diskussion

Die durchschnittliche Zeit, die Stakeholder im Datenbereich benötigen, um Datenströme zu verstehen und zu erfassen, um mindestens 50 % in drei zentralen, essenziellen Metriken reduzieren. Notwendig für Data-Governance-Standards.

Die Umwandlung und Quelle von Datensets nachzuvollziehen, ist schwierig und erfordert Kenntnisse der verschiedenen repositories und Systeme. Wir sollten es einfacher machen, zu verstehen, wie Daten in unseren Systemen fließen, sodass Stakeholder eigenständiger damit arbeiten können.

Diese Arbeit wird Workflows dort unterstützen, wo Daten umgewandelt und für Analysetools, Funktionen, APIs und Datenqualität genutzt werden. In einem anschließenden Schlüsselergebnis werden Metriken dokumentiert.

Luke Bowmaker
SDS2.1

Diskussion

Zum Ende des zweiten Quartals ein Produktteam dabei unterstützen, eine Funktion oder ein Produkt durch einfache A/B-Test zu untersuchen, was seinen Zeitaufwand gegenüber Interaktionen mit Benutzer:innen um 50 % reduziert.

Wir glauben, dass die Nutzung gemeinsamer Werkzeuge das Vertrauen von Produktteams in datengeleitete Entscheidungsfindung stärken, Effizienz und Produktivität steigern und Produktstrategie und -innovation verbessern wird.

Wir werden den Zeitaufwand des betroffenen Teams anhand von Interaktionen mit Benutzer:innen messen und die Zeit um 50 % verbessern. Wir werden auch untersuchen, wie wir diese Verbesserungen in den Kontext aller Produktteams setzen können.

Wir erwarten, zu erfahren, wie wir auf der Grundlage von Feedback des betroffenen Teams und der Ergebnisse aus SDS2.2. die Erfahrung verbessern und Kapazitätssteigerungen identifizieren und priorisieren können.

Virginia Poundstone
SDS2.2

Diskussion

Zum Ende des zweiten Quartals werden wir zwei essenzielle Metriken für Analyse-Experimente (A/B-Tests) haben, um das Testen von Produkt-/Funktionshypothesen im Zusammenhang mit den Schlüsselergebnissen des Geschäftsjahrs 2024–2025 zu unterstützen. Wenn Produktmanager:innen (oder -designer:innen) eine Hypothese aufstellen, dass ein Produkt / eine Funktion für Benutzer:innen oder die Organisation ein Problem lösen oder ein Bedürfnis erfüllen kann, testen sie diese Hypothese mit einem Experiment, um die möglichen Auswirkungen ihrer Idee anhand einer Metrik analysieren können. Auf der Grundlage der Ergebnisse des Experiments können Produktmanager:innen leichter eine Entscheidung treffen, wie sie weiter vorgehen sollen (die Idee aufgeben und eine andere Hypothese testen, die Entwicklung weiter vorantreiben, wenn das Experiment in einem sehr frühen Stadium durchgeführt wurde, oder das Produkt / die Funktion für mehr Benutzer:innen bereitstellen). Produktmanager:innen müssen in der Lage sein, solche Entscheidungen mit Überzeugung treffen zu können, unterstützt von Belegen, denen sie vertrauen und die sie verstehen.

Ein großes Hindernis hierfür ist, dass Produktteams derzeit ihre Hypothesen mit projekteigenen Metriken formulieren, wodurch es spezieller Analysen bedarf, um sie zu definieren, zu analysieren und darüber zu berichten. Einige essenzielle Metriken für alle zu testenden Hypothesen zu Produkten und Funktionen zu verwenden, würde:

  • den Entwurf, die Umsetzung und die Analyse von Experimenten zum Testen dieser Hypothesen vereinfachen und beschleunigen;
  • die Kommunikation der Ergebnisse und Erfahrungen aus Experimenten an Entscheidungstragende (Produktmanager:innen) und andere Zielgruppen (bspw. höhere Leitungsfunktionen, andere Personen in der Organisation, Communitys) erleichtern.

Wir glauben, dass eine Zusammenstellung einiger essenzieller Metriken, die weithin verständlich sind und konsistent genutzt – sowie durch Industriestandards beeinflusst – werden, auch das Datenverständnis innerhalb der Organisation verbessern und eine Kultur der Überprüfung, des Experimentierens und des Lernens fördern würde. Wir konzentrieren uns auf essenzielle Metriken, die (1) für die bestmögliche Messung und Auswertung des Erfolgs / der Auswirkung von Produkten/Funktionen im Zusammenhang mit zwei Wiki-Experiences-Schlüsselergebnissen – WE3.1 und WE1.2 – benötigt werden und (2) die standardmäßig in Web-Analytics genutzten Metriken entsprechen.

Mikhail Popov
SDS2.3

Diskussion

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

Schlüsselergebnis zu Future Audiences (FA; zukünftige Zielgruppen)

[ Zielsetzungen ]

Kürzel des Schlüsselergebnisses Text des Schlüsselergebnisses Kontext des Schlüsselergebnisses Zuständigkeit
FA1.1

Diskussion

Als Ergebnis der experimentellen Erkenntnisse und Empfehlungen zu zukünftigen Zielgruppen ist zum Ende des dritten Quartals mindestens eine Zielsetzung oder ein Schlüsselergebnis aus der Zuständigkeit eines Teams außerhalb des Bereichs Future Audiences im Entwurf des Jahresplans für das folgende Geschäftsjahr vorhanden. Seit 2020 hat die Wikimedia Foundation externe Trends erfasst, die unsere Fähigkeit, zukünftige Generationen von Wissenskonsumierenden und -beitragenden anzusprechen und noch für viele kommende Generationen eine blühende Bewegung für freies Wissen zu sein, beeinflussen können. Future Audiences, ein kleines F+E-Team, wird:
  • Schnelle, zeitlich begrenzte Experimente durchführen (das Ziel sind mindestens drei Ergebnisse pro Geschäftsjahr), um Möglichkeiten zu erforschen, auf diese Trends zu reagieren
  • Auf der Grundlage der Experimente während unserer wiederkehrenden jährlichen Planungsphase Empfehlungen für neue, nicht experimentelle Investitionen abgeben, die WMF tätigen sollte – also neue Produkte oder Programme, die von einem ganzen Team oder mehreren Teams bearbeitet werden müssen. Dieses Schlüsselergebnis wird erreicht, wenn mindestens eine Zielsetzung oder ein Schlüsselergebnis in der Zuständigkeit eines Teams außerhalb von Future Audiences, die bzw. das von einer Empfehlung von Future Audiences angeregt wurde, im Entwurf des Jahresplans für das folgende Geschäftsjahr steht.
Maryana Pinchuk

Schlüsselergebnisse Product and Engineering Support (PES)

[ Zielsetzungen ]

Kürzel des Schlüsselergebnisses Text des Schlüsselergebnisses Kontext des Schlüsselergebnisses Zuständigkeit
PES1.1

Diskussion

Kultur der Überprüfung: Schrittweise die Einschätzung der Mitarbeitenden im Bereich Produkt und Technologie unserer Ergebnisse, unserer Ausrichtung, unserer Leitung und unserer Teamgesundheit in einer vierteljährlichen Umfrage verbessern. Eine Kultur der Überprüfung ist eine Produktentwicklungskultur, die auf kürzeren Zyklen von Tests, Lernen und Anpassung besteht. Das bedeutet, dass unsere Organisation jährliche Ziele vorgeben kann, unsere Arbeit zum Erreichen dieser Ziele sich aber im Lauf des Jahres ändert und an Lernerfahrungen anpasst. Eine Kultur der Überprüfung zu kreieren umfasst zwei Komponenten: Prozesse und Verhaltensweisen. In diesem Schlüsselergebnis geht es um letztere. Verhaltensänderungen können unsere Kultur der Überprüfung erweitern und stärken. Dazu zählen Änderungen in individuellen Gewohnheiten und Routinen, wenn wir uns mehr in Richtung iterativer Produktentwicklung bewegen. Dieses Schlüsselergebnis wird auf selbst gemeldeten Änderungen individueller Verhaltensweisen und Messungen etwaiger daraus resultierender Änderungen der Einschätzungen der Mitarbeitenden basieren. Amy Tsay
PES1.2

Diskussion

Zum Ende des zweiten Quartals verbindet die neue Wunschliste Ideen und Anfragen aus dem Movement besser mit Tätigkeiten der Foundation im Bereich Produkt und Technologie: angestaute Einträge aus der Wunschliste werden in einem Schlüsselergebnis 2024–2025 behandelt, die Foundation hat zehn kleinere Wünsche erfüllt und die Foundation hat gemeinsam mit Freiwilligen mehr als drei Bereiche identifiziert, in denen Chancen für das Geschäftsjahr 2025–2026 liegen. Die Community-Wunschliste spiegelt nur einen sehr kleinen Teil des Movements wider: Ungefähr 1000 Personen nehmen teil, von denen die meisten Beitragende oder Admins sind. Oft werden Wünsche direkt an der Wunschliste vorbei auf Phabricator als Feature-Request oder Bug-Report eingetragen, was es erschwert, Anfragen aus der Community von solchen der WMF zu unterscheiden. Für Teilnehmende ist die Wunschliste eine zeitaufwendige Investition mit geringen Ergebnissen. Sie nehmen teil, weil sie das Gefühl haben, dass die Wunschliste die einzige Möglichkeit ist, auf grobe Bugs und verbesserungswürdige Funktionen aufmerksam zu machen oder auf die Notwendigkeit größerer strategischer Chancen hinzuweisen. Wünsche werden oft als Lösungen formuliert, nicht als Probleme. Auch wenn die Lösung auf Papier sinnvoll erscheinen mag, berücksichtigt sie oft nicht ausreichend die technische Komplexität oder die Auswirkungen für die Movement-Strategie.

Der Umfang von Wünschen übersteigt manchmal den Aufgabenbereich und die Kapazität von Community Tech oder eines einzelnen Teams, was für Frustration sorgen und zu Meinungsbildern und Aufrufen zur Abschaffung der Wunschliste führen kann. Während Communitymitglieder es bevorzugen, die Wunschliste für Projektideen zu nutzen, schauen Teams bei der Foundation auf die Wunschliste und andere Feedbackprozesse als Werkzeuge zur Priorisierung, auch weil Wünsche zu einem ungünstigen Zeitpunkt in der Jahresplanung gesammelt werden und nur schwer in Aktionspläne und Zielsetzungen/Schlüsselergebnisse eingebaut werden können.

Die zukünftige Wunschliste sollte eine Brücke zwischen der Community und der Foundation schlagen, über die Communitys auf strukturierte Weise Feedback geben können, sodass wir aktiv werden und Freiwillige beglücken können. Wir bauen ein neues Feedbackverfahren, über das alle angemeldeten Benutzer:innen Wünsche einreichen können, an 365 Tagen im Jahr. Wünsche können eine Fehlermeldung, ein Verbesserungsvorschlag oder Ideen für eine neue Funktion sein. Alle können Kommentare abgeben, daran arbeiten oder einen Wunsch unterstützen, um die Priorisierung zu fördern. Die Foundation wird Wünsche nicht als „zu groß“ oder „zu klein“ kategorisieren.

Wünsche, die thematisch an ein größeres Problem anschließen, können die Jahresplanung und Aktionspläne für Teams beeinflussen und dadurch Chancen und strategische Anleitungen bieten. Wünsche werden für das Movement in einem Dashboard sichtbar sein, in dem Wünsche nach Projekt, Produkt-/Problembereich und Wunschart kategorisiert sind. Die Foundation wird Wünsche zeitnah bearbeiten und mit der Community zusammenarbeiten, um sie zu kategorisieren und zu priorisieren. Wir werden gemeinsam mit Wikimedianer:innen drei Verbesserungsbereiche identifizieren, die in den Jahresplan der Foundation 2025–2026 aufgenommen werden, mit denen die Bearbeitung und Erfüllung von Wünschen mit großer Wirkung verbessert werden sollte. Wir werden Wünsche geeigneten Umfangs der freiwilligen Developer-Community und den Teams der Foundation vorstellen, was zu mehr Beteiligung von Teams und Developern sowie zu mehr erfüllten Wünschen führt und damit mehr Zufriedenheit bei der Community mit sich bringt. Wenn mehr Wünsche bearbeitet werden, steigen Zufriedenheit, Effektivität und Bindung von Beitragenden, was zu mehr qualitativ hochwertigen Bearbeitungen, besseren Inhalten und einer größeren Leserschaft führen sollte.

Jack Wheeler
PES1.3

Diskussion

Zwei Experimente mit bestehenden Forschungsprodukten/-funktionen durchführen, um Daten/Erkenntnisse zu gewinnen, wie wir Wikipedia als Anlaufstelle für Wissen für unsere aktuellen Zielgruppen aus Konsument:innen und Freiwilligen in den ersten beiden Quartalen entwickeln können. Erkenntnisse und Empfehlungen darauf für mögliche Berücksichtigung in der zukünftigen Arbeit an Zielsetzungen und Schlüsselergebnissen im Bereich Wiki Experiences zum Ende des dritten Quartals weitergeben. Diese Arbeit ist das Gegenstück zur Zielsetzung der Future Audiences und konzentriert sich darauf, Möglichkeiten zu ermitteln, um die Einbindung unserer bestehenden Zielgruppen (Wikipedia-Konsument:innen und -Beitragende) durch geschicktere Test von Produktideen direkt auf der Plattform zu verstärken.

Es gehört zu PES1, da es mobilisiert und vervielfältigt – indem es die Zeit, die Personen und Teams bereits auf Hacken und Experimentieren an Nebenprojekten aufgewendet haben, kanalisiert, um vielversprechende Funktionen in den Fokus zu rücken. Statt diese Nebenprojekte dahindümpeln zu lassen (was keine gute Verwendung unserer begrenzten Ressourcen ist), skizziert dieses Schlüsselergebnis einen Pfad für einige dieser Ideen, durch nachgewiesene Experimente möglicherweise in eine breitere APP-Einstellung aufgenommen zu werden, womit die Zeit von Mitarbeitenden effizienter genutzt wird und ihre Kreativität und Produktivität angespornt wird.

Indem wir mehr von diesen kleineren, kürzeren Projekten zur Umsetzung begleiten, diversifizieren wir auch unsere Möglichkeiten, mit mehr Erkenntnissen und Tests neuer Ideen Wikipedia zu verändern und an die sich verändernden Bedürfnisse und Erwartungen aktueller Zielgruppen anzupassen. Das wird unsere Arbeit wirkungsvoller und schneller machen, da der Foundation dabei geholfen wird, sich kurzfristig an das richtige Ziel anzupassen.

Rita Ho
PES1.4

Diskussion

Lernen, wie Servicelevel-Ziele (SLO) gesetzt, überprüft und entschieden werden. Mindestens eine neue Sache auswählen, um SLOs bei der Veröffentlichung zu definieren. Mit den zugehörigen Teams zusammenarbeiten (meistens Produktteams, Entwicklungsteams und SRE), um das SLO zu definieren. Richtlinien darüber entwickeln und dokumentieren, welche Releases in Zukunft SLOs haben sollten und wie diese gesetzt werden. ZUKÜNFTIGES SCHLÜSSELERGEBNIS:

Einen Prozess und rudimentäre Werkzeuge bereitstellen, um für neue Releases SLOs setzen und überprüfen zu können. Vierteljährlich darüber berichten und darauf aufbauend Entscheidungen treffen, wann (und wann nicht) Arbeit priorisiert wird, um etwas zu reparieren. Den Bericht mit der Community teilen.

WARUM:

Wir wissen nicht, wann wir Arbeit priorisieren müssen, um etwas zu reparieren. Und wir haben jede Menge Code. Da diese Menge nur immer weiter zunimmt, werden Situationen häufiger, in denen wir uns zwischen dem Lösen von Problemen und dem Fokus auf Innovation entscheiden müssen und es unklar ist, wann. Es ist auch den Mitarbeitenden und der Community nicht klar, wie sehr wir die Zuverlässigkeit und Performance all der verschiedenen Funktionen, mit denen sie zu tun haben, unterstützen. Wenn wir ein erwartbares Servicelevel definieren, wissen wir, wann wir Ressourcen darauf verwenden sollten und wann nicht.

Mark Bergsma

Draft Hypotheses

The hypotheses below are the specific things we are doing this 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.

The first quarter (Q1) of the WMF annual plan covers July-September. Links for details and discussion for each hypothesis will be added as they are created.

Details for Q2, Q3, and Q4 will be added closer to their dates.

Wiki Experiences (WE) Hypotheses

[ Draft WE Key Results ]

Diskussion

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.
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.
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. phab:T368713
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.
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 Will be added in July
WE5.2.1
WE5.3.1
WE5.4.1
WE6.1.1 Will be added in July
WE6.2.1
WE6.3.1
Signals & Data Services (SDS) Hypotheses

[ Draft SDS Key Results ]

Diskussion

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

Meta Page

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

[ Draft FA Key Results ]

Diskussion

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

[ Draft PES Key Results ]

Diskussion

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.
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.
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.
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.


Explanation of buckets

Wiki Experiences

Diversity (40786) – The Noun Project
Diversity (40786) – The Noun Project

The purpose of this bucket is to efficiently deliver, improve and innovate on wiki experiences that enable the distribution of free knowledge world-wide. This bucket aligns with movement strategy recommendations #2 (Improve User Experience) and #3 (Provide for Safety and Inclusion). Our audiences include all collaborators on our websites, as well as the readers and other consumers of free knowledge. We support a top-10 global website, and many other important free culture resources. These systems have performance and uptime requirements on-par with the biggest tech companies in the world. We provide user interfaces to wikis, translation, developer APIs (and more!) and supporting applications and infrastructure that all form a robust platform for volunteers to collaborate to produce free knowledge world-wide. Our objectives for this bucket should enable us to improve our core technology and capabilities, ensure we continuously improve the experience of volunteer editors and moderators of our projects, improve the experience of all technical contributors working to improve or enhance the wiki experiences, and ensure a great experience for readers and consumers of free knowledge worldwide. We will do this through product and technology work, as well as through research and marketing. We expect to have at most five objectives for this bucket.

Knowledge is constructed by people! And as a result our annual plan will focus on the content as well as the people who contribute to the content and those who access and read it.

Our aim is to produce an operating plan based on existing strategy, mainly our hypotheses about the contributor, consumer and content "flywheel". The primary shift I’m asking for is an emphasis on the content portion of the flywheel, and exploration of what our moderators and functionaries might need from us now, with the aim of identifying community health metrics in the future.

Signals and Data Services

Arrythmia noun 246518
Arrythmia noun 246518

In order to meet the Movement Strategy Recommendations for Ensuring Equity in Decision Making (Recommendation #4), Improving User Experience (Recommendation #2), and Evaluating, Iterating and Adapting (Recommendation #10), decision makers from across the Wikimedia Movement must have access to reliable, relevant, and timely data, models, insights, and tools that can help them assess the impact (both realized and potential) of their work and the work of their communities, enabling them to make better strategic decisions.

In the Signals & Data Services bucket, we have identified four primary audiences: Wikimedia Foundation staff, Wikimedia affiliates and user groups, developers who reuse our content, and Wikimedia researchers, and we prioritize and address the data and insights needs of these audiences. Our work will span a range of activities: defining gaps, developing metrics, building pipelines for computing metrics, and developing data and signals exploration experiences and pathways that help decision makers interact more effectively and joyfully with the data and insights.

Future Audiences

The purpose of this bucket is to explore strategies for expanding beyond our existing audiences of consumers and contributors, in an effort to truly reach everyone in the world as the essential infrastructure of the ecosystem of free knowledge. This bucket aligns with Movement Strategy Recommendation #9 (Innovate in Free Knowledge). More and more, people are consuming information in experiences and forms that diverge from our traditional offering of a website with articles – people are using voice assistants, spending time with video, engaging with AI, and more. In this bucket, we will propose and test hypotheses around potential long-term futures for the free knowledge ecosystem and how we will be its essential infrastructure. We will do this through product and technology work, as well as through research, partnerships, and marketing. As we identify promising future states, learnings from this bucket will influence and be expanded through Buckets #1 and #2 in successive annual plans, nudging our product and technology offerings toward where they need to be to serve knowledge-seekers of the future. Our objectives for this bucket should drive us to experiment and explore as we bring a vision for the future of free knowledge into focus.

Sub-buckets

Noun project 3067
Noun project 3067

We also have two other “sub-buckets” which consist of areas of critical functions, which must exist at the Foundation to support our basic operations, and some of which we have in common with any software organization. These “sub-buckets” won’t have top level objectives of their own, but will have input on and will support the top level objectives of the other groups. They are:

  1. Infrastructure Foundations. This bucket covers the teams which sustain and evolve our datacenters, our compute and storage platforms, the services to operate them, the tools and processes that enable the operation of our public facing sites and services.
  2. Product and Engineering Support. This bucket includes teams which operate “at scale” providing services to other teams that improve the productivity and operations of other teams.