Jahresplan der Wikimedia Foundation/2025–2026/Produkt und Technologie, Ziele und Schlüsselergebnisse

Wikimedia Foundation
Jahresplan 2025-2026

Jahresplan der Wikimedia Foundation 2025–2026

• Zusammenfassung
• Globale Trends
• Fortschritte
• Ziele
  • Infrastruktur
  • Unterstützung der Freiwilligen
  • Effektivität
• Finanzmodell
• Haushaltsübersicht
• Zusammenarbeit

Das kommende Jahr

Auch wenn sich die Welt verändert, ist die Wikimedia Foundation immer noch sicher, dass wir unsere Mission – nützliche Informationen aus Wikimedia-Projekten dauerhaft kostenlos im Internet bereitzustellen – als multigenerationale Anstrengung verfolgen wollen: Wir wollen, dass freies Wissen auch in Zukunft für viele weitere Generationen verfügbar bleibt.

Das Internet verändert sich schnell. Neue Generationen erhalten Informationen durch Videos in sozialen Medien und KI-Erfahrungen, und im Vergleich zu älteren Generationen sind weniger von ihnen mit Wikipedia vertraut. Wir beobachten damit zusammenhängende Rückgänge in der Anzahl der Besuchenden unserer Websites und der Anzahl der Beitragenden. Gleichzeitig sind Plattformen im Internet von Wikimedia-Inhalten abhängig, um ihre KI- und Such-Angebote bereitstellen zu können. Diese Dynamik ist eine große Herausforderung, aber sie macht deutlich, warum das zuverlässige freie Wissen, das wir gemeinsam schaffen, so wichtig ist. Die Welt braucht mehr denn je eine Quelle vertrauenswürdigen, von Menschen überprüften Wissens, und Wikimedia-Projekte zeigen weiterhin, dass sie diese bieten können.

Um diesen Herausforderungen im kommenden Jahr gerecht zu werden, werden wir Möglichkeiten schaffen, um nachhaltig auf Wikimedia-Inhalte zuzugreifen, und wir werden Wikimedia-Inhalte in Online-Räume (soziale Medien) bringen, in denen neue Generationen ihre Zeit verbringen. Wir werden unsere eigenen Websites verbessern, damit Lesende wiederkommen, sich einbringen und auf eine Weise beitragen wollen, die ihnen am sinnvollsten erscheint. Und wir werden in unsere Fähigkeit investieren, schnell mit neuen Technologien zu experimentieren, damit unsere Entwicklungsgeschwindigkeit mit den Veränderungen in der Welt Schritt halten kann.

Das Infrastrukturziel dreht sich darum, wie die Plattform und Benutzungserfahrung den Umgang mit diesen Herausforderungen und das Erreichen einer Mehrheit der am Movement Beteiligten unterstützen werden. Es ist keine reine Liste von Projekten, sondern eine Reihe von Richtungsweisungen, um das Wachstum der Freiwilligen zu fördern, es den Freiwilligen zu ermöglichen, seriöse enzyklopädische Inhalte zu erstellen, unsere Mission zu finanzieren und unser Angebot so weiterzuentwickeln, dass es das sich verändernde Internet prägen kann. Du kannst mehr über diese vier strategischen Säulen erfahren.

Wachstum der Freiwilligen fördern

Die Freiwilligencommunity ist der einzigartige Antrieb hinter dem Erfolg der Wikimedia-Projekte, und wir brauchen sie, um gesund und wachstumsorientiert zu bleiben. Aber im vergangenen Jahr haben wir einen kontinuierlichen Rückgang der Anzahl neuer und wiederkehrender Beitragender in den Projekten gesehen. Um die Bedürfnisse unserer derzeitigen Freiwilligen besser zu verstehen und wirksamer darauf zu reagieren, hat die Foundation die Community-Wunschliste von einer einmal im Jahr durchgeführten Umfrage in einen dauerhaften Feedbackprozess umgewandelt, durch den Benutzerwünsche und Projektideen in die Arbeit mehrerer Teams der Foundation eingebunden werden können. Wir haben Wünsche in „Fokusbereiche“ gruppiert und drei dieser Fokusbereiche in die Schlüsselergebnisse des Jahresplans integriert. Wir haben auch ein Pilotprojekt für den Produkt- und Technologiebeirat begonnen, um die zahlreichen Gespräche, die die Teams der Foundation im Laufe des Jahres mit Communitymitgliedern in den und außerhalb der Wikis führen, zu ergänzen. Darüber hinaus haben wir Möglichkeiten erkannt, neue Generationen in unsere Projekte einzubeziehen, z. B. die Tatsache, dass junge Menschen sich eifrig in sozialen Räumen im Internet beteiligen, in denen sie einfache, für Mobilgeräte optimierte Möglichkeiten haben, sich über gemeinsame Interessenthemen auszutauschen.

Im kommenden Jahr werden wir das Wachstum der Freiwilligen vorantreiben, indem wir das Beitragen einfacher und attraktiver für neue Generationen machen, indem wir die Erfahrung für Mobilgeräte weiter priorisieren, neue Bearbeitungsmethoden („strukturierte Aufgaben“) erweitern und intelligente Arbeitsabläufe hinzufügen, die konstruktives mobiles Bearbeiten für Neulinge erleichtern („Edit-Checks“). Um die bestehenden Freiwilligen stärker einzubinden und beizubehalten, werden wir empfohlene Tätigkeiten und Aufgaben anbieten und sie an einem zentralen Ort sichtbar machen, der es einfach macht, Aktivitäten im Wiki zu organisieren. Wir werden mit Bedacht KI nutzen, um Freiwillige in ihrer Arbeit zu bestärken, wobei immer Menschen eingebunden bleiben und Transparenz gewahrt wird. Für neue und erfahrene Freiwillige werden wir Wege schaffen, um sich auf unseren Websites zu vernetzen und zusammenzuarbeiten – inspiriert von erfolgreichen Initiativen und WikiProjekten – sodass sie gleichgesinnte Beitragende finden und Inhalte verbessern können, die ihren Interessen entsprechen (in Verbindung mit diesem Fokusbereich der Wunschliste).

Seriöse enzyklopädische Inhalte anbieten

Da sich im Internet KI-generiertes Material weiter ausbreitet, braucht die Welt mehr denn je vertrauenswürdige enzyklopädische Inhalte. Wir möchten die Fähigkeiten der Freiwilligen verbessern, neue Inhalte zu erstellen, sicherzustellen, dass bestehende Inhalte vertrauenswürdig bleiben, und einer neuen Generation von Lesenden mit neuen Bedürfnissen und Vorlieben seriöse Inhalte anzubieten.

Um Freiwilligen bei der Erstellung neuer Inhalte zu helfen, werden wir auf bestehenden angeleiteten Werkzeugen und Arbeitsabläufen (wie dem Inhaltsübersetzungswerkzeug) aufbauen, damit große und kleine Communitys gleichermaßen zentrale Inhalte abdecken können. Um sicherzustellen, dass vorhandene Inhalte vertrauenswürdig bleiben, werden wir erfahrenen Freiwilligen helfen, besser mit ihren wachsenden Arbeitsbelastungen umzugehen, indem wir die Werkzeuge ausbauen, mit denen sie Aufgaben finden, die ihre Aufmerksamkeit benötigen – sodass es einfacher für sie wird, Artikel zu aktualisieren und nicht hilfreiche Bearbeitungen zurückzusetzen (im Sinne dieses Fokusbereichs der Wunschliste).

Wir helfen auch Funktionsträger:innen, unsere Inhalte zu schützen, indem wir neue Signale (neben IP-Adressen) bereitstellen, die böswillige Akteure identifizieren, sodass Benutzer:innen so gesperrt werden können, dass versehentliche Sperrungen gutgläubiger Beitragender minimiert werden.

Um enzyklopädische Inhalte einer neuen Generation anzubieten, werden wir Funktionen entwickeln, die neuen Gruppen von Lesenden helfen, Artikel leicht zu verstehen und die Informationen zu finden, die sie interessieren, sowie ihnen beim Lesen die Möglichkeit bieten, sich aktiv zu beteiligen. Diese Änderungen sollen neue Wikipedia-Lesende dazu anregen, regelmäßige Lesende und – einige von ihnen – Spendende zu werden (im Sinne dieses Fokusbereichs der Wunschliste).

Seriöse Inhalte zu liefern bedeutet auch, ein „Wissen als Dienstleistung“-Modell zu unterstützen, bei dem sich das gesamte Internet auf Wikimedia-Inhalte stützt. In diesem Modell ist unsere Infrastruktur nicht nur eine wertvolle Ressource für Menschen, die unsere Website besuchen, sondern auch für Suchmaschinen- und KI-Unternehmen, die automatisch auf unsere Inhalte zugreifen, die ihren Produkten zugrunde liegen. Diese Unternehmen sind nur einige der vielen Nutzungen, die unsere Infrastruktur zunehmend belasten und überlasten. Im vergangenen Jahr hat ein deutlicher Anstieg der Abrufe durch Scraper-Werkzeuge und Bots es für uns dringlicher gemacht, diesen Trend zu korrigieren. Wir müssen nachhaltige Kanäle schaffen, über die Entwickler:innen und Weiternutzende auf Wissensinhalte zugreifen können, sodass Menschen vor Bots priorisiert werden.

Die Zukunft des „Freien“ fördern

Die Abteilung für Produkt und Technologie spielt eine wichtige Rolle, um sicherzustellen, dass unser Movement nachhaltig ist. Im kommenden Jahr werden wir eng mit dem Team für Spendensammlung zusammenarbeiten, damit unsere Spendenden eine klarere und lohnendere Erfahrung haben. Auf unseren Websites und mobilen Apps werden wir Möglichkeiten für Lesende schaffen, ihre Wertschätzung für Wikipedia durch Spenden auszudrücken, und wir werden neue Möglichkeiten schaffen, wie sich Spendende wertgeschätzt fühlen, damit sie ihre Spenden jährlich wiederholen.

Ein sich veränderndes Internet gestalten

Um allen Menschen auf der Welt freies Wissen zu vermitteln, müssen wir sie dort abholen, wo sie sind, mit den Erfahrungen, die ihnen beim Lernen helfen. Menschen im Alter von 18 bis 24 Jahren haben ein geringeres Bewusstsein der Wikipedia und nutzen sie weniger als die Generationen vor ihnen. Sie lernen und interagieren weitgehend mit Videoplattformen, Online-Persönlichkeiten, denen sie vertrauen, sozialen Spiel-Umgebungen und zunehmend KI-Anwendungen. Dieses Jahr werden wir Wikipedia für diese Zielgruppen dort verfügbar machen, wo sie ihre Onlinezeit verbringen, damit sie Wikipedia als eine Quelle vertrauenswürdigen und von Menschen erstellten Wissens kennen. Wir werden unsere Präsenz auf beliebten Videoplattformen vergrößern, Wikipedia-Inhalte verbreiten und in diesen Bereichen eine Community schaffen. Und wir werden Ideen für die Verbreitung von Wikipedia-Wissen auf Spiele- und sozialen Plattformen nachgehen.

Im Bereich Infrastruktur umfasst dies drei Arbeitsportfolios (sogenannte „Buckets“): Wiki-Erlebnisse, Signale und Datendienste sowie zukünftige Zielgruppen. Diese Buckets sind die gleichen wie im vergangenen Jahr und im Jahr davor.

Zusammenfassend glauben wir, dass dieser Plan in einen entscheidenden Moment in der Geschichte des Internets fällt und uns darauf vorbereitet, sicherzustellen, dass freie Wissensinhalte weiterhin für alle Generationen zugänglich sind und von ihnen gestaltet werden. Unsere Zielsetzungen und Schlüsselergebnisse beschreiben die Struktur und den Inhalt dieses Plans detaillierter und wir freuen uns auf Fragen und Ideen aus der breiteren Community.

Die Infrastruktur für Wikimedia-Projekte und -Freiwillige aufbauen, verbessern und erhalten, ausgehend von unseren Werten

„Die Foundation wird nützliche Informationen aus ihren Projekten für immer kostenlos im Internet bereitstellen.“

Die Produkt- und Technologie-Teams priorisieren dauerhaft und ganzjährig den Aufbau, die Verbesserung und den Erhalt der Infrastruktur für die Wikimedia-Projekte. Wir investieren ins Hosting der Wikimedia-Projekte, in die Entwicklung von Open-Source-Software und -Designsystemen und in die Pflege und Verbesserung der Infrastruktur für Datenprodukte und KI-Modelle.

Ein Teil unserer wesentlichen Arbeit konzentriert sich auf die Grundlagen der Entwicklung und des Hostings einer großen, beliebten Website. Wir hosten unsere Wikimedia-Projekte in Rechenzentren sowie auf Servern und Hardware, die wir kaufen, installieren und warten, und die mit dem Rest des Internets über ein Hochgeschwindigkeitsnetzwerk verbunden sind. Wir überwachen und erhöhen wenn nötig die Kapazitäten und aktualisieren die technische Ausstattung, wenn sie veraltet. So planen wir beispielsweise in diesem Jahr, in unseren Rechenzentren in Ashburn (Virginia) und Carrollton (Texas) unsere Kapazitäten auszubauen und unsere Hardware zu aktualisieren.

Wir gestalten und entwickeln Open-Source-Software (insbesondere MediaWiki). Wir nutzen und implementieren auch viele bestehende Open-Source-Anwendungen, -Bibliotheken und -Frameworks von Drittanbietern. Wichtige Fehler in unserer Software werden priorisiert und behoben. Die Wartung von Open-Source-Software erfordert hochqualifizierte Arbeit von Personen mit besonderer Expertise in der Entwicklung von Open-Source-Software, mit Site-Reliability-Engineering (SRE), Produktmanagement, Programmmanagement, Design und vielem mehr. Unsere Mitarbeitenden arbeiten daran, sicherzustellen, dass unsere Software und unsere Systeme aktuell und einer sich ständig verändernden Umgebung angepasst sind. Dazu gehört auch die Modernisierung unseres Codes, um weiterhin von Sicherheitskorrekturen zu profitieren und gut mit neuer Software von Drittanbietern arbeiten zu können. Beispielsweise ist MediaWiki in PHP geschrieben und im vergangenen Jahr sind wir von PHP 7.4 auf 8.1 migriert, was Änderungen sowohl des Codes als auch der Infrastruktur, in der wir unsere Websites und Dienste betreiben, erforderte. Dieses Jahr werden wir auf diesen Arbeiten aufbauen und auf PHP 8.3 migrieren, indem wir die Lehren und Werkzeuge aus dem 8.1-Upgrade nutzen. Die Aktualisierung wird unsere Systeme schneller für Lesende, einfacher für Angestellte und Freiwillige und sicherer für alle machen. Außerdem wird es durch Sicherheits-, Leistungs- und Supportverbesserungen, die mit Sprachupdates einhergehen, zukünftige Entwicklungszeiten einsparen.

Um sicherzustellen, dass unsere Projekte und Inhalte für immer im Internet verfügbar bleiben, arbeiten unsere Teams ständig daran, eine hohe Verfügbarkeit unserer Websites und Dienste zu gewährleisten. Ein Aspekt dieser Arbeit ist die Notrettung nach katastrophalen oder bösartigen Ereignissen. Zum Beispiel stellen wir sicher, dass wir wichtige Daten in Backups sichern und daraus wiederherstellen können. Ebenso testen wir zweimal im Jahr unsere Fähigkeit, unsere Websitestandorte automatisch zwischen unseren Rechenzentren zu wechseln und alle Probleme zu beheben, die wir finden. Ein weiterer Aspekt dieser Arbeit konzentriert sich auf die Erkennung und Anpassung an die Trends in Art und Umfang des Traffics, den wir erhalten. Aufgrund der beispiellosen Zunahme von automatisierten Scrapern priorisieren wir beispielsweise Arbeit zur Sicherstellung, dass unsere Websites und Dienste für menschliche Benutzer:innen zugänglich bleiben, und verwenden einen systematischen Ansatz zur Festlegung von Regeln über die verantwortungsvolle Nutzung unserer Infrastruktur.

Nicht alle Arbeiten werden weit im Voraus geplant. Wir reagieren auch auf unerwartete Ereignisse und Vorfälle, wie Website-Ausfälle, Sicherheitsmeldungen oder -vorfälle oder groß angelegte Vandalismusangriffe auf unsere Projekte. Wir überwachen unsere Leistung und Zugangsbarrieren auf der ganzen Welt (einschließlich Internetverbindungsproblemen und Zensur) und untersuchen alle Anomalien, die wir finden. Einige dieser unerwarteten Ereignisse oder wiederholten Problemmustern führen dazu, dass Angestellte kurzfristige Projekte priorisieren, die darauf abzielen, weitere negative Auswirkungen einzudämmen oder vollständig zu verhindern. Solche Anstrengungen waren zum Beispiel entscheidend dabei, es unseren Wikimedia-Projekten zu ermöglichen, enormen globalen Anstiegen von Zugriffszahlen aufgrund bedeutender Nachrichtenereignisse (z. B. prominenter Todesfälle) durch eine Kombination aus Leistungsoptimierung, Neugestaltung der Architektur von Flaschenhalsbereichen und Kapazitätserhöhungen standzuhalten. Auch die jüngsten Verbesserungen der Benutzungsfreundlichkeit unserer Werkzeuge und Systeme zur Verwaltung unseres Traffics haben es uns ermöglicht, schneller und effektiver auf veränderliche Bedingungen zu reagieren. Diese Art von Anpassungsarbeit ist ein wesentlicher Bestandteil unserer Fähigkeit, auf neue Ereignisse – oft kurzfristig – zu reagieren und sicherzustellen, dass unsere Projekte und Inhalte verfügbar bleiben.

Zielsetzungen für Produkt und Technologie

Die hier aufgeführten Zielsetzungen sind noch im Entwurfsstadium und stehen für Rückmeldungen und Diskussion offen.

• Die Zielsetzungen sind eine Richtungsvorgabe auf hoher Ebene.
• Die „Schlüsselergebnisse“ sind eine messbare Möglichkeit, den Erfolg der zugehörigen Zielsetzung nachzuvollziehen.
• Die zu jedem Schlüsselergebnis gehörenden „Hypothesen“ beschreiben die eigentliche Arbeit, die wir leisten, um die zugehörigen Schlüsselergebnisse zu erreichen. Sie werden in diesem Dokument und auf den relevanten Wiki-Seiten der Projekte oder Teams aktualisiert werden, da das ganze Jahr über neue Erkenntnisse gewonnen werden.
• kennzeichnet Arbeit, die die Foundation auf der Grundlage der Community-Wunschliste priorisiert.

Wiki-Erfahrungen (WE)

Erfahrungen der Beitragenden (WE1)

• Zielsetzung: Beiträge nehmen zu, weil Freiwillige überzeugende Möglichkeiten erhalten und ihre Wirkung verstehen. Diskutieren
  • Kontext: Diese Zielsetzung wird die Grundlage für die Umsetzung der neuen Strategie für Beitragende mit ihren drei Säulen sein: 1) Freiwilligen eine zentrale Möglichkeit bieten, ihre Aktivitäten im Wiki zu organisieren, 2) kleinere, unauffällige Aufgaben erstellen, um mehr Klarheit zu schaffen und Freiwilligen zu helfen, ihr Potenzial auszuschöpfen, und 3) Beiträgen mehr Bedeutung geben. Im Geschäftsjahr 2025/26 planen wir, die grundlegende Infrastruktur zu schaffen, um Freiwillige dabei zu unterstützen, ihre Aktivitäten im Wiki zentral zu organisieren, beginnend mit Änderungen, die sich speziell auf erfahrene Beitragende und Moderator:innen konzentrieren. In den folgenden Jahren werden wir Änderungen bei allen Benutzerrollen vornehmen und mehr Problembereiche einbeziehen. Zusätzlich werden wir weiterhin in Edit-Check und strukturierte Aufgaben investieren, um eine Grundlage für die skalierbare Verwendung von KI zu schaffen, sowohl als Leitfaden während des Bearbeitungsvorgangs als auch, um Freiwillige auf nützliche Möglichkeiten hinzuweisen. Und schließlich werden wir in die bessere Sichtbarmachung der Wirkung der Freiwilligen investieren, um ihre Erfahrung zu verbessern.
    • Schlüsselergebnis WE1.1: Erhöhung der Frequenz konstruktiver Bearbeitungen über die Mobilversion [i] durch Benutzer:innen mit ≤100 kumulativen Bearbeitungen um 4 % [ii], gemessen an kontrollierten Experimenten (am Ende des zweiten Quartals).
      • i. „Konstruktive Bearbeitungen“ = Bearbeitungen von Seiten im Hauptnamensraum jeder Wikipedia, die nicht innerhalb von 48 Stunden nach dem Abspeichern wieder zurückgesetzt werden.
      • ii. T389403#10960480
      • Neue(re) Freiwillige tun sich schwer, erfolgreich mit dem Bearbeiten zu beginnen. Das gilt besonders für Menschen, die mobile Geräte verwenden, auf denen der Bildschirmraum begrenzt und die Aufmerksamkeit oft fragmentiert ist.
      • Manche ermüden der Kontext, die Geduld und das Ausprobieren, die erforderlich sind, um konstruktiv beizutragen. Andere haben noch keine überzeugende Gelegenheit gesehen, es zu versuchen.
      • WE 1.1 wird diese Probleme folgendermaßen angehen:
        • Anzeigen von Bearbeitungsvorschlägen
        • Anbieten von direkt umsetzbaren Anleitungen beim Bearbeiten
        • Schaffung von mehr aufgabenspezifischen Bearbeitungs-Workflows
      • Im Mittelpunkt dieser Bemühungen steht die Notwendigkeit skalierbarer Möglichkeiten, um zu erkennen, wie Bearbeitungen und bestehende Inhalte verbessert werden könnten. Um diese Kapazität zu vergrößern, werden wir weiterhin mit Maschinenlernen experimentieren, um zu erfahren, wie es Beitragenden am besten helfen kann, in verschiedenen Rollen und Erfahrungsniveaus.
      • Die vorgeschlagene Methodik zur Bewertung der Schlüsselergebnisse: Je Plattform werden wir den Anteil der von uns durch kontrollierte Experimente umgesetzten und ausgewerteten Eingriffe, die das Anfang dieses Jahres festgelegte Ziel für konstruktive Bearbeitungen erfüllt und/oder überschritten haben, berechnen. Siehe phab:T379285#10782051 für Gedanken dazu.
        • Anmerkung: Stand 30. Juni 2025 sind für WE 1.1 zwei kontrollierte Experimente geplant.

• Schlüsselergebnis WE1.2: Zunahme von Zusammenarbeit in den Wikis um 55 % im Jahresvergleich am Ende von Q4.
  • Beitragende tun sich oft schwer, Gelegenheiten zu finden, zusammenzuarbeiten, insbesondere bei den Themen und Aufgaben, die ihnen wichtig sind. Dies kann bei Neulingen zu einem Gefühl führen, in den Wikis ganz allein zu sein, und bei erfahrenen Beitragenden kann es zu einem Burnout führen. Darüber hinaus ist die Wirkung von kooperativen Tätigkeiten oft unklar, was dazu führen kann, dass weniger Menschen sich beteiligen, etwas organisieren oder Zusammenarbeit unterstützen möchten.
  • Wir wollen den Wert der Zusammenarbeit durch folgende Maßnahmen verdeutlichen:
    1. Erstellen neuer Möglichkeiten, um die Wirkung von Zusammenarbeit in den Wikis aufzuzeigen
    2. Beginnen, Daten über die Auswirkungen von Kooperationsaktivitäten im gesamten Movement zu sammeln
    3. Die Grundinfrastruktur zur Nachvollziehung kollaborativer Beiträge einrichten, damit wir in Zukunft innovative neue Möglichkeiten zur Anerkennung und Belohnung von Beiträgen bieten können
  • Die Zusammenarbeit wird anhand neuer Aktivitäten gemessen, die über die Veranstaltungsregistrierung in der CampaignEvents-Erweiterung erstellt werden. Ziel ist es, dass bis zum Abschluss dieses Schlüsselergebnisses mehr Nutzende der Werkzeuge dieser Erweiterung sowie neue Möglichkeiten zur Präsentation der Wirkung der Zusammenarbeit haben werden. Dies wird uns in die Lage versetzen, unsere bestehende Infrastruktur mit anderen Möglichkeiten zu verbinden, die Arbeit in den Wikis anzuerkennen und zu belohnen (wie dem Impact-Modul, der Danken-Funktion usw.).
  • Fokusbereich der Wunschliste: Community Wishlist/Focus areas/Connecting Contributors (Beitragende verbinden)
• Schlüsselergebnis WE1.3: Ende des dritten Quartals haben 10 % der Beitragenden, denen eine Startseite für neue Moderator:innen angeboten wurde, diese Seite zwei Wochen in Folge besucht.
  • Wir glauben, dass wir besser darin sein können, Freiwilligen Beitragsmöglichkeiten zu präsentieren. Langfristig glauben wir, dass eine Startseite für alle Beitragenden hilfreich sein kann, um ihre Arbeit zu organisieren, neue Möglichkeiten zu finden und ihre Auswirkungen zu verstehen. Unser Ziel im Geschäftsjahr 25/26 ist es, erfahrenen Beitragenden neue Möglichkeiten anzubieten, Moderationsarbeiten zu übernehmen, die sie sonst nicht unbedingt gefunden hätten.
    • Wir werden diese Theorie zuerst testen, indem wir herausfinden, wie sehr erfahrene Beitragende sich mit einer Startseite beschäftigen würden, die der Neulings-Startseite ähnelt.
    • Wir werden dann spezifische Moderationsaktivitäten (die Details sind noch offen) für Beitragende, die neu in diesem Bereich sind, anbieten, um die Belastung erfahrener Beitragender durch die Reduktion von Rückständen (unter einem neuen Schlüsselergebnis) zu verringern.
    • Wenn das Konzept der Startseite erfolgreich ist, planen wir, diese Seite modular zu machen, um den Bedürfnissen der Communitys gerecht zu werden. Diese Module könnten Dinge wie die bessere Darstellung der Auswirkungen von Beitragenden umfassen.
  • Hinweise zur Methodik:
    • Wir werden eine Hypothese haben, um unsere Zielgruppe zu definieren, die Teil von WE1.3.1 sein wird.
    • „Moderator:innen“ folgen der Definition aus Research:Develop a working definition for moderation activity and moderators, auch wenn weitere Arbeit nötig wäre, um die quantitative Definition weiter einzugrenzen.
    • Die zweite Woche wird im Hinblick auf den Zeitpunkt des ersten Besuchs der einzelnen Benutzer:innen festgelegt. In diesem Fall würden wir alle neuen Moderator:innen überprüfen, die die Startseite in einem bestimmten Zeitrahmen besucht und sie dann mindestens einmal (7 bis 14 Tage) später erneut besucht haben.
  • Fokusbereich der Wunschliste: Community Wishlist/Focus areas/Task prioritization (Aufgaben priorisieren)
• Schlüsselergebnis WE1.4: Verbesserung des Anteils einzelner Besucher:innen der Beobachtungsliste und/oder der letzten Änderungen, die klicken, um eine Bearbeitung anzusehen.
  • Unser Ziel ist es, Beitragenden mit mehr als 100 Bearbeitungen zu helfen, für sie interessante Bearbeitungen effizienter zu finden und zu öffnen. Wir werden den Schwerpunktbereich Aufgabenpriorisierung untersuchen, Wünsche in diesem Bereich erfüllen und weitere Rückmeldungen von Freiwilligen darüber einholen, wie diese Oberflächen verbessert werden können. Wir können den Erfolg messen, indem wir die Wirksamkeit jeder Seite bei der „Suche nach Arbeit“ verbessern, definiert durch den Indikator-Wert der Klickraten.
• Schlüsselergebnis WE1.5: Definition und Operationalisierung von sieben Metriken hoher Priorität [1] zur Nachverfolgung der Fortschritte bei der Erreichung der in der Strategie für Beitragende beschriebenen Ziele bis zum Ende von Q4, indem ein Dashboard erstellt und die Metriken zu monatlich aktiven Moderator:innen in Betrieb genommen werden.
  [1] Wiederkehrende Beitragende, konstruktive Aktivierung, konstruktive Bearbeitungen, Kontoregistrierungen bleibender Neulinge, aktive Beitragende nach Alter des Kontos, aktive Beitragende nach Erfahrungsniveau.
  • Die Strategie zur Erfahrung von Beitragenden sieht eine 3–5-jährige Anstrengung vor, um „das Wachstum der Freiwilligen zu fördern“ und „die Anbindung und Aktivierung“ neuer und bestehender Beitragender durch drei Hauptaktivitätsbereiche zu erhöhen:
  1. Verbesserung der Möglichkeiten, wie Freiwillige Empfehlungen erhalten können, ihre Aufgaben und Interessen verwalten können, sehen können, was auf den Wikis passiert, und ihre Auswirkungen verstehen können
  2. Angebot entsprechend strukturierter Aufgaben, um mehr Klarheit zu schaffen und Freiwilligen zu helfen, ihr Potenzial auszuschöpfen, indem wir die von uns vorbereiteten Workflows optimieren, einschließlich einer kontinuierlichen Investition in die Bereitstellung strukturierter Leitlinien und die Automatisierung repetitiver Aufgaben, mit besonderem Blick auf die Erfahrung in der Mobilversion
  3. Die Bedeutung der Beiträge erhöhen, indem Freiwilligen ihre Wirkung gezeigt wird und in Möglichkeiten für menschliche Verbindungen und ein Umfeld, das auf positiven Rückmeldungen basiert, investiert wird
  • Ein Messungsstrategieprojekt machte dann einen Entwurf für ein umfangreiches Netzwerk von Metriken zur Nachverfolgung dieser Theorie der Veränderung. Es kam zu dem Schluss, dass die primäre Erfolgsmaßnahme („Kern-Metrik“) eine Anzahl von wiederkehrenden Beitragenden sein sollte, ergänzt durch engere Indikatoren wie die konstruktive Aktivierung und die Absicht der Beitragenden, zurückzukommen, sowie breitere „Downstream“-Metriken wie aktive Beitragende und qualitativ hochwertige Inhalte. Wir müssen sicherstellen, dass diese Messwerte in einem Dashboard operationell und sichtbar sind, damit wir unseren Fortschritt bei der Umsetzung der Strategie nachverfolgen können.
• Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
  • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.

---

Zentrales Wissen (WE2)

• Zielsetzung: Mehr zentrales Wissen sprach- und themenübergreifend verfügbar machen und gut darstellen. Diskutieren
  • Kontext der Zielsetzung: Diese Zielsetzung wird Wachstum von Inhalten vorantreiben, das sowohl auf die Interessen der Beitragenden an bestimmten Themen und Sprachen als auch auf die Nachfrage der Lesenden nach gut dargestelltem zentralen Wissen reagiert. Zentrales Wissen ist eine Reihe von Artikeln, die die Breite und Tiefe der Themen liefern, die für ein nutzbares Wikipedia-Sprachprojekt erforderlich sind. Es wird von Communitys unter Bezugnahme auf Relevanz, erwartetes Lese-Interesse und Verbindungen zwischen Artikeln definiert.
  • Wir werden einen sozio-technischen Ansatz verfolgen, um die Effektivität von Funktionen, Werkzeugen und sozialen Prozessen zu verbessern. Wir werden auf wirkungsvollen Produktfunktionen wie vorgeschlagenen Aufgaben, Mediensuche und Inhaltsübersetzung aufbauen, aber auch die Einführung und Entwicklung kleiner Sprach-Wikipedias erleichtern. Wir werden die Wikimedia-Organisator:innen unterstützen, die Beitragende gewinnen, trainieren und unterstützen, um durch kollaborative Initiativen wie WikiProjekte und Kampagnen an gemeinsamen Inhaltszielen zu arbeiten. (Wir schätzen, dass mindestens 300 solcher Organisator:innen pro Quartal aktiv sind.) Wir werden auch Beziehungen zu den wichtigsten Verlagen pflegen, um den Zugang zu Quellmaterial zu erleichtern. (Wir haben derzeit Partnerschaften mit mehr als 100 der weltweit führenden abonnementbasierten Datenbanken.)
  • Um sicherzustellen, dass unsere Eingriffe einen positiven Einfluss auf das zentrale Wissen haben, werden wir sowohl die Zunahme von durch die Community priorisierten Inhalten als auch die Qualität dieser Inhalte messen, indem wir Faktoren wie Zurücksetzungsraten und die Anzahl der Belege und Bilder betrachten.
    • Schlüsselergebnis WE2.1: Experimentierung und Auswertung dreier Eingriffe, die Beitragenden helfen, den Zustand des zentralen Wissens in ihren Wikipedias zu verbessern, bis zum Ende von Q2.
      • Dieses Schlüsselergebnis wird innerhalb von Bearbeitungsmechanismen inhaltliche Lücken aufzeigen, wie das Auffinden von Bildern auf Wikipedia, die Inhaltsübersetzung und die geführte Erstellung neuer Artikel. Wir werden auch einen sozio-technischen Eingriff zur Unterstützung der Inhaltserstellung für kleine Sprachgemeinschaften vornehmen und testen. Der Erfolg wird für jede Hypothese gemessen.
    • Schlüsselergebnis WE2.2: Entwicklung der nötigen Plattformfunktionen, um zu bestätigen, dass wir die Vision der Abstract Wikipedia im großen Maßstab unterstützen können, bis zum Ende von Q4. Wir werden wissen, dass wir erfolgreich sind, wenn wir zeigen, dass das System reichhaltige, mehrsprachige enzyklopädische Inhalte mittels Wikidata und generierter natürlicher Sprache erstellt, von der Wikimedia-Community kontrolliert wird und auch bei umfangreichen Einführungen leistungsfähig bleibt.
      • Jetzt, wo wir Wikidata verwenden können, um grundlegende, einfache Textinhalte in Wikipedias zu erstellen, ist der nächste Schritt, Plattformfunktionen aufzubauen, die Abstract Wikipedia im großen Maßstab unterstützen können. Die Plattform muss reichhaltige, mehrsprachige Inhalte unterstützen, die von der Community kontrolliert werden können und im großen Maßstab leistungsfähig bleiben. Das ist ein Meilenstein-Schlüsselergbnis, da wir hier von 0 auf 1 gehen.
    • Schlüsselergebnis WE2.3: Einführung einer ersten Version des neuen Wikis zur frühen Community-Erstellung „abstrakter“ Artikel, bis zum Ende von Q4.
      • Dieses Schlüsselergebnis gibt vor, die Plattform-Fähigkeiten eines Abstract Wikis nächstes Jahr zu testen. Das neue, eigenständige Wiki wird die Bibliothek von abstrakten Artikeln, die über Wikifunctions erstellt wurden, beinhalten und die notwendigen Plattformfunktionen zur Verfügung stellen, um später abstrakte Artikel in Wikipedia zu integrieren.
    • Schlüsselergebnis WE2.4: Erreichung einer übereinstimmenden Definition zwischen WMF und WMDE von Erfolg bei den Verbesserungen der technischen Infrastruktur, die einen kritischen Wikidata-Anwendungsfall bis zum Ende von Q2 unterstützen, mit Matriken und Zielen im Geschäftsjahr 25–26.
      • Das WMF-Wikidata-Plattform-Team (WDP) wurde im August 2025 gegründet und mit einem Product Lead und einem Tech Lead besetzt. Als neue Ergänzung eines Programms mit Jahren der Entwicklung durch technische und Produktverantwortliche bei WMF bzw. WMDE spiegelt dieses Ziel unserer Absicht wider, die Verantwortung durch Abstimmung über Anwendungsfälle, Abhängigkeiten und wichtige Erfolgskriterien zu übertragen. Dieses Schlüsselergebnis wird die Grundlage für ein gegenseitiges Verständnis des Problemraums schaffen, auf der wir den Rest des Geschäftsjahres (Mai 2026) aufbauen werden.
    • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
      • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

---

Erfahrungen der Konsumierenden (WE3)

• Zielsetzung: Lesende aus mehreren Generationen befassen sich mit Wikipedia und bleiben dabei, was zu messbaren Steigerungen in der langfristigen Anbindung von Lesenden und Spendenaktivitäten führt. Diskutieren
  • Kontext der Zielsetzung: Diese Zielsetzung konzentriert sich auf die langfristige Anbindung neuer Lesender durch innovative Inhaltsformate und des Kernpublikums durch die Verbesserung vertrauter Leseerlebnisse sowie auf die langfristige Sicherstellung der Nachhaltigkeit durch die Vertiefung der Verbindung der Lesenden und die Diversifizierung von Spenden. Dazu gehört die Fortsetzung unserer Arbeit, Inhalte durch neue und experimentellere Funktionen wie KI-Zusammenfassungen oder „personalisierte Kaninchenlöcher“ leichter auffindbar zu machen. Auch Arbeit, um die Qualität der Lese-Erfahrung im weiteren Verlauf zu erhalten und zu verbessern und um organsiertes Lesen durch Leselisten und andere Beteiligungsmöglichkeiten (abseits des Bearbeitens) zu erforschen, gehören dazu. Für Spendende wird sich diese Arbeit weiterhin auf die Diversifizierung der Einnahmequellen innerhalb der Plattform konzentrieren.
    • Schlüsselergebnis WE3.1: Nachweis eines praktisch signifikanten Anstiegs der langfristigen Anbindung nicht angemeldeter Lesender, gemessen mit A/B-Tests einer Funktion pro Plattform, bis zum Ende von Q2
      • Dieses Schlüsselergebnis wird sich darauf konzentrieren, weiterhin in Erfahrungen zu investieren, die neue Wege des Konsumierens und des Lernens von Inhalten optimieren, oft durch den Einsatz neuer Technologien und Formate, wobei bestehende Inhalte auf neue und ansprechende Weise präsentiert werden. In diesem Geschäftsjahr möchten wir weiterhin mit neuen Funktionen experimentieren und uns gleichzeitig auf die Ausweitung erfolgreicher Experimente auf alle Wikis und Plattformen konzentrieren. Die Arbeit am Schlüsselergebnis wird sich auf die mobile und Desktop-Website sowie die iOS- und Android-Apps erstrecken und sich auf das Auffinden von Inhalten (Einstiegspunkte und Empfehlungen) und anpassungsfähige Lernformate (maschinengestützte Zusammenfassungen, Inhaltsremixe) konzentrieren.
      • Schwerpunktbereich der Wunschliste: Neue Erfahrungen für Konsumierende
    • Schlüsselergebnis WE3.2: Erhöhung der Anzahl der Spenden über E-Mail oder andere, nicht bannerbasierte Methoden um 5 % im Jahresvergleich pro Plattform, durch Eingriffe in Produkte, die engere Verbindungen pflegen und Reibungsmomente reduzieren, bis zum Ende von Q2
      • Für dieses Schlüsselergebnis werden wir weiterhin neue Einstiegspunkte für Spenden und andere Möglichkeiten, um Lesende in Spendende zu verwandeln und sie durch Vertiefung ihrer Verbindungen zu den Wikis langfristig anzubinden, auch dank mehr personalisierter Inhalte, erforschen. Das Schlüsselergebnis wird sich in Zusammenarbeit mit dem Fundraising-Team auf die Einführung neuer Einstiegspunkte und die Ausweitung bestehender Einstiegspunkte auf Apps und Web konzentrieren.
    • Schlüsselergebnis WE3.3: Nachweis eines praktisch signifikanten Anstiegs der langfristigen Anbindung angemeldeter Lesender, gemessen mit A/B-Tests einer Funktion pro Plattform, bis zum Ende von Q2
      • Dieses Schlüsselergebnis wird sich auf die Verbesserung der Lese- und Lernerfahrung für bestehende und erfahrene Lesende konzentrieren, mit dem Ziel, unser aktuelles Publikum beizubehalten und seine Verbindung zur Website zu vertiefen, um mehr zu lernen und offener für Spenden und Bearbeitungen zu werden. Die Arbeit wird sich auf die Verbesserung der Lese-Erfahrung im Web und in den Apps konzentrieren (Verbesserungen der Lesbarkeit, bessere Navigation und Auffindbarkeit) sowie auf die Ausarbeitung und Wiederholung unserer Angebote für Organisation und Personalisierung (Leselisten, personalisierte Vorschläge, Benutzer- und Artikelverlauf usw.).
    • Schlüsselergebnis WE3.4: Beseitigung aller gefundenen Hürden für die Veröffentlichung von Websites mit kleinformatigem Cache (PoPs), die unseren aktuellen Qualitäts- und Sicherheitsstandards gemäß unserer derzeit aktiven Website-Caches entsprechen, bis zum Ende von Q4
      • Dieses Schlüsselergebnis wird sich darauf konzentrieren, das Konzept zu untermauern, dass wir die Leistung der Websites verbessern und die Latenz für unsere Lesenden reduzieren können, indem wir unsere Caching-Infrastruktur vereinfachen und die Prozesse für die Bereitstellung einer Caching-Website verbessern, indem wir die grundlegende Aktivierungszeit von durchschnittlich etwa einem Jahr auf höchstens ein Quartal reduzieren. Der Schwerpunkt liegt hier auf der Vervollständigung der Vereinfachung, der Bereitstellung eines PoC, der Durchführung einer Sicherheitsprüfung und der Erstellung einer Entscheidungshilfe darüber, ob wir weiterhin unsere Edge-Caches in öffentlichen Clouds bereitstellen sollen. Die Verringerung der Latenz kann zu einer nachgewiesenen Zunahme der Seitenaufrufe und einer geografisch vielfältigeren Leserschaft führen.
    • Schlüsselergebnis WE3.5: Verbesserung der Identifizierung von Spendenden bis zum Ende von Q4, sodass alle angemeldeten Lesenden, die dem zugestimmt haben, eine gemäß Spendenstatus personalisierte Erfahrung erhalten.
      • Wir werden Identifizierungsstrategien für Spendende umsetzen, um sicherzustellen, dass alle, angemeldeten Lesenden, die dem zugestimmt haben, nach ihrem Spendenstatus identifiziert werden können, was eine maßgeschneiderte und ansprechendere Erfahrung ermöglicht. Die Arbeit zur Identifizierung von Spendenden werden in Q4 priorisiert, um künftig effektivere Personalisierungs- und Aktivierungsinitiativen zu unterstützen.
    • Schlüsselergebnis WE3.6: Finalisierung, Veröffentlichung und Kommunikation einer Strategie für die plattformübergreifende Erfahrung von Wikipedia-Lesenden und -Konsumierenden bis zum Ende von Q4, mit definierten Zielen und grundlegenden Metriken, entwickelt in Zusammenarbeit mit Interessensvertreter:innen und der Community, um unsere Arbeit bis 2030 anzuleiten.
      • Die Arbeit an der Konsumierendenstrategie wird weitergeführt, mit einem Schwerpunkt auf der Entwicklung und Kommunikation der Strategie, sowohl intern als auch mit der Community, und mit der Bestimmung zentraler Metriken für Konsumierende und zugehöriger Grundlagen.
    • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q3.
      • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
    • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
      • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
    • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
      • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
    • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
      • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

---

Schutz und Sicherheit (WE4)

• Zielsetzung: Unsere Systeme schützen die Konten und privaten Informationen unserer Beitragenden standardmäßig besser und bieten Beitragenden und Benutzer:innen mit erweiterten Rechten mehr Möglichkeiten, missbräuchliche Aktivitäten zu verhindern und darauf zu reagieren. Diskutieren
• Schlüsselergebnis WE4.1: Bereitstellung eines praktikablen und funktionierenden Systems zum Melden von Zwischenfällen in all unseren Wikis, das von den Communitys genutzt und akzeptiert wird, bis zum Ende von Q2.
  • Die Sicherheit und das Wohlbefinden der Benutzer:innen zu gewährleisten, ist eine grundlegende Verpflichtung unserer Plattform. In vielen Rechtssystemen gelten Vorschriften, die Onlineplattformen dazu verpflichten, gegen Belästigung, Cybermobbing und andere schädliche Inhalte auf der Plattform vorzugehen. Diesen Verpflichtungen nicht nachzukommen, bedeutet für Plattformen, dass sie rechtlich verfolgt werden können und Sanktionen ausgesetzt sind.
  • Wir möchten unseren Benutzer:innen die Möglichkeit geben, unmittelbare Bedrohungen durch ein leicht auffindbares und intuitives Meldeverfahren zu melden, um sicherzustellen, dass wir über solche Vorfälle erfahren und bei Bedarf schnelle Maßnahmen ergreifen können. Diesen Schritt setzen wir, damit sich unsere Benutzer:innen beim Beitragen zu unserer Plattform sicher fühlen. Wir werden dies durch die Einführung eines Meldesystems für Zwischenfälle in unseren Wiki umsetzen.
• Schlüsselergebnis WE4.2: Stärkung der Präzision und Effektivität der Anti-Missbrauchs-Werkzeuge, durch die Umsetzung zweier Verbesserungen bis zum Ende von Q2.
  • Wir und unsere Community müssen unechte und bösartige Aktivitäten in den Wikis besser erkennen und verhindern. Wir werden dies tun, indem wir die Anzahl und Qualität der Signale erhöhen, die der Plattform zur Verfügung stehen, diese Signale in Werkzeugen zusammenführen, die wir für Benutzer:innen mit erweiterten Rechten zur Verfügung stellen, und feststellen, an welchen Stellen wir unbesorgt automatisierte Beschränkungen in Reaktion auf verdächtige Aktivitäten vornehmen können.
  • Wir sehen auch Möglichkeiten, gleichzeitig die Zugänglichkeit von Wikipedia und unseren anderen Projekten zu verbessern. Zum Beispiel soll eines der Projekte das sehr konventionelle selbstverwaltete CAPTCHA der Wikis, das Benutzer:innen davon abhält, sich anzumelden, wenn sie die gestellte Aufgabe nicht lösen, durch einen Risikobewertungsdienst ersetzen, der Benutzer:innen nur selten testet. Stattdessen soll der Dienst Konten mit einem bestimmten Verdachtsgrad im Hintergrund entsprechend markieren, wodurch wir Funktionalitäten deaktivieren können, und diese Markierung besonders berechtigten Moderator:innen anzeigen, um bei ihrer Arbeit zu helfen.
  • Ganz allgemein sind die Wikimedia-Projekte stark auf Sperren von IP-Adressen angewiesen, um Missbrauch durch böswillige Akteur:innen zu bekämpfen. Dies ist zunehmend wirkungslos darin, Missbrauch zu stoppen, und hat negative Auswirkungen auf gutgläubige Benutzer:innen, die von IP- und IP-Range-Sperren betroffen sind. In diesem Schlüsselergebnis wollen wir bestehende Möglichkeiten verbessern und neue Werkzeuge bereitstellen, die eine präzisere und wirksamere Sperrung böswilliger Akteur:innen ermöglichen und Kollateralschäden durch IP- und IP-Range-Sperren verringern.
  • Um unsere Wirksamkeit zu messen, werden wir auf qualitative Rückmeldungen von Freiwilligen, die aktiv Missbrauch bekämpfen, und quantitative Indikatoren wie die Rate der eingesetzten IP-Sperren, die Annahme von Minderungen aufgrund von IP-Reputation und browserbasierten Signalen, die Rate wahrscheinlich menschlicher Interaktionen, wenn Benutzer:innen blockiert werden, und die Annahme neuer Signale in den Anti-Missbrauchs-Werkzeugen blicken.
  • Die Arbeit an diesem Schlüsselergebnis beinhaltet verbesserte Erkennung und Eindämmung von Sockenpuppen und Sperrumgehungen, Einsicht in Informationen über das Potenzial für Kollateralschäden, Stärkung der Bot-Erkennung, Weitergabe von Signalen an Anti-Missbrauchs-Aktive, verbesserte Effizienz in den Oberflächen der Anti-Missbrauchs-Werkzeuge, Verbesserung von Metriken im Zusammenhang mit Missbrauch und Vorschläge von Aktivitäten verdächtiger Konten zur Untersuchung durch CheckUser.
• Schlüsselergebnis WE4.3: Verringerung der Anzahl von großflächigen Angriffen, die menschliche SRE-Eingriffe erforderlich machen, um 50 % im Vergleich Geschäftsjahr zu Geschäftsjahr, bis zum Ende von Q4.
  • 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ähigkeit verbessern, solche Angriffe automatisch zu erkennen, ihnen standzuhalten und sie einzudämmen oder zu stoppen.
  • In diesem Jahr werden wir uns vor allem auf die automatisierte Erkennung von IP-Adressen und Netzwerken konzentrieren, die regelmäßig Angriffe gegen uns durchführen, und die Belastung, der diese anhaltend schädlichen Akteure unsere Systeme aussetzen dürfen, reduzieren.
• Schlüsselergebnis WE4.4: Bereitstellung der temporären Konten in 100 % unserer Projekte bis zum Ende von Q2, sodass persönliche Daten unserer nicht angemeldeten Beitragenden nur noch weniger als 0,1 % der Benutzer:innen zugänglich sind.
  • Die temporären Konten zielen darauf ab, die Privatsphäre und damit die Sicherheit unserer nicht angemeldeten Beitragenden zu verbessern, indem sie deren persönliche Daten (IP-Adressen) vor der Öffentlichkeit abschirmen und den Zugang auf diejenigen beschränken, die ihn für Kontrollzwecke benötigen. Neben der wesentlichen Verbesserung der Sicherheit der Benutzer:innen ist dieses Projekt auch wichtig, um verschiedenen regulatorischen Anforderungen zu entsprechen.
• Schlüsselergebnis WE4.5: Beurteilung des Einflusses generativer KI auf Vertrauen und Sicherheit und Bestimmung von Produktlösungen zur Nutzung von Chancen und zur Eindämmung von Bedrohungen für Wikimedia-Projekte, bis zum Ende von Q3.
  • Die Nutzung von KI und insbesondere generativer KI nimmt im Internet rasant zu. Es gibt Chancen und Bedrohungen hinsichtlich Vertrauen und Sicherheit, die durch KI allgegenwärtig werden. Zum Beispiel ist die Erstellung von Inhalten einfacher und billiger, aber die Moderation ist aufwändiger. Ebenso können Recherchen mit viel weniger Aufwand durchgeführt werden, aber KI-Halluzinationen sind schwerer zu entdecken.
  • Dieses Projekt soll auf der Untersuchung der Auswirkungen von Maschinenlernen/KI auf Menschenrechte aufbauen, indem die Auswirkungen von KI auf die Vertrauens- und Sicherheitsaspekte des Ökosystems von Wikimedia geprüft werden. Dazu gehören:
    • Austausch mit Benutzer:innen mit erweiterten Rechten.
    • Finden von Beispielen für durch generative KI unterstützten Missbrauch und Möglichkeiten zur Eindämmung.
    • Finden von Chancen durch maschinelles Lernen, um die Belastung der Benutzer:innen mit erweiterten Rechten zu verringern.
    • Durchführung von Experimenten, um zu verstehen, worauf wir unseren Fokus legen sollten, sodass wir die größte Wirkung erzielen können.
• Schlüsselergebnis WE4.6: Umsetzung einer technischen Lösung, um zu erzwingen, dass 100 % der sicherheits- oder datenschutzsensiblen Maßnahmen, die Benutzer:innen ergreifen können, bis zum Ende von Q4 nur noch von Konten durchgeführt werden können, die Zwei-Faktor-Authentifizierung aktiviert haben.
  • Wir müssen die Sicherheit der Benutzerkonten in unseren Wikis erhöhen, insbesondere für Benutzer:innen mit sensiblen Berechtigungen. Ein Schwerpunkt liegt darin, dass jegliche sensible Maßnahme nur noch von Benutzer:innen ergriffen werden kann, die die Zwei-Faktor-Authentifizierung (2FA) aktiviert haben. Wir werden ein umfassenderes System für die Umsetzung von erweiterten Rechten einrichten, das die Notwendigkeit von Kontrollen und manuellen Aktivierungen von 2FA umgehen kann, und den Kreis der Benutzerrollen erweitern, die die Aktivierung von 2FA erfordern.
  • Als Teil davon werden wir unsere Authentifizierungs- und Wiederherstellungssysteme verbessern, damit wir (WMF) und unsere Benutzer:innen eine strengere 2FA-Durchsetzung leichter unterstützen können. Wir werden die allgemeine Verfügbarkeit von Zwei-Faktor-Authentifizierung auf der gesamten Plattform erweitern, damit jede:r Benutzer:in sie nach Belieben aktivieren kann, und um sicherzustellen, dass sie aktiviert wird, bevor sensible Rechte gewährt werden. Wir werden uns auch darauf konzentrieren, die Arbeitsbelastung unserer Kontowiederherstellungs- und -unterstützungssysteme zu reduzieren und dabei zu helfen, unsere Zurücksetzungs- und Wiederherstellungsverfahren rund um die Konto-Anmeldung zu optimieren. Wir wollen die Benutzungsfreundlichkeit unserer 2FA-Implementierung weiter verbessern und Benutzer:innen mehr Möglichkeiten bieten, ihre Konten zu sichern und ungewolltes Aussperren zu vermeiden.

---

Verantwortungsvolle Nutzung der Infrastruktur (WE5)

• Zielsetzung: Entwickler:innen und Weiternutzer:innen greifen über vorgesehene Kanäle auf Wissensinhalte zu, wodurch die Nachhaltigkeit unserer Infrastruktur und verantwortungsvolle Weiternutzung der Inhalte gewährleistet werden. Diskutieren
  • Kontext der Zielsetzung: Diese Zielsetzung konzentriert sich auf die Schaffung von Kanälen für verantwortungsvolle Weiternutzung von Inhalten.
  • Wikimedia stellt die größte Sammlung von durch Menschen gepflegtem Wissen im Web bereit. Das hat unsere Wissensinfrastruktur nicht nur für Menschen, sondern auch für automatische Datennutzer zu einem wertvollen Ausgangspunkt gemacht. Unsere Inhalte werden in Suchmaschinen, sozialen Medien und Internetshops eingebettet und seit dem Aufstieg von KI werden sie zum Trainieren großer Maschinenlernen-Modelle verwendet. Konsumierende greifen auf Daten durch das Scrapen von Seiten, die Verwendung von APIs und das Herunterladen von Inhalten zu - in der Regel ohne Namensnennung. In einer Welt nicht authentifizierter Zugriffe können wir einzelne Nutzer:innen nicht zuverlässig von anderen unterscheiden, was unsere Fähigkeit, die verantwortungsvolle Nutzung unserer Infrastruktur zu ermöglichen und durchzusetzen, stark einschränkt. Wie können wir weiterhin unsere Community fördern und gleichzeitig der automatischen Inhaltsnutzung Grenzen setzen? Wie können wir die Nutzung in bevorzugte, unterstützte Kanäle lenken? Welche Anleitung brauchen wir, um Anreize für die verantwortungsvolle Wiederverwendung von Inhalten zu schaffen? Wie können wir eine kohärente Erfahrung für Entwickler:innen erreichen und Produkte entwickeln, die den Bedürfnissen der freiwilligen Entwickler:innen, Angestellten und Weiternutzer:innen gleichermaßen gerecht werden? Auch wenn diese Fragen nicht alle neu sind, ist die Dringlichkeit, sie zu beantworten, exponentiell gestiegen: Seit 2024 beobachten wir einen dramatischen Anstieg des Anfragevolumens, wobei der Großteil davon aus Scraping durch Bots herrührt, die Trainingsdaten für KI-betriebene Workflows und Produkte sammeln. Die Belastung unserer Infrastruktur ist nicht zukunftsfähig und gefährdet den Zugang der Menschen zum Wissen: Wir müssen jetzt handeln, um wieder ein gesundes Gleichgewicht herzustellen, damit wir die Wikimedia-Projekte effektiv unterstützen und den nachhaltigen Erfolg unserer Mission ermöglichen können.
    • Schlüsselergebnis WE5.1: Bis zum Ende von Q4 können 50 % der Anfragen über Kanäle für Zugriffe von Programmen bekannten Entwickler:innen oder Anwendungen zugeordnet werden.
      • Wir haben derzeit begrenzte Möglichkeiten, herauszufinden, wer für den automatisierten Datenverkehr verantwortlich ist, und im Gegensatz zu On-Wiki-Nutzungen begrenzte Möglichkeiten, Nutzer:innen zu kontaktieren oder ihren Zugang zu regulieren. Wir haben einen deutlichen Anstieg des externen automatisierten Datenverkehrs beobachtet, der für uns nicht nachhaltig ist und den Zugang der Menschen zum Wissen gefährdet. Wir wollen den Anteil des automatisierten Datenverkehrs, der bekannten Kontos zugeordnet ist, erhöhen, indem wir für Scraping und API-Nutzung hohen Volumens gemäß abgestuften Zugriffsstufen Authentifizierung und Genehmigung verlangen. Dies wird uns helfen, festzustellen, wer Inhalte in großem Umfang wiederverwendet, sodass wir unsere Infrastruktur schützen und die Governance bezüglich fairer Nutzung verbessern können und gleichzeitig die Bedürfnisse der Weiternutzer effektiver erfüllen können. Wir werden auch untersuchen, wie die technische Community besser mit einer kohärenteren Entwicklererfahrung unterstützt werden kann, die den bevorzugten Zugang für Community-Mitglieder erhält und neue Funktionen für Entwickler:innen ermöglicht.
    • Schlüsselergebnis WE5.2: Unterstützung von 70 % der Wikimedia-Web-API-Endpunkte durch allgemeine Infrastruktur bis zum Ende von Q4.
      • Wir wollen die Erfahrung und Nachhaltigkeit unserer Kanäle für Entwickler:innen verbessern, indem wir für alle Wikimedia-Entwickler:innen einheitlichere, stabilere und besser auffindbare Web-APIs anbieten. Wir werden unsere API-Angebote vereinfachen, indem wir eine zentralisierte Infrastruktur für Kern-API-Leistungen einführen, um konsistente Kanäle und Governance für folgende Elemente zu erhalten: OpenAPI-Spezifikationen und -Dokumentation, Entwickleridentifizierung und Zugriffskontrollen, Durchsetzung der API-Richtlinien, Routing, Versionierung und Fehlerbearbeitung. Durch die Modernisierung unserer API-Angebote werden wir es schneller, einfacher und angenehmer machen, Werkzeuge, Bots, Forschungsprojekte und Funktionen zu entwickeln, die der Wikimedia-Mission dienen. Dieser Ansatz unterstützt die multigenerationale Zukunft der Mission, indem er die Wartungskosten für die API-Infrastruktur senkt, die Sichtbarkeit und die Zugangskontrolle für die Bekämpfung böswilliger Akteure erhöht und eine stärkere Entwicklercommunity fördert.
    • Schlüsselergebnis WE5.3: Veröffentlichung und Verlinkung aus den Wikimedia-Websites der neuen Rahmenordnung zur Namensnennung für Web, Apps, Sprachassistenten und große Sprachmodelle bis zum Ende von Q4, mit zwei aktiven Demos für Weiternutzung, die messbare Interaktionen bewirken, und einem externen Partner, der bei der Weiternutzung die Namensnennung optimal umsetzt.
      • Um die richtige Namensnennung bei Wikimedia-Inhalten zu erhöhen, werden wir klare Anleitungen zur optimalen Umsetzung anbieten, die eine verantwortungsvolle Weiternutzung fördern. Das umfasst die Erstellung einer Rahmenordnung zur Namensnennung für die zentralen Plattformen (Web, Apps, Sprachassistenten, Multimedia) und die Demonstration von mindestens zwei praktischen Beispielen, die mögliche Anwendungen von Wikimedia-Inhalten verdeutlichen. Beispiele für Ergebnisse sind die Ermutigung von Medien, bei Bildern aus Wikimedia Commons korrekte Namensnennungen vorzunehmen, von Suchmaschinen, relevante Wikimedia-Daten effektiver anzuzeigen, oder von KI-Assistenten, Wikipedia-Wissen auf transparente und verantwortungsvolle Weise zu integrieren, die das Vertrauen in ihre Zuverlässigkeit erhöht. Die Stärkung der Namensnennungspraktiken verbessert nicht nur das öffentliche Bewusstsein und erhöht die direkten Interaktionen mit den Wikimedia-Projekten, sondern hilft auch, verantwortungsvolle und neue Wege zur Zusammenstellung von Wissen zu etablieren und Missbrauch zu reduzieren.
    • Schlüsselergebnis WE5.4: Verringerung des Datenverkehrs durch Scraper um 20 %, gemessen an der Anfragenrate, bzw. 30 %, gemessen an der Bandbreite
      • Scraping gab es schon immer: Die Suchmaschinen haben sich seit Jahrzehnten auf Wikipedia verlassen, um ihren Nutzer:innen Informationen zu liefern. Aber in letzter Zeit gibt es eine weitere große Motivation dazu, unsere Daten zu scrapen: Es handelt sich um die größte gepflegte, mehrsprachige Sammlung von Wissen, die im Internet zu finden ist, was sie zu einem grundlegenden Werkzeug macht, um große Sprachmodelle zu trainieren. Dies gilt sowohl für unsere enzyklopädischen Inhalte als auch für unsere Multimedia-Sammlung Wikimedia Commons, die für maschinelle Lernmodelle, die Bilder generieren, von unschätzbarem Wert ist.
      • Infolgedessen haben wir im vergangenen Jahr einen deutlichen Anstieg des Datenverkehrs durch Scraper und damit verbundener Probleme mit der Stabilität der Website: Site Reliability Engineers (SRE) mussten wiederholt fallweise die Zugriffsrate einschränken oder Crawler blockieren, um unsere Infrastruktur zu schützen. Das Scraping hat so sehr Überhand genommen, dass unsere ausgehende Bandbreite 2024 um 50 % gestiegen ist. Außerdem zeigte eine aktuelle Analyse, dass mindestens 65 % unserer teuersten Anfragen (jener, die wir nicht über unsere Caching-Server bearbeiten können und die stattdessen von den Hauptdatenbanken bedient werden) von Bots durchgeführt werden.
      • Unsere Rechenressourcen sind im Vergleich zum Datenverkehr sehr begrenzt, weshalb wir Prioritäten setzen müssen, wem wir mit diesen Ressourcen dienen. Wir wollen den menschlichen Konsum fördern und die Unterstützung der Wikimedia-Projekte und -Beitragenden mit unseren knappen Ressourcen priorisieren.

---

Den Weg zu Produktergebnissen beschleunigen (WE6)

• Zielsetzung: Wikimedia-Entwickler:innen bringen ihre Produkte schnell und verlässlich zu den Endnutzer:innen. Diskutieren
  • Kontext der Zielsetzung: Um die vier strategischen Säulen effektiv zu erreichen, müssen die Entwickler:innen von Wikimedia ihre Zeit und ihre Mühe für hochwertige Aktivitäten einsetzen, die so schnell wie möglich zur Bereitstellung qualitativ hochwertiger Produkte führen. Zu komplizierte Arbeitsabläufe, fehlende Standardwerkzeuge und nicht nachhaltige Systemkomponenten stehen diesen Ergebnissen im Weg.
  • Diese Arbeit baut auf dem Anstoß auf, den wir in den letzten zwei Jahresplänen erhalten haben, um MediaWiki als Plattform und die unterstützende Software weiterzuentwickeln. Die Arbeiten für dieses Jahr werden sich auf die Bereitstellung zuverlässigerer Entwicklerumgebungen, die Vereinfachung von Vorproduktionsarbeiten und die Verringerung von Plattform- und Infrastrukturrisiken konzentrieren.
    • Schlüsselergebnis WE6.1: Verringerung der Anzahl von Fehlern, die die Bereitstellung blockieren und es durch die Test-Wikis schaffen, um 10 % bis zum Ende von Q4
      • Im Jahr 2024 mussten Entwickler:innen 144-mal Arbeit noch einmal aufgreifen, weil es einen Notfall gab, der die Bereitstellung der neuen MediaWiki-Version verhinderte. In vielen dieser Fälle wurden die Fehler nach der Bereitstellung in den Testwikis bemerkt, was bedeutet, dass das Problem potenziell ein Milliardenpublikum erreichte. Wir können nicht komplett verhindern, dass es Bugs gibt, aber sie früher abzufangen, würde bedeuten, dass weniger akute heldenhafte Einsätze erforderlich sind. Es würde auch das Vertrauen der Entwickler:innen stärken, dass, wenn etwas in die echte Produktion geht, nicht wieder ein Feuer ausbricht.
      • Wir werden diese Fehler früher erfassen, indem wir Entwickler:innen die Umgebungen bieten, die sie brauchen, um ihren Code während des gesamten Entwicklungs- und Bereitstellungszyklus zuversichtlich einzubringen und zu testen. Wir müssen auch sicherstellen, dass diese Verbesserungen nicht auf Kosten der Entwicklungsgeschwindigkeit gehen.
    • Schlüsselergebnis WE6.2: Umsetzung von vier Schritten aus der Checkliste für die Production-Readiness-Überprüfung ohne SRE-Intervention bis zum Ende von Q4
      • Die produktive Bereitstellung eines neuen Dienstes oder eine neuen Funktion hängt derzeit von einer Liste von 24 Schritten ab, wobei jeder Schritt in der Regel Unterstützung durch SREs erfordert. Wir haben das SRE-Botschafterprogramm eingerichtet, um schon früher im Entwicklungszyklus einzugreifen und innerhalb der Entwicklungsteams eigene Kapazitäten aufzubauen, aber viele der Aufgaben sollten komplett selbstständig ausgeführt werden können. Derzeit handelt es sich um manuelle, repetitive, automatisierbare Arbeit, die mit der Anzahl der Entwicklungsteams linear wächst. Für das SRE-Team ist dies langfristig gesehen nicht zukunftsfähig.
      • In der Vergangenheit wurde viel dieser Arbeit von Entwicklerteams ferngehalten, indem eine Reihe gemeinsamer Bibliotheken und bewährter Praktiken zum Umgang mit unserer Plattform gepflegt wurden. Diese wurden aufgegeben, als wir in unsere neue Kubernetes-Infrastruktur umgezogen sind, und wir haben keinen direkten Ersatz. Durch die Bereitstellung ähnlicher Bibliotheken, Dokumentationen und Trainings, die darauf angepasst sind, wie wir Dinge heute bauen und bereitstellen, glauben wir, dass wir die Häufigkeit der Beteiligung von SREs, die vor dem produktiven Einsatz eines neuen Dienstes oder einer neuen Funktion benötigt wird, reduzieren können.
    • Schlüsselergebnis WE6.3: Bereitstellung von 100 % aller Wikipedia-Seitenaufrufe über Parsoid bis zum Ende von Q4
      • Parsoid bietet verbesserte Funktionen für die Weiterentwicklung von Wikitext und die Zukunftssicherung der Plattform. Die gleichzeitige Aufrechterhaltung von zwei Parsern ist langfristig nicht zukunftsfähig, da sie die technischen Rückstände und die Komplexität erhöht. Darüber hinaus hängt der Erfolg einiger neuer Projekte wie Wikifunctions davon ab, dass Parsoid überall verfügbar ist.
      • Wir haben die Einführung mit kleineren Projekten begonnen und sind in diesem Jahr bereit für Wikipedia. Alle Wikipedia-Seitenabrufe über Parsoid zu verarbeiten, ist der wichtigste nächste Meilenstein. Neben der Einführung an sich umfasst diese Arbeit auch die Lösung von Performance-Problemen und die effektive Kommunikation der Auswirkungen an Lesende und Beitragende.
    • Schlüsselergebnis WE6.4: Eindämmung oder Reduzierung auf ein akzeptables Niveau von mindestens zwei bekannten Risiken, die unsere Fähigkeit, die Wikis weiterzuentwickeln, bedrohen, bis zum Ende von Q2
      • Durch einige gezielte Initiativen werden wir mehrere Skalierbarkeits-, Zuverlässigkeits- oder Sicherheitsrisiken reduzieren oder eindämmen, die wir als potenzielle Bedrohung für das Wachstum und die Nachhaltigkeit unserer Plattform und unserer öffentlichen Projekte identifiziert haben.
      • Zum Beispiel werden wir die Struktur der Kerndatenbanken von Commons umstrukturieren, um sicherzustellen, dass das Wachstum des Projekts in den nächsten Jahren nicht durch die Kapazität der verfügbaren Serverhardware eingeschränkt wird. Wir werden auch PHP, die Programmiersprache, die MediaWiki und verwandte Dienste antreibt, auf eine modernere Version aktualisieren. Andere identifizierte Risiken erfordern wahrscheinlich die Einführung zusätzlicher Sicherheitsmaßnahmen zum Schutz und zur Verstärkung unserer Infrastruktur.

---

Signals and Data Services (SDS)

Matriken (SDS1)

• Zielsetzung: Entscheidungsträger:innen greifen auf verlässlichere und aktuellere Metriken zurück, um Entscheidungen über Produkte und Strategien zu treffen. Diskutieren
  • Kontext der Zielsetzung: Wir verwenden Metriken, um die Entscheidungen der Foundation darüber anzuleiten, worauf wir unsere Bemühungen konzentrieren sollen, um dem Movement am besten zu dienen. Einige unserer Datenleitungen können jedoch leicht kaputtgehen, was zu Verzögerungen bei der Lieferung führt. Wenn Datenprobleme bei uns auftreten, ist die Identifizierungs- und Problemlösungszeit zu lang. Darüber hinaus sind viele unserer Datensätze nicht für eine einfache Erkennung von Trends optimiert und es fehlen Dimensionen, die für die Interpretation der Daten wichtig sind, wie sich gezeigt hat. Diese Probleme verlangsamen und begrenzen unsere Fähigkeit, Metriken auszuwerten.
  • Im Geschäftsjahr 2025/26 werden wir uns auf besondere Anwendungsfälle aus dem Jahresplan konzentrieren, um die Datenqualitätslücken in unseren aktuellen Pipelines zu lösen, Infrastruktur und Prozesse für die Überwachung und Lösung von Problemen mit der Datenqualität vorzubereiten und Werkzeuge anzubieten, die es Entscheidungsträger:innen ermöglichen, Trends zu verstehen.
  • Ein Anwendungsfall ist die Messung die Zugriffszahlen von Menschen und Bots messen. Der Anstieg der automatisierten Zugriffe in den letzten Jahren hat es schwieriger gemacht, zu verstehen, wie stark Menschen mit Wikimedia-Projekten interagieren und zu ihnen beitragen. Wir wollen unsere Möglichkeiten verbessern, menschliche und Bot-Zugriffsmuster auszuwerten, was zentrale Daten für Planungs- und Produktentscheidungen sind.
    • Schlüsselergebnis SDS1.1: Analyst:innen, die Metriken zu Seitenabrufen nutzen, haben bis zum Ende von Q1 Zugriff auf grundlegende Messungen der Datenqualität und der Leistung der Erkennungskriterien für automatisierten Datenverkehr.
      • Durch die in diesem Schlüsselergebnis erforschten Hypothesen wollen wir Lücken in unseren aktuellen Beurteilungskriterien für automatisierten Datenverkehr erkennen und verstehen, wo diese den Datenverkehr der Seitenabrufe nicht richtig kategorisieren. Diese Erkenntnisse werden Verbesserungen der Pipelines, die Seitenabrufsmetriken erzeugen und klassifizieren, ermöglichen. Darüber hinaus werden wir Datenqualitätsmetriken definieren, um Verbesserungen in der Datengenauigkeit zu überwachen und zu messen.
      • Dieses Schlüsselergebnis wird die Grundlage für ein Nachfolge-Schlüsselergebnis legen, das sich auf die Umsetzung der hier festgelegten notwendigen Pipeline-Verbesserungen konzentriert. Die in dieser Phase festgelegten Datenqualitätsmetriken werden als Bezugswerte dienen, um die Wirksamkeit dieser künftigen Verbesserungen zu beurteilen.
    • Schlüsselergebnis SDS1.2: Bis zum Ende des ersten Quartals wird der Inhalt des Mediawiki-Inhaltsgeschichte-Datensatzes über einen Dateiexport mit wöchentlichen Liefergarantien (SLOs) verfügbar sein. Die exportierten Dateidaten werden im Vergleich zur alten XML-Dumps-1-Exportpipeline gleichwertig sein.
      • Ziel des Schlüsselergebnisses 1.4 aus dem Geschäftsjahr 2024/25 war es, die Abhängigkeit der drei wichtigsten Downstream-Pipelines von den monatlich aktualisierten Datensätzen mediawiki_wikitext_history und mediawiki_wikitext_history_current zu beseitigen und einen alternativen Datensatz mit garantierten wöchentlichen SLOs zu schaffen.
      • Während das Schlüsselergebnis 1.4 des Geschäftsjahres 2024/25 dazu beigetragen hat, die Zuverlässigkeitsprobleme der wichtigsten abhängigen Pipelines zu verringern, sind noch Pipelines mit der unzuverlässigen alten Eingabequelle übrig. Diese sollten ebenso wie die dateibasierte Eingabequelle auch direkt in den Wikitext-Versionsgeschichten-Datensatz migriert werden.
    • Schlüsselergebnis SDS1.3: Bis zum Ende von Q2 enthält die Bot-Erkennung ein zusätzliches Signal und erzeugt automatisierte Warnungen bei Anomalien.
      • Bei der Foundation entscheiden Teams über Produkte und Finanzierung, wobei sie sich darauf verlassen, dass sie den Unterschied zwischen menschlichen Lesenden und automatisiertem Traffic bestimmen können. Die Datenplattform ist das zentrale Repositorium für Bot-Erkennungssignale und Batch-Analysen. Durch die Hypothesen, die wir im ersten und zweiten Quartal aufgestellt haben, planen wir, neue Bot-Erkennungssignale einzuführen, um unsere Analyse des automatisierten Datenverkehrs zu verschärfen, und den Prozess der Einführung neuer Signale sowohl effizient als auch wiederholbar zu machen.
    • Schlüsselergebnis SDS1.4: Bis zum Ende des zweiten Quartals haben die Entscheidungstragenden ein klares Verständnis des aktuellen Standes der Erkenntnisse, die durch unsere Organisationsmesswerte bereitgestellt werden. Wir werden wissen, dass wir erfolgreich sind, wenn wir eine für eine Vorstandsversammlung geeignete Präsentation bereitstellen können, die die Analyse unserer Messwerte sowohl ins Wikimedia-Ökosystem als auch in die breiteren Internettrends und Herausforderungen des Marktes einordnet.
      • Erkenntnisse aus unseren organisatorischen Metriken werden verwendet, um eine Vielzahl von Entscheidungen innerhalb der Foundation zu treffen, einschließlich Entscheidungen darüber, wie wir unser Produkt entwickeln, wie wir Infrastrukturressourcen zuweisen und wie wir Geld sammeln. Gleichzeitig entwickelt sich die Landschaft des Internets weiter, wobei sich insbesondere der automatisierte Datenverkehr auf unsere Messwerte auswirkt. Ziel ist es, dass die Leitungsebene der Foundation mit einem klaren Bild von den Bedrohungen und Chancen im Wikimedia-Ökosystem, unterstützt durch eine verlässliche Analyse interner Metriken und externer Trends, in die Kuratoriumssitzung im Dezember geht. Wir können diese Geschichte erzählen, indem wir Erkenntnisse, Metriken und Datenpunkte sammeln, die uns verlässlich über folgende Dinge informieren:
        • Trends in unseren internen Messungen der Leserzahl (Seitenabrufe)
        • Trends in unserem Ökosystem der Beitragenden
        • Trends aus externen Daten und Bezugswerten von Wettbewerbern
        • Erkenntnisse aus internen und externen Studien und vertrauenswürdiger Forschung
    • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
      • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
        • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
        • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).
        • We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.
      • In Q3/Q4, we will follow that with three main deliverables:
        • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
        • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
        • Operationalize a client-side signal, which remains the most promising internally developed detection method.
    • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
      • A consistent delivery cadence
      • Most valuable content for our stakeholders
      • Areas for future automation
      • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
        • What meaningfully changed in the past week/2 weeks?
        • Have we learned anything new about existing trends that we’re questioning?
        • Why does it matter now?
        • What requires attention or action?
      • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

---

Experimentierplattform (SDS2)

• Zielsetzung: Produktmanager:innen können die Auswirkungen von geänderten Produktfunktionen schnell, einfach und sicher beurteilen. Diskutieren
  • Kontext der Zielsetzung: Um die datenbasierte Entscheidungsfindung über die Entwicklung von Produktfunktionen zu ermöglichen und zu beschleunigen, benötigen Produktmanager:innen eine Experimentierplattform, auf der sie Funktionen definieren, die betroffenen Zielgruppen auswählen und Wirkungsmessungen einsehen können. Die Zeit vom Start bis zur Analyse zu beschleunigen ist entscheidend, da die Verkürzung der Lernzeit das Experimentieren und letztlich die Innovation beschleunigt. Manuelle Aufgaben und maßgeschneiderte Messmethoden wurden als Geschwindigkeitsbarrieren identifiziert. Das ideale Szenario ist, dass Produktmanager:innen vom Beginn des Experiments mit wenig oder gar keiner manuellen Intervention von Entwickler:innen und Analyst:innen bis zur Entdeckung gelangen können.
  • Wir konzentrieren uns im nächsten Geschäftsjahr auf Wikipedia, weil Core Experiences dort an Experimenten interessiert ist (die Organisationsstrategie sieht vor, dass wir die Arbeit an Wikipedia intensivieren) und weil dies uns erlaubt, zu verdeutlichen (auch in der Kommunikation), mit welchen Teams und Projekten wir zu tun haben. Andere Teams haben die Komponenten der Experimentierplattform verwendet und können dies auch weiterhin tun, aber diese Nutzung wird nicht der Schwerpunkt dieser Zielsetzung sein.
    • Schlüsselergebnis SDS2.1: Ermöglichung der Durchführung mindestens zweier vollständiger Experimentzyklen mit der Experimentierplattform bis zum Ende von Q2.
      • Da die Organisation zunehmend Wert auf datenbasierte Produktentscheidungen legt, müssen wir Experimente allen Produktteams zugänglich machen, nicht nur denen mit Spezialisierungen. Produktteams benötigen gemeinsame Standards, Werkzeuge und Infrastruktur, die es ihnen ermöglichen:
        • Ideen schnell in unserer globalen Benutzerbasis zu testen
        • Auswirkungen von Produktänderungen mit standardisierten Metriken zu messen
        • Ergebnisse transparent mit Interessensgruppen im Movement zu teilen
      • Warum wir unseren Fokus von der Anzahl der „unterstützten Teams“ zu den „abgeschlossenen Experimenten“ verlegen:
      1. Strategische Ausrichtung: Es ist die wichtigste Erfolgsmetrik der Plattform
      2. Datenbasierter Ansatz: Unsere (laufende) Benutzerforschung deutet auf variable Einsatzbereitschaft der Teams in der Organisation hin, während wir wissen, dass das Webteam Interesse an zwei bestimmten Experimenten bekundet hat.
      3. Ressourcenoptimierung: Die Einführung unserer MVP-Plattform erfordert eine berührungsintensive Anwerbung, wodurch es kurzfristig effizienter ist, sich auf Experimentmöglichkeiten zu konzentrieren, anstatt ein breites Netz über mehrere Teams auszuwerfen. Wir wollen uns zur allgemeinen Veröffentlichung hinbewegen und nicht wieder in das Training von Teams investieren, wenn wir es vermeiden können.
      4. Zukunftsorientiert: Feedback aus den vollständigen Experimentzyklen wird unsere Plattformverbesserungen effektiver anleiten als Erfahrungen aus teilweiser oder unvollständiger Anwendung. Wenn wir uns auf die allgemeine Veröffentlichung konzentrieren, vermeidet ein Fokus auf die Fertigstellung der Experimente, dass wir in vorübergehende Ansätze investieren, die später erneut entwickelt werden müssen.
      • Wir führen eine laufende Benutzerforschung durch, um die teamübergreifenden Bedürfnisse und Anforderungen zu ermitteln: Umfragen und Interviews, um die Anforderungen des Produktteams zu klären, sind in der zweiten Maihälfte 2025 geplant. Sobald die Forschung abgeschlossen ist, werden wir einen Experimentkalender erstellen, mit dem wir unsere nächsten Ziele und Prioritäten aus den Schlüsselergebnissen festlegen können.
    • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
      • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
      • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
      • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
    • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
      • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
      • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
      • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

---

Zukünftige Zielgruppen (FA)

Zukünftige Zielgruppen (FA1)

• Zielsetzung: Die Wikimedia Foundation verfügt über Empfehlungen, welche strategischen Investitionen sie tätigen soll, um unserem Movement zu helfen, neue Zielgruppen in einem sich verändernden Internet zu erreichen. Diskutieren
  • Kontext der Zielsetzung: Aufgrund der anhaltenden Veränderungen in Technologie und Online-Benutzerverhalten (z. B. die zunehmende Bevorzugung von Social-Media-Apps für die Erlangung von Informationen, die Popularität von Kurzvideo-Edutainment, der Aufstieg generativer KI) steht die Wikimedia-Bewegung vor Herausforderungen beim Ansprechen und Anbinden von Lesenden und Beitragenden. Diese Veränderungen bringen auch Chancen, neue Zielgruppen zu erreichen, indem Informationen auf neue Art und Weise geschaffen und aufbereitet werden. Wir als Bewegung haben jedoch kein klares, datenbasiertes Bild von den Vor- und Nachteilen verschiedener potenzieller Strategien, die wir verfolgen könnten, um die Herausforderungen zu überwinden oder neue Chancen zu ergreifen. Sollten wir beispielsweise …
    • In umfangreiche neue Funktionen wie Chatbots 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.
    • Schlüsselergebnis FA1.1: Aufnahme mindestens einer Zielsetzung oder eines Schlüsselergebnisses, die bzw. das nicht in der Verantwortung des Future-Audiences-Teams liegt, in den Entwurf des Jahresplans für das folgende Jahr, als Ergebnis experimenteller Erkenntnisse und Empfehlungen des Future-Audoiences-Teams bis zum Ende von Q3.
      • Seit 2020 verfolgt die Wikimedia Foundation externe Trends, die unsere Fähigkeit beeinflussen können, zukünftige Generationen von Wissenskonsumierenden und -beitragenden zu erreichen und für viele weitere Generationen eine blühende Bewegung für freies Wissen zu bleiben. Future Audiences, ein kleines Forschungs- und Entwicklungsteam, wird
        • Schnelle, zeitlich begrenzte Experimente durchführen (das Ziel sind mindestens drei Experimente pro Geschäftsjahr), um Möglichkeiten zu erforschen, auf diese Trends zu reagieren
        • Auf der Grundlage von Erkenntnissen aus Experimenten Empfehlungen für neue, nicht-experimentelle Investitionen geben - d. h. neue Produkte oder Programme, die von einem vollständigen Team oder mehreren Teams übernommen werden müssen –, die WMF während unserer regelmäßigen Jahresplanungszeit verfolgen sollte
      • Dieses Schlüsselergebnis wird erreicht, wenn mindestens eine Zielsetzung oder ein Schlüsselergebnis, die bzw. das in der Verantwortung eines Teams außerhalb von Future Audiences liegt und von einer Empfehlung von Future Audiencies angetrieben wird, im Entwurf des Jahresplans für das folgende Geschäftsjahr erscheint.

---

Videos in sozialen Medien (FA2)

• Zielsetzung: Junge Menschen (< 25 Jahre alt) lieben es, Wikipedia-Inhalte auf Plattformen zu teilen, auf denen sie ihre Online-Zeit am liebsten verbringen, lernen von diesen Inhalten und interagieren damit. Diskutieren
  • Kontext der Zielsetzung: Die Experimente von Future Audiences mit Kurzvideos in diesem Geschäftsjahr haben gezeigt, dass wir auf diesen Plattformen in großem Stil jüngere Zielgruppen erreichen können, aber unsere Daten zum Markenzustand zeigen, dass unsere derzeitigen Investitionen nicht ausreichen, um dem Rückgang in der Wahrnehmung und der Affinität zu Wikipedia im Gen-Z-Publikum entgegenzuwirken.
  • Um sicherzustellen, dass wir diese Generation effektiv erreichen und einbeziehen, glauben wir, dass wir uns mit einer Vielzahl von Taktiken beschäftigen müssen und unsere Aktivitäten in Bereichen wie bezahltem und Influencer-Marketing, kreativen Kampagnen, Anpassung an Trends und unser Experimentierniveau auf diesen Kanälen deutlich erhöhen müssen.
  • Wir erwarten, dass die Herausforderungen, denen wir gegenüberstehen, eine erhebliche Investition erfordern, um uns dabei zu helfen, sie zu überwinden, insbesondere in Kommunikations- und Marketingbemühungen zur Schaffung von Engagement sowie in der Zusammenarbeit verschiedener Abteilungen zur Schaffung neuer Produkte und Erfahrungen, die darauf ausgerichtet sind, die Präsenz der Marke und der Inhalte von Wikipedia auf diesen Plattformen zu erhöhen.
    • Schlüsselergebnis FA2.1: Generierung von 9,5 Mio. Abrufen durch Kurzvideos in allen Kanälen bis zum Ende des ersten Halbjahres.
      • In diesem Jahr erreichten wir innerhalb von drei Monaten eine Reichweite von etwa 1 Mio. Abrufen, nachdem wir kurze Videos auf den @Wikipedia-Kanälen auf TikTok, Instagram und YouTube veröffentlicht hatten. Zu Beginn des nächsten Geschäftsjahres erwarten wir mehr Follower auf unseren eigenen Kanälen und mehr Einsichten in effektive/engagierende Inhalte, die wir in die Praxis umsetzen können, um noch mehr Zusehende zu erreichen.
      • Durch die Festlegung eines ehrgeizigen Ziels in der ersten Jahreshälfte hoffen wir, auf eine stärkere Wirkung zuzusteuern, neue Strategien/Prozesse zur Erleichterung der Arbeit zu schaffen und zusätzliche Mittel zur Erreichung dieses Ziels beantragen zu können.
    • Schlüsselergebnis FA2.2: Vergrößerung unserer Followerschaft auf TikTok (außerhalb unserer Plattform) vom mittleren Bereich (100.000–250.000) auf ein höheres Niveau (250.000 – 1 Mio.) bis zum Ende des Geschäftsjahrs 25/26 (Juni 2026).
      • Wir befinden uns derzeit im mittleren Bereich von TikTok (100.000–250.000 Follower) und unser Ziel ist es, bis Ende des Geschäftsjahres 25/26 (Juni 2026) die höhere Stufe (250.000 – 1 Mio. Follower) zu erreichen. Diese Ebenen sind standardisierte Schwellenwerte für die Zielgruppegröße und Reichweite. Um dorthin zu gelangen, werden wir unsere Inhaltsstrategie verfeinern, um die Follower der Generation Z besser anzusprechen und unsere allgemeine Sichtbarkeit durch Communitymanagement zu erhöhen. Die Leistung im ersten Halbjahr wird taktische Anpassungen im zweiten Halbjahr ermöglichen, um das Wachstum zu beschleunigen und diesen Meilenstein zu erreichen.
    • Schlüsselergebnis FA2.3: Veröffentlichung eines Produktes abseits der Plattformen, das auf neue Methoden des Lernens und des Medienkonsums zukünftiger Zielgruppen abzielt und durch eine gemeinsam vermarktete Kampagne auf den Markt gebracht wird.
      • Future Audiences arbeitet in der Regel an kleinen Experimenten mit minimalem/organischem Marketing. In diesem Jahr möchten wir uns Zeit für eine größer angelegte neue Produkt- und Marketingkampagne nehmen, die auf jüngere Zielgruppen abseits der Plattformen abzielt.

---

Unterstützung von Produkt und Entwicklung (PES)

Unterstützung von Produkt und Entwicklung (PES1)

• Zielsetzung: Die Produkt- und Entwicklungsteams der WMF sind dank verbesserter Prozesse effektiver, was eine positive Entwicklung unserer Kultur fördert. Diskutieren
  • Kontext der Zielsetzung: Bei dieser Zielsetzung geht es darum, die Arbeitsweise der Wikimedia Foundation schneller, klüger und besser zu machen. Es geht darum, wie wir arbeiten. Dies bedeutet weniger Spannungen und Hindernisse (Ineffizienz und Fehler) in Prozessen und die schnellere Erzielung von Wirkung. Diese Zielsetzung umfasst auch das Erlernen von Arbeitsweisen, die in der ganzen Abteilung und Organisation übernommen werden können.
    • Schlüsselergebnis PES1.1: Festlegung von SLOs für sechs produktive Dienste auf der Grundlage eines Priorisierungsschlüssels, der darauf abzielt, unsere Lernerfahrung zu maximieren, wie SLOs festgelegt und genutzt werden können, um fundierte Entscheidungen über die Priorisierung von Arbeit im Bereich Verlässlichkeit durch Stakeholder-Teams zu treffen.
      • Ein Service Level Objective (SLO) ist eine Vereinbarung zwischen Stakeholder-Teams über ein Zielniveau (Verlässlichkeit/Leistung), auf dessen Erreichung die Teams hinarbeiten. Das hilft beispielsweise dabei, zu bestimmen, wann ein Entwicklungsteam die Arbeit an Zuverlässigkeit oder Leistung priorisieren oder de-priorisieren sollte oder was ein Problem darstellt. Die Teams müssen sich bemühen, zu identifizieren, was von unmittelbarer Bedeutung ist (Warnungen / Reaktionen auf Zwischenfälle / kritische Fehler) und was nicht. Das Ziel ist es, die Spannung zwischen den Funktionen durch gemeinsame Festlegung von Zielen und durch Information über eine gemeinsame und klare Priorisierung zu reduzieren.
    • Schlüsselergebnis PES1.2: Auswirkung von Community-Signalen (einschließlich der Wunschliste) auf WMF bis zum Ende von Q2, um mindestens fünf Produkt-Workstreams für Q3–Q4 zu priorisieren.
      • Unser Ziel ist es, zu erkennen und zu unterstützen, wenn Teams Arbeit auf der Grundlage von evidenzbasierten Community-Anfragen priorisieren.
      • Zwei geplante Hypothesen konzentrieren sich ausschließlich auf die Wunschliste. Sie sollen Vertrauen verbessern, Prozesse optimieren und die Beteiligung von Angestellten und Freiwilligen erhöhen. Eine andere Hypothese ist ein Experiment, das darauf abzielt, zu sehen, ob ausreichend wertvolle Signale von Projektdiskussionsseiten usw. kommen und ob KI unsere Signalsammlung unterstützen kann.
    • Schlüsselergebnis PES1.3: Aufnahme zweier abteilungsübergreifender Experimente in frühem Stadium, die durch unsere externen Zielgruppen (Konsumierende, Spendende, Beitragende) validiert werden, in den Jahresplan der Foundation.
      • Bei dieser Arbeit geht es darum, Experimente und Experimentierprozesse für die Übernahme in unserer gesamten Organisation zu schaffen.
      • Die Foundation stärkt eine Kultur der abteilungsübergreifenden Experimente, indem sie zwei validierte Experimente in einem frühen Stadium in ihren Jahresplan einbezieht. Diese Initiative fördert die Zusammenarbeit über die Funktionsteams der Produkt- und Technologie-Abteilung hinaus und regt mehr Innovation mit anderen Abteilungen der Organisation (etwa Kommunikation und Advancement) an. Durch die Ausstreuung ungetesteter neuer Ideen und die Verfeinerung von Prozessen für Experimente verbessern Teams die Produktivität und vergrößern die Wirkung. Erfolg wird durch Abschluss von zwei abteilungsübergreifenden Experimenten pro Jahr, deren Integration in zukünftige OKR-Arbeit und die zunehmende Anwendung von Experimentierpraktiken gemessen. Beispiele für Ergebnisse sind neue Prototypen, um das Wachstum und die Produktivität neuer Beitragender zu erhöhen, oder experimentelle Funktionen, die die Bindung von Lesenden und Spendenden an Wikipedia vertiefen. Eine spezifische Gelegenheit, die identifiziert wurde, ist die Verbindung kleiner Funktionstests zur Feier des 25. Geburtstags der Wikipedia.
    • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
      • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
      • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
      • We're anticipating that this will mean:
        • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
        • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
        • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
      • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
    • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
      • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
        • We have 19 SLOs currently.
        • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
        • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
      • Success looks like:
        • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
        • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
        • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
        • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
    • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
      • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
        • We estimate there are ~20 critical services without owners.
        • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
        • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
    • Key result PES1.7: By the end of Q4, for Wishes received in Q3 and Q4, the rate of Wishes shipped improves to 5%.
      • We calculated that there have been 76 Wishes submitted since Q1 this FY, and 2 have been completed, for a rate of ~2.6%.
      • Commtech can, on average, complete a Wish per quarter (the time varies by size, hence the average).
      • If we assume that over the next 6 months we'll get a similar number of new Wishes, then we can do ~2 more without any other teams contributing. Since the whole point is more teams picking up Wishes, 5% total is roughly 2 more wishes on top of the baseline of 2, for a total of 4 by the end of June. One wish per P&T team would be ~3-4 teams depending on Commtech's contribution. In short, we want to double our Wish completion rate over the next 6 months.
      • Success:
        • Diversity of contribution: we want Wishes to be completed by several teams, not just one. We can count contractor support as one "team." We need to engage teams beyond ad-hoc requests; this is about operationalizing their commitment and delivery.
        • Diversity of Wish: we want a variety of Wishes, including service area, type (bug, feature, etc.), and size.

Hypothesen

1. Quartal

Das erste Quartal (Q1) des WMF-Jahresplans umfasst die Monate Juli–September.

Hypothesen zu Wiki Experiences (WE) [ WE-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q1-Text	Einzelheiten und Diskussion
WE1.1.1	Wenn wir neue(re) Freiwillige, die Text von einer externen Website einfügen, dazu auffordern, zu bestätigen, dass sie die hinzugefügten Inhalte selbst geschrieben haben, wird der Anteil der neuen inhaltlichen Beiträge, die neue(re) Freiwillige veröffentlichen und die wegen WP:URV (und verbundenen Regeln) zurückgesetzt werden, um ≥10 % zurückgehen.
WE1.1.2	Wenn wir eine erste Betaversion des Bearbeitungsvorschlags „Stil verbessern“ bereitstellen, können wir ermitteln, ob dieses neue Format für Bearbeitungsvorschläge eine sinnvolle Methode ist, um konstruktive Bearbeitungen neuer Beitragender zu erhöhen, ohne die Moderationsbelastung für Sichter:innen zu erhöhen.
WE1.1.3	Wenn wir einen neuen Vorschlagsmodus für erfahrene Beitragende im Visual Editor (Mobil- und Desktopversion) mit ≥ 3 neuen Bearbeitungsvorschlägen als Betafunktion aktivieren, werden wir herausfinden, welche – und ob – Anpassungen vorgenommen werden müssen, bevor die Erfahrungen mit neue(re)n Freiwilligen durch ein kontrolliertes Experiment bewertet werden können.
WE1.1.4	Wenn wir den Beleg-Check in en.wiki im Rahmen eines kontrollierten Experiments aktivieren, werden wir einen Anstieg um ≥ 10 % bei den konstruktiven Beiträgen, die neue(re) Freiwillige tätigen, beobachten und herausfinden, ob Moderator:innen und Kontrolleur:innen die Funktion ausreichend befürworten, um sie weitergehend zu aktivieren.
WE1.1.5	Wenn wir ein Fortschrittssystem über Designprototypen mit Neulingen testen, können wir feststellen, welche Arten von Meilensteinen, Anleitungen und Anerkennungen am motivierendsten wirken, und diese Erkenntnisse verwenden, um ein Design für zukünftige Experimente in Pilot-Wikis zu finalisieren.
WE1.1.6	Wenn wir die wichtigsten technischen, sozialen und verhaltensbezogenen Barrieren und Voraussetzungen für die mobile Bearbeitung im Browser durch Nutzerforschung und Datenanalyse untersuchen, werden wir mindestens drei umsetzbare Erkenntnisse erarbeiten, die die wichtigsten Wissenslücken schließen und unsere Fähigkeit verbessern, die Produktinvestitionen für die zweite Hälfte des Geschäftsjahrs 25/26 und darüber hinaus zu priorisieren.
WE1.2.1	Wenn wir einen Konzeptnachweis für die Anzeige von Daten über die Zusammenarbeit in den Wikis erstellen, können wir Feedback von mindestens 30 Beitragenden sammeln, wobei 70 % der Befragten angeben, dass die Funktion nützlich ist und dazu beitragen könnte, das Wachstum der Zusammenarbeit zu fördern.
WE1.3.1	Wenn wir die Bedürfnisse, die in früheren Studien und Designs identifiziert wurden, nutzen und frühe Modelle der X wichtigsten Moderationsmodule vorstellen, können wir damit die Startseite für Moderationsmaßnahmen ändern.
WE1.3.2	Wenn wir die Neulingsstartseite so anpassen, dass sie unter bestimmten Bedingungen Moderationsmodule anzeigt, können wir die Machbarkeit einer Nutzung der Startseite für Moderator:innen beweisen.
WE1.4.1	Wenn wir eine Reihe von Verbesserungen vornehmen, die in T396489 genannt wurden, werden wir die langsamen Anfragen nach den Letzten Änderungen in großen Wikis um X Prozent reduzieren. Dann können Moderationswerkzeuge die Startseitenmodule in diesen Wikis ohne besondere Bedenken hinsichtlich der Datenbankleistung bereitstellen.	T400696
WE2.1.1	Wenn wir Muttersprachler:innen aus kleinen Wikis über ein CentralNotice-Banner auf einer viel aufgerufenen Wikipedia in ihrer Region einladen, zu Bearbeitungsvorschlägen und anderen Growth-Funktionen beizutragen, können wir beurteilen, ob dieser Ansatz neue Muttersprachler:innen anzieht und ob sie diese Bearbeitungswerkzeuge verwenden, um wichtige Inhalte zu verbessern.
WE2.1.2	Wenn wir für neue Beitragende geeignete Übersetzungsvorschläge entwickeln und veröffentlichen, könnten wir dann prüfen, ob dieser Ansatz im Vergleich zu unserem derzeitigen Ansatz bessere Übersetzungen liefert. Dies bezieht sich auf bekannte Herausforderungen, mit denen neue Beitragende konfrontiert sind, die mit höherer Wahrscheinlichkeit eine Artikellöschung erleben. Durch die Konzentration auf die Übersetzung handhabbarer Inhalte soll eine weniger überwältigende und zugänglichere Einführung in den Übersetzungsprozess ermöglicht werden. Gute Kandidaten für Artikel und Abschnitte könnten eine geringere Komplexität in Formatierung und Gesamtlänge aufweisen.
WE2.1.3	Wenn wir mehr über die Erfahrung von Beitragenden bei der Erstellung neuer Artikel und Abschnitte erfahren (einschließlich Motivationen, Schwierigkeiten und Reaktionen auf neue Ideen, sie besser zu unterstützen), werden wir Bedürfnisse und Verhaltensweisen der Benutzer:innen entdecken, die umsetzbare Einblicke und Strategien für Produkt, Design und Entwicklung zur Verbesserung der Erfahrung bei der Artikelerstellung bieten.
WE2.1.4	Wenn wir durch Workshops oder Interviews untersuchen, wie drei mittelgroße Wikipedia-Sprachversionen mit Wissenslücken und der Bewertung wichtigen Wissens umgehen, werden wir Arbeitsdefinitionen oder Konzepte für „zentrales Wissen“ finden, die für jede Community relevant sind.
WE2.2.1	Wenn wir die Einführung von Parsoid verfolgen und Wikifunctions in die meisten Wiktionarys und einige Wikipedias mit geringem Datenverkehr integrieren, erhalten wir die Testmöglichkeiten, die wir benötigen, um die Einführung sicher in größeren Wikis durchführen zu können.
WE2.2.2	Wenn wir es Wikifunctions ermöglichen, HTML-Tabellen, Stile und Links auszugeben, werden wir durch eine Funktion, die eine Konjugationstabelle anzeigt, die Fähigkeit des Projekts demonstrieren, neues Wissen in Wiktionarys zu generieren, und nicht nur einfache Umwandlungen durchzuführen.
WE2.2.3	Wenn wir Unterstützung für Wikidata-Elemente in eingebetteten Funktionsanrufen hinzufügen, werden wir über 200 neue Funktionen aktivieren, die vollständige Sätze aus Wikidata-Elementen erzeugen können, was die Nutzung von Funktionen in Wikimedia-Projekten erleichtert.
WE2.2.4	Wenn wir einen Architekturplan dafür entwickeln, wo Abstrakte Inhalte gespeichert werden und wie sie mit Wikipedia interagieren, sind wir besser darauf vorbereitet, die Plattform für die Abstrakte Wikipedia zu implementieren, um die Bereitstellung hochwertiger enzyklopädischer Inhalte zu verstärken.
WE2.2.5	Wenn wir in den Produkt- und Technologie-Teams die Produktbedürfnisse für Zitate, die für Abstrakte Inhalte erforderlich sind, definieren und uns darüber austauschen, werden wir in der Lage sein, wikimediaübergreifende Arbeiten anzutreiben, um Herkunftsinformationen für Abstrakte Inhalte zu liefern, was für eine erfolgreiche Nutzung in allen Wikis entscheidend ist.
WE2.2.6	Wenn wir unser backendinternes Abfragenformat ausdrucksstärker und prägnanter gestalten, können wir die Stabilität des Systems erhöhen und so eine breitere Einführung unterstützen.
WE2.2.7	Wenn wir Prototypfragmente mithilfe von Wikidata- und Wikifunctions-Aufrufen bereitstellen, um Ausschnitte in natürlicher Sprache zu generieren, zeigen wir, dass das Projekt bereit ist, und sind darauf vorbereitet, es zum Trainieren von KI zu verwenden, sodass Menschen nicht zu viel über Funktionen nachdenken müssen.
WE2.2.8	Wenn wir den Import von Wikidata-Aussagen mit Qualifikatoren ermöglichen, können vielschichtige Fakten generiert werden (Fakten, die mehr als nur Subjekt/Prädikat/Wert brauchen um ausgedrückt zu werden), was schätzungsweise 50 % der enzyklopädischen Inhalte in Wikidata umfasst.
WE2.2.9	Wenn wir die Zwischenspeicherung abgerufener Wikidata-Elemente ermöglichen, reduzieren wir die durchschnittliche Laufzeit inhaltsbasierter Funktionen von Wikidata um mindestens 50 % und verringern so Zeitüberschreitungen und Frust auf Benutzerseite.
WE2.2.10	Wenn wir eine Wikidata-Lexem-Sinnkomponente in der Wikifunctions-UI bereitstellen, können Beitragende relevante Lexeme identifizieren und auswählen, ohne die Plattform/Wikifunctions zu verlassen – wodurch die Kontextumstellung reduziert und die schnellere und erfolgreichere Erstellung sprachbezogener Funktionen ermöglicht wird.
WE2.2.11	Wenn wir die Erkenntnisse zur Benutzerfreundlichkeit aus der Dagbani-Community über die Wikifunctions-Integration in Wikipedia behandeln, werden wir feststellen, dass Beitragende beim Einfügen einer Funktion in einen Artikel während Tests weniger oder keine kritischen Benutzungsprobleme erleben.
WE3.1.1	Wenn wir eine verbesserte Version der Tabbed-Navigationsfunktion testen, werden wir in der iOS-App eine 5%ige Zunahme der mehrtägigen Nutzung unter Nutzer:innen von Tabs beobachten.
WE3.1.3	Wenn wir Nutzer:innen eine neue Möglichkeit bieten, in Artikelseiten durch relevante Bild- oder Videoinhalte zu navigieren, werden wir bei Nutzer:innen, denen diese Funktion präsentiert wird, eine Klickrate von mindestens 3 % beobachten.
WE3.1.4	Wenn wir Leser:innen mehrere Konzepte für das Erkunden des Wissensnetzes in den Wikis zeigen, werden wir eine priorisierte Liste von Konzepten für weitere Entwicklung erhalten.
WE3.1.5	Wenn wir Leser:innen im Browser die Möglichkeit geben, eine maschinell übersetzte Version von Wikipedia-Inhalten, die nicht in ihrer Sprache verfügbar sind, zu sehen, werden wir herausfinden, ob die Leseaktivität erhöht wird, gemessen als ein 3%iger Anstieg der Seiteninteraktionen, wodurch Leser:innen ins Wiki ihrer lokalen Sprache gelenkt werden, mit einem potenziellen Anstieg der lokalen Bearbeitungsaktivität. Dies wird als kontrollierter A/B-Test für maximal sechs Monate und in 13 Wikipedia-Sprachversionen (nach vorheriger Zustimmung) mittels offener maschineller Übersetzungsdienste zur Verfügung gestellt, die bereits für Wikipedia-Beitragende verfügbar sind.
WE3.2.1	Wenn wir mit dem Fundraising-Team zusammenarbeiten, werden wir im iOS-Jahresrückblick interessantere sowie besser integrierte und personalisierte Darstellungen für Spendende entwickeln, gemessen durch Benutzertests. Im zweiten Quartal folgt eine Hypothese, um zu beurteilen, ob der verbesserte Jahresrückblick 5 % mehr Spenden angeregt hat als der Jahresrückblick 2024.
WE3.2.2	Wenn wir Leser:innen der Android-App in Märkten ohne Spendenkampagne dazu bringen, eine optionale, anpassbare (in Betrag und Häufigkeit) Erinnerung an Spenden auf der Grundlage ihrer Wikipedia-Nutzung einzustellen, werden wir in diesen Märkten einen Anstieg der Spenden aus dem App-Menü um 5 % sehen.
WE3.2.3	Wenn wir ein A/B-Test-Experiment mit nicht angemeldeten Benutzer:innen durchführen, um subtile Varianten des Spenden-Ausgangspunkts für Mobil- und Desktopgeräte auszuspielen, werden wir eine um 2 % höhere Anzahl von Spenden in der Testgruppe im Vergleich zur Kontrollgruppe beobachten.
WE3.3.1	Wenn wir die 2024 von iOS-Nutzer:innen gewünschten personalisierten Elemente, die geringen bis mittleren Aufwand erfordern, zum Jahresrückblick 2025 hinzufügen, werden wir eine Zunahme der Zufriedenheit um 3 % im Vergleich zum Vorjahr sehen, gemessen durch Tests der Benutzerfreundlichkeit oder Beta-Tests.
WE3.3.2	Wenn wir den bestehenden Bearbeiten-Reiter auf Android zu einem personalisierten Aktivitätshub erweitern, der Einblicke in Lese- und und andere Beteiligung jenseits des Bearbeitens umfasst, werden wir einen Anstieg der mehrtägigen Nutzung des Reiters um 5 % im Vergleich zur ursprünglichen Version beobachten.
WE3.3.3	Wenn wir in der Android-App mindestens einen freischaltbaren Avatar für Kontoinhaber einführen, der durch sinnvolle Lese-Tätigkeiten wie die Speicherung einer bestimmten Anzahl von Artikeln verdient werden kann, erhöhen wir die Wiederholung dieser Tätigkeit durch angemeldete Benutzer:innen um 10 %, gemessen über mehrere Tage.
WE3.3.4	Wenn wir angemeldeten Leser:innen die Möglichkeit geben, Artikel in einer privaten Leseliste zu speichern, erwarten wir eine Steigerung der Aktivitäten auf der Website, gemessen an einem Anstieg des internen Referral-Datenverkehrs um 5 % für Leser:innen, die die Funktion verwenden, und einem statistisch signifikanten Anstieg für alle Benutzer:innen.
WE3.3.5	Wenn wir eine Benutzerstudie durchführen, die es Leser:innen im Browser ermöglicht, Wikipedia-Inhalte zu sammeln / zusammenzustellen, dann speichern mindestens 10 % der Teilnehmenden zwei oder mehr verschiedene Inhaltsarten (z. B. Artikel, Auszüge, Medien) in einer Sammlung.
WE3.4.1	Wenn wir auf eine hybride PoP/CDN-Freischaltung hinarbeiten, können wir sowohl volle PoPs als auch Mini-PoPs (physisch und in der Cloud) als notwendig vorbringen und so die Grundlage für einen Prototyp für eine Mini-PoP-Aktivierung in der Zukunft legen.
WE3.6.1	Wenn wir einen A/A-Test über die Anbindungsrate nicht angemeldeter Benutzer:innen durchführen, werden wir eine Basis für die Anbindungsrate festlegen, die wir für zukünftige Quartale verwenden können.
WE3.6.2	Wenn wir eine Definition angemeldeter Leser:innen erstellen und veröffentlichen, können wir diese Definition für alle Teams und Hypothesen im Zusammenhang mit dem Schlüsselergebnis WE 3.3 verwenden.
WE3.6.3	Wenn wir die Communitys in Gespräche über die sich weiterentwickelnden Bedürfnisse der Leser:innen und über die sich verändernde Natur des Wissens im Internet einbeziehen, können wir einen gemeinsamen Fokus darauf entwickeln, wie wir den Leser:innen am besten dienen, und gemeinsam daran arbeiten, ob und wie wir unsere verschiedenen Ideen testen können (einschließlich solcher zu Multimedia, Suche und Entdeckung und maschinellem Lernen).
WE3.6.4	Wenn wir die unterschiedlichen Motivationen, Verhaltensweisen und Bedürfnisse untersuchen, die hinter den Fragen, wann, warum und wie Leser:innen Wikipedia und andere Wissensplattformen verwenden, stecken, werden wir Ergebnisse erzielen, mit denen wir unsere Strategie für Konsumierende verbessern und weiterentwickeln können.
WE4.1.1	Wenn wir einen Prototyp für einen minimal lebensfähigen Flow abseits von Notfällen entwickeln und dabei ein wiederholtes Rückmeldungsverfahren offen halten, während wir ihn mit Benutzer:innen mit erweiterten Rechten entwickeln, dann unterstützen diese Gruppen die weitere Bereitstellung dieses Flows.	Project page
WE4.2.1	Wenn wir das hCaptcha-Risikolevel, das mit der Kontoerstellung verbunden ist, vertrauenswürdigen Funktionär:innen übermitteln, werden wir die Zeit, die benötigt wird, um böswillige Akteur:innen zu erkennen, verringern und die Häufigkeit der Entdeckung solcher Konten, die auf der Plattform erstellt werden, erhöhen. Wir können den Erfolg der Hypothese messen, indem wir uns die Rate der auf Konten angewandten Sperren, die Angleichung des hCaptcha-Risikolevels und der Kontensperren allgemein sowie das qualitative Feedback von Funktionär:innen ansehen.
WE4.2.2	Wenn wir vorgeschlagene Untersuchungen erstellen, die Checkuser weiterführen sollen, werden wir eine Verringerung der benötigten Zeit zur Identifizierung von Konten böswilliger Akteur:innen und eine Zunahme der Anzahl der identifizierten böswilligen Akteur:innen sehen. Wir werden wissen, dass wir erfolgreich sind, wenn wir die regelmäßige Nutzung der Funktion „Vorgeschlagene Untersuchungen“ und eine Zunahme der Maßnahmen, die auf Konten angewendet werden, die über vorgeschlagene Untersuchungen identifiziert wurden, beobachten, sowie über Rückmeldungen aus qualitativen Umfragen.
WE4.2.3	Wenn wir Daten aus dem hCaptcha-Kontenerstellungsversuch analysieren, werden wir den Pfad der Kontenerstellung sowie die Wirksamkeit der hCaptcha-Puzzles und -Scores verstehen und die Daten erhalten, die notwendig sind, um die weitere Einführung von hCaptcha bei Kontenerstellung zu untermauern.
WE4.2.4	Wenn wir die UserInfoCard in allen Wikis freischalten, werden wir Funktionär:innen und Moderator:innen befähigen, Konten böswilliger Akteur:innen effizienter zu identifizieren und entsprechende Maßnahmen zu ergreifen.	Project page
WE4.2.5	Wenn wir Forschung durchführen, uns mit Communitys austauschen und technische Lösungen untersuchen, werden wir in der Lage sein, eine Reihe von strukturierten Sperrgründen zu definieren, die in allen WMF-Wikis verwendet werden können.
WE4.2.6	Wenn wir die Fähigkeit entwickeln, auf der Datenplattform OpenSearch-basierte Cluster zu implementieren, werden die Entwicklerteams für Produktfunktionen in der Lage sein, Systeme zu entwickeln, die diese Fähigkeit integrieren, mit einer großen Autonomie, Resilienz und Isolation von anderen suchbasierten Systemen. Der erste und wichtigste Nutzer dieses Systems wird der IPoid-Dienst sein.
WE4.2.7	Wenn wir die Integration von hCaptcha Enterprise in mehreren produktiven Wikipedias als Pilotversuch aktivieren, können wir Daten über die Wirksamkeit und den Wert von hCaptcha Enterprise in Bezug auf Missbrauchsbekämpfung, Bot-Erkennung, Benutzungsfreundlichkeit und Barrierefreiheit sammeln.
WE4.3.1	Wenn wir die Unterstützung für das neue Edge-Uniques-Cookie in requestctl, unsere Edge-Rules-Engine für SREs, die Missbrauch bekämpfen, integrieren, werden wir uns besser vor DDoS und Inhaltsweiterverwendung schützen können.
WE4.4.1	Wenn wir auf der Basis von Rückmeldungen aus Pilotprojekten Verbesserungen vornehmen und temporäre Konten für alle Projekte aktivieren können, können wir personenbezogene Daten (IP-Adressen) nicht registrierter Beitragender in all unseren Projekten schützen, indem wir sie nur noch weniger als 0,1 % aller (angemeldeten) Benutzer:innen zur Verfügung stellen.	Project page
WE4.4.2	Wenn wir mit den relevanten Interessensgruppen in der Wikimedia-Bewegung (einschließlich Wiki-Communitys und globalen Funktionär:innen) klar und pünktlich kommunizieren, können wir die Bereitstellung in allen verbleibenden Wikis leisten, kurzfristige Arbeitsbelastung reduzieren und Zurücksetzungen vermeiden.
WE4.4.3	Wenn wir es Kontrolleur:innen leichter machen, die Aktivitäten temporärer Konten zu sehen und Aktionen danach zu filtern, basierend auf den zugehörigen IP-Adressen, dann können temporäre Konten erfolgreich auf allen Wikis aktiviert werden.
WE4.4.4	Wenn wir erlauben, den Zugriff auf die IP-Betrachtung temporärer Konten gemäß der IP-Betrachtungsrichtlinie zu widerrufen und die Funktion an mehr Stellen bereitstellen, dann können temporäre Konten erfolgreich in allen Wikis aktiviert werden.
WE4.5.1	Wenn wir qualitative Forschung durchführen, um Beispiele für Missbrauch durch böswillige Akteur:innen, die durch generative KI unterstützt werden, zu finden (wie Spam, Belästigung, langfristigen Missbrauch, nicht offengelegte bezahlte Bearbeitungen oder Desinformationskampagnen), werden wir in der Lage sein, das Risiko für unsere Community-Modelle zu bewerten und Ideen zusammenzustellen, um verschiedene Arten von Missbrauch, der durch generative KI unterstützt wird, zu mildern.
WE4.6.1	Wenn wir den Synchronisierungsprozess für Konten innerhalb von Zendesk für Passwortzurücksetzungen automatisieren, wird dies die Belastung von T&S verringern und es ihnen ermöglichen, mehr eingehende 2FA-Zurücksetzungsanfragen zu behandeln.
WE4.6.2	Wenn wir Benutzer:innen unterstützen und dazu ermutigen, mehrere Authentifizierungsfaktoren zu registrieren, werden Benutzer:innen mit aktivierter 2FA sich weniger wahrscheinlich aus ihrem Konto aussperren.
WE4.6.3	Wenn wir allen Benutzer:innen mit einer bestätigten E-Mail-Adresse erlauben, 2FA für ihre Konten zu aktivieren, aber diese Änderung nicht proaktiv bei Benutzer:innen bewerben, bleibt die Arbeitsbelastung für die Wiederherstellungsunterstützung auf einem nachhaltigen Niveau.
WE5.1.1	Wenn wir verschiedene Speicher-Backends für authentifizierte und anonyme Sitzungen verwenden, können wir Sessionstore vor DDoS-Angriffen und umfangreichem Scraping schützen, indem wir es nicht mit den anonymen Sitzungen überladen, die für die CSRF-Prävention auf Authentifizierungsseiten erstellt werden.	T398814
WE5.1.2	Wenn wir MediaWiki-Sitzungs-Cookies in ein strukturiertes Format mit einer kryptographischen Signatur ändern, können wir die Anwesenheit einer Sitzung als Schutzfaktor gegen Scraper nutzen, indem wir eine zuverlässige Überprüfung der gefährdeten Sitzungen auf leistungsfähige und hochskalierbare Weise ermöglichen.	T398815
WE5.1.3	Wenn wir eine Ratenlimitierungslösung für das API-Gateway mit einer lokalen Entwicklungsumgebung auf Kubernetes erstellen, können wir die beste Option bestimmen, die wir im Produktionsverkehr testen müssen, indem wir die Leistung und Funktionalität von mindestens drei verschiedenen Ratenlimitierungsdiensten vergleichen.	T398913
WE5.2.1	Wenn wir die REST-API-Sandbox-UI neu gestalten, um den Informationsbedürfnissen der Entwickler:innen besser gerecht zu werden, werden wir die Klarheit der Dokumentation verbessern, wie durch Tests der Benutzungsfreundlichkeit bestätigt wird.
WE5.2.2	Wenn wir alle APIs unter rest.php durch ein zentrales Gateway leiten, werden wir die Möglichkeiten des zentralisierten API-Managements freischalten und können anfangen, konsequent den REST-API-Datenverkehr und Nutzungsmuster zu messen, um Einblicke zu erhalten, die die Grundlage für zukünftige Entscheidungen und Aktionen bilden.
WE5.2.3	Wenn wir Monitoring-Dashboards und Alarme für die MediaWiki-REST-API implementieren, dann können wir eine nachhaltige, nützliche und replizierbare Möglichkeit demonstrieren, um Einblicke ins Verhalten unserer Systeme zu verbessern und Probleme schneller zu bemerken, insbesondere bei kritischen Modifikationen.
WE5.3.1	Wenn wir die Leitlinien für die UX-Attribuierung erweitern und optimieren und gleichzeitig bestehende Leitlinien aktualisieren, werden wir eine Reihe von verbesserten Leitlinien erstellen, die intern getestet und iterativ verfeinert werden können, um für eine breitere öffentliche Nutzung vorbereitet zu sein.
WE5.3.2	Wenn wir einen Pitch erstellen, der Drittanbieter-Weiternutzern von Inhalten und deren Endnutzern die Vorteile der Namensnennung von Wikipedia zeigt, können wir WME4.1 und WME4.2 unterstützen, indem wir erreichen, dass mindestens ein weiterer Weiternutzungspartner zustimmt, bis zum Ende des ersten Quartals in einer Namensnennungsstudie oder -demo aufzutauchen.
WE5.4.1	Wenn wir sicherstellen, dass die meisten Webanfragen ein Edge-Uniques-Cookie erhalten, wird es einfacher, Bots und gefälschte Anfragen zu identifizieren.
WE5.4.2	Wenn wir eine skalierbare Möglichkeit schaffen, bekannte Clients zu identifizieren, können wir Ausnahmen von allgemeinen Ratenlimitierungsgrenzwerten für Bots mit verifiziertem Ursprung erlauben und zu einer systematischen Durchsetzung unserer Regeln übergehen.
WE5.4.3	Wenn wir das Filtern von Textanfragen im CDN über einen Allowlist/Denylist-Ansatz neu organisieren, können wir eine strengere allgemeine Ratenlimitierung für Bots durchsetzen und das Filtern des Datenverkehrs optimieren.
WE5.4.4	Wenn wir eine einheitliche Messstrategie entwickeln, werden wir die Bewertung der mehrjährigen Strategie für „verantwortungsbewusste Infrastrukturnutzung“ ermöglichen und einen Fahrplan erstellen, um die Entwicklung von Metriken und die Berichterstattung zu ermöglichen.
WE6.1.1	Wenn wir die täglichen Bilder-Builds auf den Deployment-Server verlagern und Bild-Updates hinzufügen, die durch ausgewählte Bereitstellungsaktionen ausgelöst werden, werden wir Einschränkungen finden und festlegen, welche Zeit für mehr kontinuierliche Bereitstellungen benötigt wird.
WE6.1.3	Wenn wir Wikifarms zu einem Pre-Merge-Testumfeld hinzufügen, ermöglicht es dies Entwicklungsteams, die abweichend von der Produktionsumgebung entwickeln und die mehrere Wikis benötigen, ihre Patches isoliert zu testen, was ihnen mehr Vertrauen vor der Produktion gibt und zu weniger Fehlern führt.
WE6.2.1	Wenn wir unsere Checklist zur Produktionsbereitschaft überprüfen und veröffentlichen, in der die Voraussetzungen für einen als produktionsfertig angesehenen Dienst sowie selbst bedienbare Aufgaben klar definiert werden, werden wir die Erwartungen zwischen den SREs und den Entwicklungsteams ausgleichen und unsere Betriebseffizienz und Skalierbarkeit insgesamt verbessern.
WE6.2.2	Wenn wir die Erstellung einer Golang- und Nodejs-Bibliothek ankündigen, die viele mühsame Aufgaben für Entwickler:innen abstrahiert, werden sie mit Feedback und Interesse reagieren.
WE6.2.3	Wenn wir eine Checklist / ein Worksheet erstellen, können sich die Entwickler:innen im Voraus vollständig auf die Datenpersistenz-Designprüfung vorbereiten.
WE6.3.1	Wenn wir im ersten Quartal die Aktivierung in mindestens 70 Wikipedia-Sprachversionen mit geringem Datenverkehr vornehmen, ohne Wikis mit Sprachvariantenunterstützung, werden wir unser Selbstvertrauen für die spätere Aktivierung in den Top-10-Wikis erhöhen, die einen größeren Einfluss auf die Parsoid-Seitenabrufe haben.
WE6.4.1	Wenn wir die Spliting-Links-Tabelle von Commons in ihrem eigenen Cluster bereitstellen, erhöhen wir die Chancen, dass das Wachstum der Datenbank für Commons nachhaltig bleibt.	T398709
WE6.4.2	Wenn wir (SRE) die MediaWiki-Entwicklungsteams unterstützen – indem wir Dokumentation erstellen, die notwendige Infrastruktur (z. B. PHP-Pakete, Container-Bilder) vorbereiten und Anleitungen und Überprüfung anbieten –, können sie beruhigt das PHP-8.3-Upgrade in der Produktion zum Start des zweiten Quartals starten.	T360995
WE6.4.3	Wenn wir für SSH-Logins von Benutzer:innen mit erweiterten Systemprivilegien einen physischen zweiten Faktor (Hardware-Sicherheitsschlüssel) verlangen, werden wir das Risiko verringern, dass ein kompromittierter Laptop zu einem schweren Sicherheitsverstoß führt.
WE6.4.4	Wenn wir unsere Domains vereinheitlichen, indem wir alle Seitenansichten der MediaWiki-Websites über eine kanonische Domain ausführen (Eliminierung der Weiterleitung auf die mobile Domain), dann werden wir die Plattformkomplexität und die Risiken hinsichtlich Search Engine Optimization (SEO) reduzieren. Die Fertigstellung wird durch die Verringerung der Weiterleitungen von mobilen Seitenansichten über kanonische Domains von 100 % auf 0 % gemessen.	T214998
WE6.4.5	Wenn das MediaWiki-Engineering-Team aktiv Probleme in MediaWiki im Zusammenhang mit dem PHP-8.3-Upgrade überwacht und behebt, kann das SRE-Team ab dem zweiten Quartal mit dem PHP-8.3-Upgrade fortfahren.	T360995

Hypothesen zu Signals & Data Services (SDS) [ SDS-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q1-Text	Einzelheiten und Diskussion
SDS1.1.1	Wenn wir die Wirksamkeit der automatisierten Beurteilungskriterien für Datenverkehr in unseren Pageviews-Datensätzen analysieren, können wir Datenqualitätsmetriken entwickeln, um deren Leistung zu beschreiben und die Notwendigkeit weiterer Investitionen in diese Beurteilungskriterien zu prüfen.
SDS1.2.2	Wenn wir den XML-Dumps-Prozess von der aktuellen „Dumps 1“-Infrastruktur zu einer Datenpipeline migrieren, die die MediaWiki-Inhaltspipelines nutzt, können wir SLOs garantieren und den „Dumps 1“-basierten XML-Export abschalten.
SDS1.2.3	Wenn wir einen Durchlauf machen und die SLOs für MediaWiki Content History und Event Platform / Event Gate überprüfen, können wir die Kundschaft, die Metriken und die abhängigen Stakeholder validieren und möglicherweise für die SLOs nötige Verbesserungen erkennen, was uns dabei helfen wird, Lücken in unseren wöchentlichen Lieferungsgarantien zu klären.
SDS2.1.1	Wenn wir eng mit Teams zusammenarbeiten, die Experimente durchführen, werden wir lernen, wie wir das System in Zukunft mehr zur Selbstbedienung ausbauen können, und welchen konzeptionellen oder technischen Herausforderungen sie möglicherweise begegnen.
SDS2.1.2	Wenn wir besseres Debugging für Eventlogging implementieren können, wissen die Produktteams, dass ihr Experiment Event-Daten wie erwartet aufzeichnet, was das Vertrauen der Experimenteigner:innen erhöht.
SDS2.1.3	Wenn wir Logging und Beobachtbarkeit für die A/B-Testsystem-Komponente (xLab) der Experimentierungsplattform und für die damit verbundenen MediaWiki-Teile verbessern, können wir Grundlinien für die Leistung des Systems festlegen und auf experimentbezogene Ausfälle reagieren.
SDS2.1.4	Wenn wir einmal im Monat Geschichten und Ergebnisse von Experimenten mit der gesamten Organisation teilen (durch Product-Ops-Treffen, Design-Team-Treffen und teamübergreifende Präsentationen), werden wir eine organische Nutzung der Experimentierungsplattform erreichen.
SDS2.1.5	Wenn wir den Benutzer:innen sagen, dass ihr Instrument, wenn es in xLab erstellt wird, eine Reihe von Attributen enthält, die die Risikokategorie verändern, werden wir Benutzer:innen der Instrumente davon abhalten, übermäßig Daten zu sammeln, und die Klarheit darüber erhöhen, welche Kombination von Attributen eine Überprüfung des Datenschutzes erfordert.

Hypothesen zu Future Audiences (FA) [ FA-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q1-Text	Einzelheiten und Diskussion
FA1.1.1	Wenn wir 1) Mediensammler:innen auf anderen Plattformen (wie Letterboxd, Goodreads und RateMyMusic) Möglichkeiten bieten, ihre Sammlungen mit exklusivem Wikipedia-Wissen zu verbessern, oder 2) diesen Mediensammler:innen interessante Inhalte zum Verbreiten in sozialen Medien anbieten, dann werden wir in der Lage sein, die Reichweite von Wikipedia außerhalb unserer Plattform zu vergrößern.
FA2.1.1	Wenn wir unsere interne Kapazität für die Erstellung kurzer Videoinhalte im ersten Quartal erhöhen (durch die Vergrößerung unserer Teams und die Prüfung und Identifizierung von Möglichkeiten, um die Effizienz in unserem aktuellen Produktionsprozess zu erhöhen), werden wir in der Lage sein, auf den Erfahrungen aus im Geschäftsjahr 2024/25 erstellten Inhalten aufzubauen und eine höhere jährliche Reichweite für im zweiten Quartal des Geschäftsjahrs 2025/26 erzeugte Inhalte zu erreichen.

Hypothesen zu Product and Engineering Support (PES) [ PES-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q1-Text	Einzelheiten und Diskussion
PES1.1.1	Wenn wir xLab, Charts und ToneCheck unterstützen, um Metriken für SLIs (Service Level Indicators) in Prometheus zu definieren, und diese Service Level Objectives (SLOs) auf Pyrra einführen, werden wir die Beschränkungen and Ausnahmefälle unserer Werkzeuge in verschiedenen komplexen Szenarien sehen sowie klären, welche Iterationen für die SLO-Vorlage benötigt werden, was uns helfen wird, die sechs geplanten SLOs für das Schlüsselergebnis besser zu unterstützen.
PES1.1.2	Wenn wir zwei Sätze von SLO-Benachrichtigungs-Dashboards testen, werden wir lernen, wie schwierig es wäre, geeignete Werkzeuge so umzusetzen, dass die Dienstanbieter ihre Verpflichtungen klar verstehen, und auch, ob wir zu einem anderen Werkzeug wechseln müssen, das nur eine einzelne Ansicht eines bestimmten SLOs bietet. Ein Dashboard ist für die vierteljährlichen Berichte (in denen das tatsächliche Service Level Agreement für das Fehlerbudget festgelegt ist) vorgesehen, und ein kleines dynamisches Dashboard (genannt „rolling“) wird für täglichen Betrieb und die Benachrichtigungen bestimmt sein.
PES1.1.3	Wenn wir die Abstract-Wikipedia-Gruppe bei der Erstellung eines SLOs (Service Level Objectives) für das Wikifunctions-Projekt unterstützen, lernen wir, wie wir eine Liste von SLO-Zielen (zusammen mit zugehörigen Service-Level-Indicator-Metriken) für eine komplexe Funktion definieren, die derzeit einem wichtigen User-Workflow hinzugefügt wird: der Darstellung von Wiki-Artikeln. Wir lernen auch, die damit verbundenen Fehlerbudgets richtig zu visualisieren und mit von SRE bereitgestellten Dashboards und Überblicken darüber zu benachrichtigen.
PES1.1.4	Wenn wir die Data-Platform-Gruppe bei der Überprüfung und Iteration der Service Level Objectives (SLO) für das MediaWiki-Content-History-Projekt unterstützen, lernen wir, wie SLOs zur Unterstützung der Dienst-Inhaberschaft genutzt werden können, wenn eine Kombination aus Batch- und Stream-Verarbeitungsdienste gemeinsam betrieben wird, um den Datensatz zu aktualisieren und ihn konsistent sowie für Downstream-Benutzer:innen verfügbar zu halten.
PES1.2.1	Wenn wir drei gezielte Verbesserungen der Wunschliste durchführen, werden wir 30 % mehr an der Wunschliste Teilnehmende erreichen.
PES1.2.2	Wenn wir eingehende Wünsche innerhalb von 72 Stunden prüfen und einem Maintainer (z. B. Produktmanager) zuweisen (einschließlich Ablehnung, Klärung, Kennzeichnung von Diensten ohne Maintainer usw.), indem wir neue Wünsche mit der Maintainer-Tabelle abgleichen und dem relevantesten Produktteam oder -manager eine „Maintainer-Kategorie“ zuweisen, werden Maintainer (z. B. Produktmanager) in der Lage sein, Wünsche in maximal 10 Tagen zu bewerten und zu beantworten.
PES1.2.3	Wenn wir Pilotprojekte zur Identifizierung von allgemeinen Community-Signalen durchführen, werden wir mehr Stimmen von Freiwilligen in unsere von der Community ausgehenden Priorisierungsbemühungen einbeziehen.
PES1.2.4	Wenn wir im ersten Quartal einen vierteljährlichen Wunsch- und Communitysignal-Überprüfungsprozess mit drei Teams als Pilotprojekt durchführen, werden wir die Produktmanager dazu anregen, Communitysignale in ihre vierteljährlichen und jährlichen Planungsprozesse zu integrieren.
PES1.3.1	Wenn wir bis zum Ende des ersten Quartals drei Sitzungen zur funktionellen Planung mit der Kommunikationsabteilung und den Produktteams koordinieren, um Außenkommunikation, kreative Bedürfnisse und Kampagnenzeitpläne für WP25-Initiativen zu koordinieren, werden wir kreative Unterlagen für alle drei Experimente der Kampagne (25YiR, Easter Eggs, WikiRun) bereitstellen.
PES1.3.2	Wenn wir ein Lenkungskomitee mit Vertreter:innen aus Design und Feature-Engineering zusammenstellen, können wir Grundmetriken für Beiträge zu Codex definieren: Bekanntheit, Nutzung, Qualität sowie Quantität der Beiträge. Die Erkenntnisse aus der Bewertung dieser Grundmetriken werden uns helfen, einen Fahrplan für Wachstum und Diversifizierung der Codex-Beitragendenbasis zu erstellen.

2. Quartal

Das zweite Quartal (Q2) des jährlichen WMF-Plans umfasst die Monate Oktober–Dezember.

Hypothesen zu Wiki Experiences (WE) [ WE-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q2-Text	Einzelheiten und Diskussion
WE1.1.1	Wenn wir einen vorgegebenen Satz führender Indikatoren ≥2 Wochen nach dem Start des A/B-Tests zum Einfügen-Check analysieren, können wir feststellen, welche – wenn überhaupt – Facetten der Enderfahrung angepasst oder untersucht werden müssen, bevor wir die Wirkung der Funktion mit Sicherheit bewerten können.
WE1.1.4	Wenn wir den Beleg-Check in en.wiki im Rahmen eines kontrollierten Experiments aktivieren, werden wir einen Anstieg um ≥ 4 % bei den konstruktiven Beiträgen, die neue(re) Freiwillige tätigen, beobachten und herausfinden, ob Moderator:innen und Kontrolleur:innen die Funktion ausreichend befürworten, um sie weitergehend zu aktivieren.
WE1.1.7	Wenn wir einen vorgegebenen Satz führender Indikatoren ≥2 Wochen nach dem Start des A/B-Tests zum Tone-Check analysieren, können wir feststellen, welche – wenn überhaupt – Facetten der Enderfahrung angepasst oder untersucht werden müssen, bevor wir die Wirkung der Funktion mit Sicherheit bewerten können.
WE1.1.8	Wenn wir das Tone-Check-Modell auf veröffentlichte Artikel anwenden, werden wir erfahren, ob wir die ≥ 10.000 Tonprobleme (mit einer Wahrscheinlichkeit von je 0,8 oder höher) identifizieren können, die erforderlich sind, um einen hochwertigen (Genauigkeit ≥ 70 %) Vorschlagspool zu erstellen, der Beitragenden bei der Verbesserung des Artikeltons hilft.
WE1.1.10	Wenn wir ≈ 10 erfahrene Freiwillige auf en.wiki und fr.wiki interviewen, die Missbrauchsfilter (und andere Helferlein/Skripte/Vorlagen/Bearbeitungsnachrichten) schreiben, um Kontroll-/Moderations-Workflows zu automatisieren, werden wir ≥ 3 Muster/Bedürfnisse identifizieren, die dazu beitragen werden, den Wert von Edit-Checks aus der Community zu erhöhen.
WE1.1.11	Wenn wir eine Umfrage an ≥ 500 erfolgreiche Neulinge [i] verteilen und hochwertige Daten erhalten, die für die breitere Gruppe erfolgreicher Neulinge repräsentativ sind, können wir ≥ 4 umsetzbare Erkenntnisse identifizieren, mit denen wir priorisieren können, welche Aspekte der Onboarding-Erfahrung verbessert werden sollen.
WE1.1.12	Wenn wir ≥ 3 Freiwilligen ermöglichen, jeweils ≥ 30 Probebearbeitungen zu bewerten, werden wir für jede der 10 neuen Sprachen, auf die wir Tone-Check ausdehnen wollen, erfahren, wie oft die Freiwilligen mit Modellvorhersagen übereinstimmen, und entscheiden können, auf welche neuen Wikis wir bezüglich der Bereitstellung von Tone-Check zugehen sollen.
WE1.1.13	Wenn wir „Link hinzufügen“ für 100 % der neuen Freiwilligen in der englischen Wikipedia bereitstellen, wird sich die konstruktive Aktivierung und Anbindung von Neulingen verbessern, was die konstruktiven Bearbeitungen durch neue Freiwillige um ≥ 4 % erhöhen wird.
WE1.2.3	Wenn wir die Voraussetzung beseitigen, dass jemand das Event-Organisator-Recht benötigt, um die Event-Registrierung in kleinen und mittleren Wikis zu nutzen, werden wir bis zum Ende des Geschäftsjahres mindestens X mehr erstellte Veranstaltungen* in kleinen und mittelgroßen Wikis beobachten können. * die Berechnung von Basis und Ziel ist noch ausständig.
WE1.2.4	Wenn wir das MVP „Collaborative Contributions“ mit mindestens zwei Verbesserungen überarbeiten, werden mehr Kollaborationen über Event-Registrierung erstellt werden.
WE1.2.5	Wenn wir Anfang des zweiten Quartals eine Anwendungsstrategie für die Event-Registrierung auf Wikimedia Commons festlegen, können wir sie mit Organisator:innen von mindestens einer großen Kampagne testen und 5 lokale Organisator:innen in die Lage versetzen, die Funktion zu nutzen.
WE1.3.3	Wenn wir ein Experiment starten, um neueren Beitragenden ein Moderationsdashboard anzuzeigen, werden 10 % der Beitragenden, die es besuchen, dies zwei Wochen in Folge tun.
WE1.4.1	Wenn wir die in T396489 festgelegten Verbesserungen vornehmen, werden wir langsame Letzte-Änderungen-Anfragen um mindestens 30 % in großen Wikis reduzieren, wodurch Community Tech Watchlist Labels einführen kann, ohne die Datenbank der letzten Änderungen zu überlasten.
WE1.4.3	Wenn wir die letzten Änderungen und die Beobachtungsliste instrumentalisieren, können wir einen Grundwert für die Häufigkeit der Klicks auf Seiten definieren.
WE1.5.1	Wenn wir ein Dashboard einführen, um 7 Beitragsmetriken zu erforschen und die Berechnung von mindestens einer Metrik mit dbt zu standardisieren, können wir Produktteams für Beitragende ermöglichen, Metriken selbst bereitzustellen und einen Standard für die Speicherung der Berechnungslogik für Metriken zu entwickeln.
WE1.5.2	Wenn wir in Q2 feststellen, welche Moderationsmaßnahmen in die Definition von Moderator:innen einfließen sollen, dann kann das Movement-Insights-Team die Metrik der monatlich aktiven Moderator:innen in Q3 und Q4 erstellen.
WE2.1.3	Wenn wir mehr über die Erfahrung von Beitragenden bei der Erstellung neuer Artikel und Abschnitte erfahren (einschließlich Motivationen, Schwierigkeiten und Reaktionen auf neue Ideen, sie besser zu unterstützen), werden wir Bedürfnisse und Verhaltensweisen der Benutzer:innen entdecken, die umsetzbare Einblicke und Strategien für Produkt, Design und Entwicklung zur Verbesserung der Erfahrung bei der Artikelerstellung bieten.
WE2.2.12	Wenn wir Wikifunctions in Wikis einführen, in denen Parsoid aktiviert ist, können wir weiterhin testen, ob das System bei immer breiteren Einführungen leistungsfähig und nutzbar bleibt.
WE2.2.13	Wenn wir die Verfügbarkeit der Konjugationstabellen-Funktionen innerhalb der Wiktionary-Community bekannt machen, erhalten wir wertvolle Rückmeldungen zur Funktionsnutzung und Einblicke in unsere Benutzerpersönlichkeiten, die wir bei zukünftigen Einführungen berücksichtigen können.
WE2.2.14	Wenn wir uns die Databox-Arbeit der Community anhand der Verwendung von Wikidata in Infoboxen anschauen und untersuchen, ob Wikifunctions hier helfen könnte, können wir ein erstes Experiment für Wikifunctions in Infoboxen identifizieren.
WE2.2.15	Wenn wir ein Bewusstsein der Community für die Möglichkeit schaffen, Fehlermeldungen in Wikifunctions zu erstellen und zu übersetzen, werden wir eine Zunahme der Anzahl hilfreicher Fehlermeldungen feststellen.
WE2.2.16	Wenn wir der Community verfügbare semantische Funktionen aufzeigen, werden wir eine Steigerung der grammatikalischen Funktionen um 50 % feststellen.
WE2.2.17	Wenn wir eine maßgeschneiderte Komponente zur Anzeige von Wikidata-Aussagen auf Wikifunctions bereitstellen, werden Benutzer:innen Daten, die von Wikidata bezogen wurden, besser verstehen und sich weniger überwältigt fühlen.
WE2.2.18	Wenn wir zehnfache Speicherverbrauchsspitzen verhindern können, kann der Orchestrierer Wikidata-Objekte besser verarbeiten und unterstützt so den Nutzen von Wikifunctions als Plattform für die Abstrakte Wikipedia.
WE2.2.19	Wenn wir Benutzer:innen die Möglichkeit geben, direkte Links zu bestimmten Funktionsaufrufen zu teilen – einschließlich ihrer Eingaben –, können die Beitragenden Funktionsverhalten leichter reproduzieren, überprüfen und diskutieren, was wiederum die Fehlersuche beschleunigt, die Test-Workflows verbessert und gemeinschaftliche Problemlösung in der Wikifunctions-Community unterstützt.
WE2.3.1	Wenn wir die Entscheidung zur Erstellung eines neuen Wikis abschließen und uns gemeinsam mit der Community auf einen Namen einigen, können wir die Erstellung dieses neuen Wikis unseren Interessenvertretern umfassender bekannt machen und uns auf die Logistik einer möglichen Produktnamensänderung vorbereiten.
WE2.3.2	Wenn wir ein MVP für einen Prototyp des Abstrakten Wikis definieren, das die größtmögliche Erfahrung zum Testen unserer Back-End- und NLG-Funktionen enthält und uns ein iteratives Design ermöglicht, können wir im dritten Quartal einen Live-Prototyp planen und starten.
WE2.3.3	Wenn wir mit der Community sprechen und mögliche Entwürfe für die Benutzungserfahrung eines Abstrakten Wikis erforschen, können wir die Arbeit im dritten Quartal weiterführen.
WE2.4.1	Wenn wir Wikidata- und WDQS-Anwendungsfälle von WMDE- und WMF-Teams sammeln, können wir Produktanforderungen für Infrastrukturverbesserungen definieren.
WE2.4.2	Wenn wir eine zusammengefasste Berichtsübersicht über wichtige Leistungsindikatoren (KPI) mit bestehenden Servicelevel-Zielsetzungen (SLOs) für Wikidata und WDQS erstellen, können wir Erfolgskriterien für Verbesserungen der technischen Infrastruktur, die den kritischen Wikidata-Nutzungsfall unterstützen, formulieren und verfolgen.
WE2.4.3	Wenn wir innerhalb des Quartals alternative Datenbanken für Blazegraph mittels realistischer Produktionskriterien bewerten und vergleichen können, können wir eine datenbasierte Migrationsentscheidung treffen und eine konkrete Roadmap mit Zeitplan und Ressourcenanforderungen erstellen.
WE3.1.1	Wenn wir einen A/B-Test einer verbesserten Version der Tabbed-Browsing-Funktion durchführen, werden wir eine 5%ige Zunahme der mehrtägigen Nutzung unter Tabs-Benutzer:innen beobachten.
WE3.1.3	Wenn wir den Benutzer:innen eine neue Möglichkeit bieten, durch relevante Bildinhalte in Artikelseiten zu navigieren, und dies mit einer Untergruppe von nicht angemeldeten Lesenden über einen A/B-Test in einer Reihe von Wikis testen, werden wir eine Klickrate von mindestens 3 % bei Benutzer:innen beobachten, denen diese Funktion angeboten wird.
WE3.1.4	Wenn wir den Lesenden mehrere Konzepte für das Durchqueren des Wissensnetzes in den Wikis zeigen, werden wir eine priorisierte Liste von Konzepten für weitere Entwicklung erhalten.
WE3.1.5	Wenn wir Lesenden im Browser die Möglichkeit geben, eine maschinell übersetzte Version von Wikipedia-Inhalten, die nicht in ihrer Sprache verfügbar sind, anzuzeigen, werden wir erfahren, ob die Leseaktivität erhöht wird, gemessen als 3%iger Anstieg der Seiteninteraktionen, wodurch Lesende zum Wiki in der lokalen Sprache gelenkt werden, mit einem potenziellen Anstieg in der lokalen Bearbeitungsaktivität. Dies wird als kontrollierter A/B-Test für maximal 6 Monate in 13 Wikipedia-Sprachversionen mit vorheriger Zustimmung bereitgestellt, unter Verwendung offener maschineller Übersetzungsdienste, die bereits für Wikipedia-Beitragende verfügbar sind.
WE3.1.6	Wenn wir einen Prototyp für semantische Suche und Q&A im Artikel erstellen, der als Demo-Schnittstelle geliefert wird, die dem aktuellen Ansatz neue explorative Ansätze gegenüberstellt, können die Lese-Teams qualitativ auswerten, wie jeder Ansatz in verschiedenen Benutzererfahrungen funktioniert, und Lücken oder Chancen für die weitere Entwicklung aufzeigen.
WE3.1.7	Wenn wir die bestehende Forschung über die Art und Weise, wie Lesende mit Such- und Navigationswerkzeugen auf Wikipedia interagieren, und wie sie externe Suche verwenden, um Wissen auf Wikipedia zu finden, sichten, können wir den Lese-Teams ≥ 3 umsetzbare Empfehlungen und Ergebnisse liefern, die ihnen helfen, ein Such- und Entdeckungs-MVP zu erarbeiten, um auf Lücken in den Erwartungen und Bedürfnissen der Lesenden zu reagieren.
WE3.1.8	Wenn wir 2 semantische Suchprototypen (natürliche Sprache, Q&A) mit externen Teilnehmenden bewerten, können wir herausfinden, ob Benutzer:innen verbesserte Suchwerkzeuge nützlich finden, und den Lese-Teams eine Empfehlung darüber geben, wie sie mit einem Such- und Entdeckungs-MVP weiterarbeiten können.
WE3.1.9	Wenn wir 10–20 gelegentlichen Wikipedia-Lesenden in einer qualitativen Studie erstklassige Designkonzepte für die Inhaltsentdeckung durch semantische Suche vorführen, werden wir ein positives Gefühl für die Funktion beobachten und das Vertrauen schaffen, das notwendig ist, um mit einem Such- und Entdeckungs-MVP fortzufahren, das auf kurzen, von Menschen geschriebenen Auszügen für Suchanfragen beruht.
WE3.1.10	Wenn wir 10 gelegentlichen Lesenden einen Live-Prototyp der neuen Bildernavigations-Erfahrung in einer unmoderierten Benutzerstudie zeigen, werden wir mindestens eine UX-Verbesserung für zukünftige Weiterentwicklungen der Funktion finden.
WE3.1.11	Wenn wir die Übereinstimmung von Suchbegriffen in der Suche lockern, unterstützen wir Suchanfragen in natürlicher Sprache besser und ermöglichen es den Produkt-Teams, diese Funktionalität zu bewerten und sie in die Art und Weise einzubeziehen, wie sie die Arbeit im Bereich der semantischen Suche gestalten, priorisieren und umsetzen.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	Wenn wir eine Jahresrückblicks-Funktion auf Android einführen, die die Wirkung von Benutzer:innen hervorhebt und integrierte Spende-Nachrichten enthält, werden wir ein neues Spendenverhalten anregen – und wir werden eine Steigerung im App-Menü um 5 % im Vergleich zu 2024 sehen.
WE3.2.6	Wenn wir die Spende-Nachrichten im iOS-Jahresrückblick weiter integrieren und personalisieren, werden wir einen Anstieg der Spenden um 5 % im Vergleich zu 2024 sehen.
WE3.3.3	Wenn wir in der Android-App mindestens einen freischaltbaren Avatar für Kontoinhaber einführen, der durch sinnvolle Lese-Tätigkeiten wie die Speicherung einer bestimmten Anzahl von Artikeln verdient werden kann, erhöhen wir die Wiederholung dieser Tätigkeit durch angemeldete Benutzer:innen um 10 %, gemessen über mehrere Tage.
WE3.3.4	Wenn wir angemeldeten Lesenden die Möglichkeit geben, Artikel in einer privaten Leseliste zu speichern, erwarten wir eine Steigerung des Engagements auf der Website, gemessen an einem Anstieg des internen Referral-Verkehrs von 5 % für Lesende, die die Funktion verwenden, und eine statistisch signifikanten Anstieg für alle Benutzer:innen.
WE3.3.6	Wenn wir Rückschlussdaten zu Artikelthemen über einen Dienst zur Verfügung stellen, der die vereinbarten Skalierbarkeits- und Verfügbarkeitsanforderungen erfüllt, sowie alle notwendigen Daten-Füllmaterialien, dann haben wir die technischen Grundlagen geschaffen, die notwendig sind, um zukünftige personalisierte Lese-Erfahrungen zu unterstützen, die von diesen Daten abhängen.
WE3.3.7	Wenn wir die Verarbeitungskapazitäten der Datenplattform nutzen, um maßgeschneiderte Metriken zu Beitragenden und Wirkungsdaten zu aggregieren und die aggregierten Daten durch geeignete Dienste mit definierten SLOs anzubieten, können wir zukünftige Weiterentwicklungen des Jahresrückblickes WE3.3.1 des Aktivitäts-Tabs WE3.3.2 verbessern.
WE3.3.9	Wenn wir den Jahresrückblick auf Android veröffentlichen und A/B-Tests durchführen, bei denen engagierten Benutzer:innen als Belohnung angeboten wird, eine benutzerdefinierte Leseliste zu speichern, werden wir eine Steigerung der gesamten Anbindungsrate in der App bei den Lesenden beobachten, denen die Belohnung angeboten wurde, verglichen mit denen, bei denen dies nicht der Fall war.
WE3.3.10	Wenn wir A/B-Tests durchführen, bei denen ein Konto benötigt wird, um die personalisierten Leseinformationen des Jahresrückblicks zu sehen, werden wir eine Erhöhung der Gesamtanbindungsrate von 1 % für Benutzer:innen beobachten, die ein Konto benötigten, verglichen mit denen, bei denen dies nicht der Fall war.
WE3.3.11	Wenn wir eine verbesserte Version des „Aktivitäts“-Tabs in iOS testen, die Lesen, Bearbeiten und andere Beteiligungsverhalten hervorhebt, werden wir einen Anstieg von 5 % in den mehrtägigen Besuchen von angemeldeten Lesenden des Tabs im Vergleich zur Prototypenversion beobachten.
WE3.4.1	Wenn wir auf eine hybride PoP/CDN-Freischaltung hinarbeiten, können wir sowohl volle PoPs als auch Mini-PoPs (physisch und in der Cloud) als notwendig vorbringen und so die Grundlage für einen Prototyp für eine Mini-PoP-Aktivierung in der Zukunft legen.
WE3.5.1	Wenn Produkt und Technologie und Fundraising gemeinsam technische Ansätze zur Identifizierung von Spendenden innerhalb unserer Plattformen auswerten und dokumentieren, können wir eine kurz- und langfristige Lösung empfehlen, die Privatsphäre, Machbarkeit und Wirkung gleichermaßen berücksichtigt. Dieses gemeinsame Verständnis wird dazu beitragen, die Entscheidungsfindung anzupassen, die durchgängige Erkennung von Spendenden auf allen Plattformen zu ermöglichen, sowie gezielte Experimente von zukünftigen Funktionen im Zusammenhang mit der Sammlung von Geldern durchzuführen.
WE3.6.3	Wenn wir die Communitys in Gespräche über die sich entwickelnden Bedürfnisse der Lesenden und über die sich verändernde Natur des Wissens im Internet einbeziehen, können wir einen gemeinsamen Fokus darauf entwickeln, wie wir den Lesenden entgegenkommen und gemeinsam daran arbeiten können, ob und wie wir unsere verschiedenen Ideen testen können (einschließlich jener rund um Multimedia, Suche und Entdeckung und maschinelles Lernen).
WE3.6.4	Wenn wir die unterschiedlichen Motivationen, Verhaltensweisen und Bedürfnisse dahinter untersuchen, wann, warum und wie Lesende Wikipedia und andere Wissensplattformen nutzen, können wir Prioritätsbereiche und spezifische Initiativen für die Konsumierendenstrategie vorschlagen.
WE3.6.5	Wenn Produkt und Technologie und Fundraising zusammen an einer gemeinsamen Strategie arbeiten, um Spendenchancen auf der Plattform zu diversifizieren und die Lesenden, die spenden, zu lenken und zu erkennen, werden wir klare, abgestimmte Ziele und Metriken festlegen, die mit unseren Strategien für Konsumierende und für das Fundraising verbunden sind.
WE3.6.6	Wenn wir eine einheitliche Messstrategie entwickeln, werden wir die Bewertung der mehrjährigen Strategie für Konsumierende ermöglichen und einen Fahrplan für die Entwicklung von Metriken und die Berichterstattung definieren.
WE4.1.1	Wenn wir einen Prototyp für einen minimal lebensfähigen Flow abseits von Notfällen entwickeln und dabei ein wiederholtes Rückmeldungsverfahren offen halten, während wir ihn mit Benutzer:innen mit erweiterten Rechten entwickeln, dann unterstützen diese Gruppen die weitere Bereitstellung dieses Flows.
WE4.1.3	Wenn wir bis Ende Oktober 7 Wikipedias (Französisch, Deutsch, Spanisch, Ungarisch, Italienisch, Polnisch, Portugiesisch) aktualisieren, werden wir die Phase 1 der Einführung des neuen Fußtexts als Reaktion auf die Anforderungen des DSA abschließen.
WE4.1.4	Wenn wir das MVP für das Meldesytem für Zwischenfälle in mindestens 15 Wikis bereitstellen, wobei der Fokus auf größeren, komplexen Communitys liegt, werden wir beobachten, dass er von der Gemeinschaft wie beabsichtigt verwendet wird, und ein funktionierendes Modell für ein Meldesystem abseits von Notfällen demonstriert haben.
WE4.1.5	Wenn wir ein Flow-Diagramm für die Meldung von Missbrauchsanzeichen in Wikis ohne etablierte Missbrauchsbehandlungsprozesse erstellen, wird dies die Einführung des Meldesystems für Zwischenfälle in solchen Wikis fördern und den Benutzer:innen dieser Wikis eine klare und gangbare Unterstützungsmöglichkeit bieten.
WE4.2.3	Wenn wir Daten aus dem hCaptcha-Kontenerstellungsversuch analysieren, werden wir den Pfad der Kontenerstellung sowie die Wirksamkeit der hCaptcha-Puzzles und -Scores verstehen und die Daten erhalten, die notwendig sind, um die weitere Einführung von hCaptcha bei Kontenerstellung zu untermauern.
WE4.2.5	Wenn wir Forschung durchführen, uns mit Communitys austauschen und technische Lösungen untersuchen, werden wir in der Lage sein, eine Reihe von strukturierten Sperrgründen zu definieren, die in allen WMF-Wikis verwendet werden können.
WE4.2.6	Wenn wir die Fähigkeit entwickeln, auf der Datenplattform OpenSearch-basierte Cluster zu implementieren, werden die Entwicklerteams für Produktfunktionen in der Lage sein, Systeme zu entwickeln, die diese Fähigkeit integrieren, mit einer großen Autonomie, Resilienz und Isolation von anderen suchbasierten Systemen. Der erste und wichtigste Nutzer dieses Systems wird der IPoid-Dienst sein.
WE4.2.7	Wenn wir die Integration von hCaptcha Enterprise in mehreren produktiven Wikipedias als Pilotversuch aktivieren, können wir Daten über die Wirksamkeit und den Wert von hCaptcha Enterprise in Bezug auf Missbrauchsbekämpfung, Bot-Erkennung, Benutzungsfreundlichkeit und Barrierefreiheit sammeln.
WE4.2.8	Wenn wir den hCaptcha-Proxy einsatzbereit machen, indem wir seine Verfügbarkeit und Beobachtbarkeit verbessern, werden wir in Q1 einen stabileren und zuverlässigeren Dienst für aktive Wikipedias anbieten.
WE4.2.9	Wenn wir das hCaptcha-SDK in die nativen mobilen Apps integrieren, die native App-Benutzungserfahrung bewerten und prüfen, ob hCaptcha-Überprüfungen als Teil der Kontenerstellungs-API aktiviert werden können, werden wir genug Erkenntnisse haben, um die weitere Einführung von hCaptcha für die Kontenerstellungs-API anzuleiten.
WE4.2.11	Wenn wir hCaptcha für die Erkennung von Bots in Szenarien mit Bearbeitungen höheren Risikos aktivieren, werden wir beobachten, dass hCaptcha automatisierten Missbrauch reduzieren kann.
WE4.2.16	Wenn wir uns mit den zuständigen WMF-Teams beraten, werden wir in der Lage sein, einen gemeinsamen Plan zu entwickeln, um einen punktuelleren Zugriff der Benutzer:innen auf nichtöffentliche Daten zu verwalten und die Einführung von nichtöffentlichen defensiven Softwareregeln zu unterstützen.
WE4.2.17	Wenn wir reale Beispiele analysieren und CheckUser interviewen, um mindestens 2 Signale potenziell missbräuchlichen Verhaltens aus dem Prototyp für Benutzerbeiträge zu identifizieren, kann das Produktsicherheits- und Integritätsteam diese Signale später in die Funktion „Suggested Investigations“ einbeziehen, mit einem größeren Vertrauen darauf, dass die Signale nützlich sind.
WE4.3.2	Wenn wir JA4H-Fingerabdrücke einsetzen, die das HTTP-Client-Verhalten zusammenfassen, werden wir besser in der Lage sein, den Bot-Traffic zu identifizieren und zu kategorisieren.
WE4.4.1	Wenn wir auf Basis von Rückmeldungen zu den Pilotläufen Verbesserungen vornehmen und temporäre Konten in allen Projekten aktivieren können, werden wir in der Lage sein, die Sichtbarkeit personenbezogener Daten (IP-Adressen) nicht angemeldeter Benutzer:innen in allen unseren Projekten so zu schützen, dass sie weniger als 0,1 % aller (registrierten) Benutzer:innen zur Verfügung stehen.
WE4.4.2	Wenn wir mit den relevanten Interessenvertreter des Movements (einschließlich Wiki-Communitys und globaler Funktionäre) klar und pünktlich kommunizieren, können wir die Aktivierung in allen verbleibenden Wikis vornehmen, die kurzfristig anfallende Arbeit reduzieren und allfällige Zurücksetzungen vermeiden.
WE4.4.5	Wenn wir Hindernisse für Kontrolleur:innen reduzieren, um böswillige Akteure zu identifizieren, die temporäre Konten verwenden, um zu vandalieren, werden wir eine Zunahme des Vandalismus verhindern können und keine Zunahme der Zurücksetzungsquote in allen Wikis mit temporären Konten feststellen.
WE4.4.6	Wenn wir die LiquidThreads-Erweiterung aufgeben, werden wir temporäre Konten für alle Projekte, die diese Erweiterung nutzen, ermöglichen.
WE4.6.1	Wenn wir den Synchronisierungsprozess für Konten innerhalb von Zendesk für Passwortzurücksetzungen automatisieren, wird dies die Belastung von T&S verringern und es ihnen ermöglichen, mehr eingehende 2FA-Zurücksetzungsanfragen zu behandeln.
WE4.6.3	Wenn wir allen Benutzer:innen mit einer bestätigten E-Mail-Adresse erlauben, 2FA für ihre Konten zu aktivieren, ihnen diese Änderung aber nicht aktiv kommunizieren, bleibt die Belastung unserer Kontenwiederherstellungsunterstützung auf einem nachhaltigen Niveau.
WE4.6.4	Wenn wir unsere Benutzererfahrung des 2FA-Systems weiter überarbeiten und Unterstützung für Passkeys hinzufügen, werden mehr Benutzer:innen sich mit mehreren Authentifizierungsfaktoren registrieren und so besser vor dem Verlust des Kontozugangs geschützt sein.
WE4.6.5	Wenn wir einen allgemeinen Rahmen für die Festlegung von Anforderungen, die die Mitglieder einer lokalen oder globalen Gruppe erfüllen müssen, erarbeiten und erstellen, werden wir diesen Rahmen nutzen, um die Einhaltung der geltenden Anforderungen für Mitglieder der Gruppe IP-Betrachter temporärer Konten durchzusetzen.
WE4.6.6	Wenn wir untersuchen, wie sehr Benutzer:innen mit erweiterten Rechten (UWER) auf Benutzerskripte angewiesen sind, können wir einen Plan vorschlagen, den die UWER-Community unterstützen könnte, um einen oder mehrere größere technische Eingriffe vorzunehmen, die das System von Benutzerskripten sinnvoll absichern würden.
WE4.6.7	Wenn wir die Benutzererfahrung und die technischen Änderungen bewerten, die erforderlich sind, um die Anmeldeerfahrung der nativen mobilen Apps an jene der Webplattform anzugleichen, durch das Erkunden alternativer Mechanismen wie OAuth, können wir die Machbarkeit der Integration ermitteln, um Benutzer:innen eine sicherere und konsistentere Erfahrung zu bieten.
WE4.6.8	Wenn wir die Auswirkungen der Zendesk- und MediaWiki-Formulare im Auge behalten, die wir im ersten Quartal erstellt haben, können wir technische Eingriffe für zukünftige Quartale vorschlagen, die den Rest des Kontowiederherstellungsverfahrens besser automatisieren.
WE5.1.2b	Wenn wir mehrere Methoden zur Identifizierung und Authentifizierung von Entwickler:innen ins API-Gateway integrieren, können wir jeder Anfrage eine angemessene Limitierung der Raten zuweisen, indem wir Anfragen, die von verschiedenen Benutzergruppen stammen, korrekt identifizieren.
WE5.1.3b	Wenn wir einen Probelauf für eine Limitierung der Zugriffsrate auf mindestens 3 Routen des REST-Gateways durchführen, können wir die Machbarkeit der Ratenlimitierung in Bezug auf den Ressourcenverbrauch überprüfen und eine erste Reihe von Limitierungen festlegen, die mit minimalem Effekt für Benutzer:innen durchgesetzt werden können.
WE5.1.4b	Wenn wir die vorgeschlagenen API-Mechanismen zur Benutzersegmentierung mit breiteren Datensätzen und manuellen Überprüfungen der identifizierten Gruppen validieren, können wir die Benutzergruppen finalisieren, die Berechnungsmethoden verfeinern und ihre Wirksamkeit besser verstehen.
WE5.1.5	Wenn wir mit dem MediaWiki-Plattform-Team zur Traffic-Identifizierung und Ratenlimitierung zusammenarbeiten, werden wir in der Lage sein, Ratenlimitierung für Testläufe in der Produktion zu aktivieren, indem wir das Plattform-Team bei der Erstellung und Ausführung dieser Funktionalität unterstützen.
WE5.2.1b	Wenn wir uns mit potenziellen Benutzer:innen des neuen REST-API-Explorers austauschen, wird uns dies helfen, wichtige Erkenntnisse zur Nutzbarkeit zu gewinnen, die aufzeigen, ob das neue Design einfach zu bedienen ist und mit den Vorstellungen der Entwickler:innen übereinstimmt.
WE5.2.2b	Wenn wir die Action-API durch das zentrale API-Gateway lenken, können wir damit beginnen, Datenverkehr und Nutzungsmuster konsequent zu messen, um Einblicke zu gewinnen, die zukünftige Entscheidungen und Aktionen anleiten werden.
WE5.2.4	Wenn wir Standarddokumentationsmuster für 2 APIs implementieren, können wir die Inhaltsrichtlinien verfeinern, verstehen, was API-Owner benötigen, um die Richtlinien anzuwenden, und die erforderlichen Anstrengungen zur Implementierung der Richtlinien in den verbleibenden Wikimedia-API-Dokumentationen quantifizieren.
WE5.2.5	Wenn wir mit der Definition und Anwendung von OpenAPI-Spezifikationsregeln für die MediaWiki-REST-APIs experimentieren, werden wir ein Mittel zur programmatischen Durchsetzung von API-Gestaltungsrichtlinien demonstrieren, um die Qualität und Konsistenz von APIs zu verbessern, die in Wikimedia und unseren Communitys veröffentlicht werden.
WE5.3.1	Wenn wir die UX-Attributionsrichtlinien erweitern und optimieren und gleichzeitig bestehende Richtlinien aktualisieren, werden wir eine Reihe von zentralen verbesserten Richtlinien erstellen, die intern getestet und schrittweise verfeinert werden können, um sie für eine breitere öffentliche Nutzung vorzubereiten.
WE5.3.1b	Wenn wir den Entwurf der UX-Leitlinien und -Demos veröffentlichen und weiterentwickeln, werden wir einen zentralen Rahmen erstellen, der intern getestet und schrittweise verfeinert werden kann, um ihn für eine breitere öffentliche Nutzung vorzubereiten.
WE5.3.2	Wenn wir einen Pitch erstellen, der Drittanbieter-Weiternutzern von Inhalten und deren Endnutzern die Vorteile der Namensnennung von Wikipedia zeigt, können wir WME4.1 und WME4.2 unterstützen, indem wir erreichen, dass mindestens ein weiterer Weiternutzungspartner zustimmt, bis zum Ende des ersten Quartals in einer Namensnennungsstudie oder -demo aufzutauchen.
WE5.4.2b	Wenn wir eine skalierbare Möglichkeit schaffen, bekannte Clients zu identifizieren, können wir Ausnahmen von allgemeinen Ratenlimitierungsgrenzwerten für Bots mit verifiziertem Ursprung erlauben und zu einer systematischen Durchsetzung unserer Regeln übergehen.
WE5.4.5	Wenn wir mit der Durchsetzung von Ratenlimitierungen beginnen, die auf verschiedene Klassen einzelner Clients zugeschnitten sind, werden wir die Belastung unserer Infrastruktur durch Crawling reduzieren.
WE5.4.6	Wenn wir bis zum Ende von Q2 die Top-N-Spiders als bekannte Bots klassifiziert haben, können wir die Menge an Ressourcen, die sie verwenden, begrenzen.
WE5.4.7	Wenn wir uns auf einen standardisierten Satz von zulässigen Größen für Miniaturbilder in unserer Medieninfrastruktur einigen und die „teuersten“ vorab generieren, während wir die Rate der Erzeugung verschiedener Bildgrößen begrenzen, werden wir die Belastung der Infrastruktur zur Medienbereitstellung reduzieren.
WE6.1.2	Wenn wir Wikifarms zu einem Pre-Merge-Testumfeld hinzufügen, ermöglicht es dies Entwicklungsteams, die abweichend von der Produktionsumgebung entwickeln und die mehrere Wikis benötigen, ihre Patches isoliert zu testen, was ihnen mehr Vertrauen vor der Produktion gibt und zu weniger Fehlern führt.
WE6.2.1	Wenn wir unsere Checkliste zur Produktionsbereitschaft überprüfen und veröffentlichen, in der die Voraussetzungen für einen als produktionsreif betrachteten Dienst sowie selbstbedienbare Aufgaben klar definiert werden, werden wir die Erwartungen von SREs und Entwicklungsteams angleichen und unsere Gesamtbetriebseffizienz und Skalierbarkeit verbessern.
WE6.2.2	Wenn wir die Erstellung einer Golang- und Nodejs-Bibliothek ankündigen, die viele mühsame Aufgaben für Entwickler:innen abstrahiert, werden sie mit Feedback und Interesse reagieren.
WE6.2.4	Wenn wir die Datenpersistenz-Designüberprüfung anwenden und aktiv unterstützen, können wir sichere Wege zur Produktion identifizieren.
WE6.3.2	Wenn wir neue Metriken entwickeln, die Cache-Infrastruktur von Parsoid verbessern und die Aktivierung in zwei Top-10-Wikipedias vornehmen, werden wir Leistungskriterien für den Vertrauensrahmen entwickeln, der dazu beitragen wird, unsere Bereitschaft für die Aktivierung in anderen großen Wikis zu validieren, und unsere Fähigkeit zu demonstrieren, zunehmende Trafficvolumen zu handhaben.
WE6.3.3	Wenn wir kritische Verbesserungen der Unterstützung von Sprachvarianten umsetzen und Parsoid in Q2 erfolgreich in mindestens drei Wikis mit Sprachvarianten bereitstellen, werden wir die wichtigsten technischen Herausforderungen identifizieren und lösen, damit wir Parsoid in allen verbleibenden Prachvarianten-Wikis zuversichtlich aktivieren können.
WE6.4.6	Wenn SRE die MediaWiki-Engineering-Teams unterstützt – durch Kapazitäts- und Trafficmanagement, Vorbereitung und Überprüfung von Konfigurationsänderungen und Zusammenarbeit zur Problemprüfung und Fehlerbehebung –, werden wir gemeinsam das PHP-8.3-Upgrade der Produktionsumgebung im zweiten Quartal abschließen und eine Reihe von Empfehlungen dokumentieren, um die kritischen Abhängigkeiten von SRE für zukünftige Upgrades zu minimieren.	T360995
WE6.4.7	Wenn wir mindestens 90 % aller Benutzer:innen mit globalem Root-Zugriff auf einen hardwaregestützten SSH-Schlüssel für den Zugriff auf die Wikimedia-Produktionsserver umstellen, werden wir das Risiko reduzieren, dass ein kompromittierter Laptop zu einer schweren Sicherheitslücke führt.
WE6.4.8	Wenn das MediaWiki-Engineering-Team aktiv Probleme in MediaWiki im Zusammenhang mit dem PHP-Upgrade überwacht und behebt, kann das SRE-Team das PHP-8.3-Upgrade der Produktionsumgebung bis November 2025 abschließen.	T360995

Hypothesen zu Signals & Data Services (SDS) [ SDS-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q2-Text	Einzelheiten und Diskussion
SDS1.2.1	Wenn wir den XML-Dumps-Prozess von der aktuellen „Dumps 1“-Infrastruktur zu einer Datenpipeline migrieren, die die MediaWiki-Inhaltspipelines nutzt, können wir SLOs garantieren und den „Dumps 1“-basierten XML-Export abschalten.
SDS1.2.2	Wenn wir einen Durchlauf machen und die SLOs für MediaWiki Content History und Event-Platform / Event-Gate überprüfen, können wir die Kunden, Metriken und abhängige Stakeholder validieren und Verbesserungen der SLOs bestimmen, die erforderlich sein könnten, um uns zu helfen, Lücken in unseren wöchentlichen Liefergarantien zu klären.
SDS1.3.1	Wenn wir clientseitige Signale einführen und im Vergleich mit den serverseitigen Webrequest-Logs prüfen, werden wir zusätzliche Bot-Muster finden, die beschrieben werden können.
SDS1.3.2	Wenn wir die aktuelle Verteilung von Bots und Menschen als Grundlage nehmen und automatisierte Warnungen für Veränderungen in dieser Verteilung erstellen, werden wir die Erkennungszeit des nächsten unvorhergesehenen Musters automatisierten Datenverkehrs von Wochen auf Minuten verringern.
SDS1.3.3	Wenn wir den Auffüllmechanismus für Webanfragen automatisieren und in den Logbüchern für Mai verwenden, werden wir die Reaktionszeit bei zukünftigen Zwischenfällen von Monaten auf Tage verringern und den Zwischenfall des Anstieges der Seitenabrufe im Mai lösen.
SDS1.3.4	Wenn wir einen regelmäßigen, operationellen internen Prüfungsprozess für die Ergebnisse von Bot-Klassifizierungen entwickeln, werden wir Vertrauen in unsere Lösungen schaffen und Veränderungen in den Traffic-Mustern, die nicht automatisch erkannt werden, vorhersehen.
SDS1.3.5	Wenn wir das clientseitige Grundsignal analysieren und in unsere Beurteilungskriterien einbeziehen, werden wir zusätzliche Bot-Muster in der Datenplattform erkennen.
SDS1.3.6	Wenn wir die Spur.us-IP-Reputation importieren, analysieren und in unsere Beurteilungskriterien integrieren, werden wir zusätzliche Bot-Muster in der Datenplattform erkennen.
SDS1.3.7	Wenn wir ein Randsignal importieren, analysieren und in unsere Beurteilungskriterien einbeziehen, werden wir zusätzliche Bot-Muster in der Datenplattform erkennen.
SDS1.4.1	Wenn wir die bestehende Trendanalyse innerhalb des Wikimedia-Ökosystems – Seitenansichten, Messungen von Beitragenden und Lesenden, Datenverkehr usw. – erneut bestätigen, können wir mit Zuversicht wichtige Diskussionspunkte für unsere wichtigsten Erkenntnisse zum Movement unterstützen.
SDS1.4.2	Wenn wir die bestehende Trendanalyse innerhalb des Wikimedia-Ökosystems – Seitenansichten, Messungen von Beitragenden und Lesenden, Datenverkehr usw. – erneut bestätigen, können wir mit Zuversicht wichtige Diskussionspunkte für unsere wichtigsten Erkenntnisse zum Movement unterstützen.
SDS2.1.1	Wenn wir eng mit Teams zusammenarbeiten, die Experimente durchführen, werden wir lernen, wie wir das System in Zukunft mehr zur Selbstbedienung ausbauen können, und welchen konzeptionellen oder technischen Herausforderungen sie möglicherweise begegnen.
SDS2.1.2	Wenn wir eine bessere Fehlerprüfung für Eventlogging implementieren können, wissen die Produktteams, dass ihr Experiment wie erwartet Ereignisdaten sammelt, was das Vertrauen der Experimentverantwortlichen erhöht.
SDS2.1.3	Wenn wir die Erfassung und Beobachtbarkeit der Komponente für A/B-Tests (xLab) der Experimentierungsplattform und der damit verbundenen MediaWiki-Teile verbessern, können wir Referenzwerte für die Leistung des Systems festlegen und auf Fehler aus dem Experiment reagieren.
SDS2.1.4	Wenn wir einmal im Monat Geschichten und Ergebnisse von Experimenten mit der gesamten Organisation teilen (durch Product-Ops-Treffen, Design-Team-Treffen und teamübergreifende Präsentationen), werden wir eine organische Nutzung der Experimentierungsplattform erreichen.
SDS2.1.5	Wenn wir den Benutzer:innen sagen, dass ihr Instrument, wenn es in xLab erstellt wird, eine Reihe von Attributen enthält, die die Risikokategorie verändern, werden wir Benutzer:innen der Instrumente davon abhalten, übermäßig Daten zu sammeln, und die Klarheit darüber erhöhen, welche Kombination von Attributen eine Überprüfung des Datenschutzes erfordert.
SDS2.1.6	Wenn das Growth-Team mit dem Experiment Lab an der Instrumentierung von zwei Anwendungsfällen arbeitet (einem mit einem A/B-Test, um Einblicke in die Bucketing-Fähigkeiten zu erhalten, und einem mit langfristiger Instrumentierung, um über die Unterstützung von KPI-ähnlichen Metriken zu erfahren), können wir bewerten, ob dieses die Anforderungen ausreichend erfüllt, um unsere maßgeschneiderten Experimente in GrowthExperiments zu ersetzen.

Hypothesen zu Future Audiences (FA) [ FA-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q2-Text	Einzelheiten und Diskussion
FA1.1.4	[Fortgesetzt aus dem letzten Geschäftsjahr] Wenn wir eine neue Wikipedia-Erfahrung auf Roblox entwickeln, werden wir erfahren, ob dies eine wirksame Möglichkeit sein könnte, unsere Marke einem jüngeren Publikum (Generation Alpha) näherzubringen.
FA1.1.2	Wenn wir einen zentralen Hub für neue Wikipedia-Erfahrungen auf itch.io schaffen, werden wir in der Lage sein, ein Publikum von > 50 interessierten Nicht-Wikipedianern zu versammeln, die uns Rückmeldungen geben, wodurch wir lernen können, was in Spielen funktioniert und was nicht.
FA2.2.1	Wenn wir in Communitymanagement auf Kurzvideo-Plattformen investieren, werden wir bis zum Ende des zweiten Quartals (Dezember 2025) einen quartalsweisen Anstieg des Anteils der Ansichten durch neue Zuschauende auf TikTok um 30 % erleben – und auf allen SFV-Plattformen werden wir insgesamt 50.000 Engagements (Likes und Antworten) mit Markenkommentaren auf externen Inhalten erreichen, was uns dabei helfen wird, die Sichtbarkeit zu erhöhen und das Engagement mit jenen Teilen des Publikums zu steigern, die wir derzeit nicht erreichen.
FA2.2.2	Wenn wir eine interne Strategie und externe Ressourcen (einschließlich einer Beschreibung unseres Werts für Creators, Partnerschaftskriterien, Vertragsverfahren und einer Erklärung, wie Creator-Inhalte in den eigenen Kanälen und jenen der Creators gezeigt werden) für ein Wikipedia-Creator-Partnerprogramm entwickeln und dies bewilligt wird, werden wir eine robuste Creator-Strategie entwickeln können, die uns hilft, mit unserem Wissen über die sozialen Medien neues Publikum zu erreichen.

Hypothesen zu Product and Engineering Support (PES) [ PES-Schlüsselergebnisse ] Diskussion
Kürzel der Hypothese	Q2-Text	Einzelheiten und Diskussion
PES1.1.5	Wenn wir die Servicelevel-Zielsetzungen (SLOs) für MediaWiki Content History und Wikifunctions zu Sloth/Pyrra umsetzen, werden wir zwei weitere SLOs in die Produktion bringen.
PES1.1.6	Wenn wir Sloth mit rückwirkenden Daten bestehender SLOs testen, werden wir verstehen, ob Pyrra oder Sloth (oder etwas anderes) das richtige Werkzeug für unseren starren Ansatz für Fehler-Budget-Spielräume ist. Wir werden lernen, wie wir Verantwortliche von Diensten mit einem selbstbedienten Ansatz für SLO-Metriken unterstützen und diese bei der Entscheidungsfindung verwenden.
PES1.2.4	Wenn wir im ersten Quartal einen vierteljährlichen Wunsch- und Community-Signal-Überprüfungsprozess mit drei Teams als Pilotprojekt durchführen, werden wir die Produktmanager dazu bringen, Community-Signale in ihre vierteljährlichen und jährlichen Planungsprozesse zu integrieren.
PES1.2.5	Wenn wir die Funktion hinzufügen, Wünsche in der Wunschliste-Erweiterung zu filtern und zu sortieren, zusätzlich zu den Verbesserungen, die die Kategorisierung über Tags und Stimmen ermöglichen, werden die drei Verbesserungen die Teilnehmendenzahl der Wunschliste um mindestens 30 % erhöhen.
PES1.3.3	Wenn wir mindestens fünf reizvolle Interventionen auf der Plattform erstellen, die auf der Grundlage von Benutzerinteraktionen stattfinden, werden wir definieren, welche die Auslöser für die Portalseite und das Geburtstagsmodus-Gadget sein werden. Die Nutzbarkeitstests werden uns zeigen, welche Interventionen positive Assoziationen mit unserer Marke schaffen. Diese Hypothese wird mit der WikiCon North America Ende Oktober enden.
PES1.3.4	Wenn wir in Zusammenarbeit mit Mitgliedern der Kommunikationsabteilung eine fesselnde Website erstellen, die die Geschichte, Gegenwart und Zukunft von Wikipedia erforscht, um ein Online-Publikum zwischen 18 und 34 Jahren in Zielbereichen der Kampagne zu erreichen, wird sie eine größere Verbindung mit Wikipedia über Weiterverbreitung in sozialen Medien und andere Online-Aktivitäten stimulieren. Dies wird zum Schlüsselergebnis der Kommunikationsabteilung beitragen, dass die Präsenz der Marke um 10 Prozentpunkte steigt, und gleichzeitig zeigen, ob dynamische inhaltliche Ansätze die Beliebtheit der Marke steigern.

Q3

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

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

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] Diskussion
Hypothesis shortname	Q3 text	Details & Discussion
SDS1.5.1	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2	If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4	If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5	If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2	If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.

Future Audience (FA) Hypotheses [ FA Key Results ] Diskussion
Hypothesis shortname	Q3 text	Details & Discussion
FA1.1.1	If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA1.1.2	If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3	If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6	If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

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

Gemeinsame Planung

Update Januar 2025

Im Jahresplan beschreibt die Wikimedia Foundation, was wir im kommenden Jahr erreichen wollen. Wir arbeiten hart daran, den Plan partizipatorisch, mit hohen Ansprüchen und erreichbar zu gestalten. Jedes Jahr bitten wir Beitragende, ihre Perspektiven, Hoffnungen und spezifischen Anfragen einzubringen, während wir den Plan gestalten. Einige der Möglichkeiten, wie wir diesen Input suchen, sind Gespräche von Produktteams mit Communitys, die Community-Wunschliste, Communitygespräche wie die Commons-Gesprächsreihe, Konferenzen und Wiki-Seiten wie diese.

Für unseren nächsten Jahresplan, der den Zeitraum Juli 2025 bis Juni 2026 abdeckt, denken wir darüber nach, wie wir am besten eine generationenübergreifende Vision verfolgen können, da die Welt und das Internet sich schnell verändern, mit Auswirkungen auf unsere Mission für freies Wissen.

Wie ich letztes Jahr schon sagte, müssen wir uns darauf konzentrieren, was uns unterscheidet: unsere Fähigkeit, vertrauenswürdige Inhalte zu liefern, auch wenn sich im Internet und auf den Plattformen, die um die Aufmerksamkeit neuer Generationen konkurrieren, Desinformation und Falschinformationen ausbreiten. Das bedeutet, dass wir sicherstellen, unsere Mission zu erreichen, die Summe allen menschlichen Wissens sammeln und weltweit bereitstellen, indem wir momentan noch fehlende Informationen (etwa aufgrund von Ungleichheit, Diskriminierung oder Voreingenommenheit) abdecken. Unsere Inhalte müssen auch in einem sich verändernden Internet, das durch künstliche Intelligenz und multimediale Erfahrungen angetrieben wird, nützlich und zentral bleiben. Und schließlich müssen wir Wege finden, unsere Bewegung nachhaltig zu finanzieren, indem wir eine gemeinsame Strategie für unsere Produkte und die Mittelgewinnung entwickeln, damit wir diese Arbeit langfristig unterstützen können.

Um Entscheidungen und Kompromisse darüber zu treffen, worauf wir unsere Bemühungen im kommenden Jahr konzentrieren sollen, haben wir Fragen vorbereitet und darüber nachgedacht, wie wir unsere begrenzten Ressourcen so verteilen können, dass wir die größtmögliche Wirkung erzielen können.

Wenn du dich besonders dafür interessierst, welche Produkte oder Dienste die Abteilung für Produkt und Technologie ausgehend von den hier vorgegebenen Prioritäten entwickeln wird, kannst du im März Rückmeldungen zu bestimmten Zielsetzungen und Schlüsselergebnissen geben. (Hier findest du zum Vergleich die Zielsetzungen und Schlüsselergbenisse aus dem aktuellen Jahresplan.)

Wenn du über die Herausforderungen und Chancen in unserem technischen Umfeld und über die Richtung, die wir im nächsten Jahresplan setzen sollten, nachdenken möchtest, geh bitte die folgenden Fragen mit uns durch.

Wir erhalten ständig Informationen zu diesen Fragen – in Communitygesprächen, durch Daten, die wir sammeln, in Forschungsinterviews, die wir durchführen, und über viele weitere Wege. Es ist bei vielen dieser Dinge nicht das erste Mal, dass wir danach fragen – wir haben bereits an vielen davon gearbeitet! Wir wollen jetzt noch einmal danach fragen und mehr erfahren, da sie für uns in dieser Phase der Planung zentral stehen.

Fragen:

• Metriken und Daten
  • Wie können Daten und Metriken eure Arbeit als Beitragende besser unterstützen? Fallen dir Daten zum Bearbeiten, Lesen oder Organisieren ein, die dir helfen würden, zu entscheiden, wie du deine Zeit am besten nutzen kannst oder wann etwas Aufmerksamkeit benötigt? Es können Daten zur eigenen Tätigkeit oder zu Tätigkeiten von anderen sein.
• Bearbeiten
  • Wann fühlt sich das Bearbeiten für dich am lohnendsten an und wann macht es am meisten Spaß? Wann fühlt es sich besonders frustrierend und schwierig an?
  • Wir wollen, dass Beitragende mehr Feedback und Anerkennung für ihre Arbeit erhalten, sodass sie nicht das Gefühl haben, dass niemand die Mühe bemerkt, die sie sich für die Wikis machen. Welche Art von Rückmeldung und Anerkennung motiviert dich? Was bringt dich dazu, weiter zu bearbeiten?
  • Weil die Wikis so groß sind, kann es für die Beitragenden schwierig sein, zu entscheiden, welche Wiki-Arbeit für sie am wichtigsten ist, um täglich Zeit damit zu verbringen. Welche Informationen oder Werkzeuge können dir helfen, zu entscheiden, wie du deine Zeit verbringen möchtest? Wäre es nützlich, einen zentralen, persönlichen Ort zu haben, der es dir ermöglicht, neue Möglichkeiten zu finden, deine Aufgaben zu verwalten und deine Reichweite zu überblicken?
  • Wir wollen die Erfahrung der Zusammenarbeit in den Wikis verbessern, sodass es für Beitragende einfacher ist, einander zu finden und gemeinsam an Projekten zu arbeiten, egal ob es sich um das Abarbeiten von Wartungslisten, Edit-a-thons, WikiProjekte oder zwei gemeinsam arbeitende Beitragende handelt. Wie könnten wir mehr Beitragenden helfen, einander zu finden, sich auszutauschen und zusammenzuarbeiten?
• Lesen/Lernen
  • Die Wikis laden schneller oder langsamer, je nachdem, wo auf der Welt man lebt. Gibt es Weltgegenden, in denen deiner Meinung nach eine bessere Performance am dringendsten benötigt wird?
  • Wie können wir neuen Generationen von Lesenden dabei helfen, Wikipedia-Inhalte interessant und ansprechend zu finden? Wir haben in der Vergangenheit Ideen rund um interaktive Inhalte und Videos besprochen, und im laufenden Jahr haben wir uns auf Diagramme und auf Experimente mit neuen Möglichkeiten, bestehende Wikipedia-Inhalte zu präsentieren, konzentriert. Wie können wir hier weitermachen, um unsere bestehenden Inhalte auf neue, einzigartige Weisen zu nutzen?
• Moderation
  • Was muss sich an Wikipedia ändern, damit mehr Menschen sich in „höheren“ Freiwilligenrollen wie Moderator:innen oder Administrator:innen betätigen wollen?
  • Welche Informationen oder welcher Kontext zu Bearbeitungen oder Benutzer:innen könnten dir helfen, Moderations- oder Adminentscheidungen schneller oder leichter zu treffen?
• Externe Trends
  • Welche wichtigen Veränderungen fallen dir außerhalb von Wikimedia auf? Es können Trends in Technologie, Bildung oder Lernweisen von Menschen sein.
  • An welchen anderen Online-Communitys außerhalb der Wikimedia-Bewegung beteiligst du dich? Was können wir von den Werkzeugen und Prozessen auf anderen Community-Plattformen lernen?
  • Wie nutzt du innerhalb und außerhalb deiner Wikimedia-Arbeit KI-Werkzeuge? Wobei erscheint dir KI nützlich?
• Commons
  • Welche Entscheidungen können wir mit der Commons-Community treffen, um ein nachhaltiges Projekt zu schaffen, das die Erstellung enzyklopädischen Wissens unterstützt?
• Wikidata
  • Wie soll sich Wikidata in Zukunft deiner Meinung nach weiterentwickeln? Wie kann das Projekt der Erstellung seriöser enzyklopädischer Inhalte am besten nützen?

Diskussion

–– Selena Deckelmann