Jaarplan van de Wikimedia Foundation/2025-2026/Doelstellingen en belangrijkste resultaten voor het product en de technologie

This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 77% complete.

Outdated translations are marked like this.

Het komende jaar

Terwijl de wereld verandert, blijft de Wikimedia Foundation er zeker van dat wij met zijn allen willen dat onze missie - om nuttige informatie van de Wikimedia-projecten gratis beschikbaar te maken en te houden op het internet - een onderneming is die over meer generaties rijkt. We willen dat vrije kennis beschikbaar blijft voor vele toekomstige generaties.

Het internet verandert snel. Nieuwe generaties krijgen informatie via de ervaringen van sociale video en AI. Vergeleken met oudere generaties zijn minder van hen op de hoogte van Wikipedia. We zien een daraan gerelateerde afname van het aantal mensen dat naar onze websites komt en van het aantal mensen dat bewerkingen uitvoert. Ondertussen zijn platforms op internet afhankelijk van de inhoud van Wikimedia om hun AI en hun zoekaanbod te ondersteunen. Deze dynamiek is een grote uitdaging, maar maakt ook duidelijk waarom de betrouwbare vrije kennis die we samen creëren zo belangrijk is. De wereld heeft meer dan ooit tevoren behoefte aan een bron van betrouwbare, door mensen beoordeelde kennis. De Wikimedia-projecten laten blijvend zien dat ze dit kunnen bieden.

Om deze uitdagingen het komende jaar aan te gaan, bouwen we manieren vinden om de inhoud van Wikimedia op een duurzame manier te gebruiken en we zullen die inhoud brengen naar de online sociale omgevingen waar jongere generaties hun tijd doorbrengen. We gaan onze eigen sites verbeteren zodat lezers terug willen komen, zich diep betrokken voelen en gaan bijdragen op manieren die voor hen zinvol zijn. En we investeren in ons vermogen om snel te experimenteren met nieuwe technologieën, zodat ons ontwikkelingstempo overeenkomt met het tempo waarin de wereld verandert.

De doelstelling voor de infrastructuur is om voor het platform en de gebruikerservaring deze uitdagingen aan te gaan en daarbij de meerderheid van de deelnemers te bereiken die aan onze beweging meedoen. Het is geen lijst met projecten, maar in plaats daarvan een reeks aanwijzingen om de groei van vrijwilligers te stimuleren, vrijwilligers in staat te stellen om betrouwbare encyclopedische inhoud op te bouwen, om onze missie te financieren en om ons aanbod te ontwikkelen om een bijdrage te leveren aan het veranderende internet. U kunt meer lezen over deze vier strategische pijlers.

Groei van vrijwilligers stimuleren

De gemeenschap van vrijwilligers is de unieke motor achter het succes van de Wikimedia-projecten. We hebben die gemeenschap nodig om gezond te zijn en te groeien. Maar in het afgelopen jaar hebben we een voortdurende daling gezien van zowel het aantal nieuwe als het aantal terugkerende bewerkers. Om de behoeften van onze huidige vrijwilligers beter te begrijpen en om er effectiever op in te spelen, heeft de Foundation de wensenlijst herzien. In plaats van een jaarlijkse enquête is die omgevormd naar een intakeproces dat altijd open is, zodat de behoeften van gebruikers en ideeën voor projecten meegenomen kunnen worden in het werk van meerdere teams bij de Foundation. We hebben wensen gegroepeerd in "Aandachtsgebieden" en hebben drie van die aandachtsgebieden geïntegreerd in het jaarplan. We zijn ook begonnen met een pilot Adviesraad voor producten en technologie als aanvulling op de talrijke gesprekken die de teams van de Foundation lopende het jaar hebben met leden van de gemeenschap, on- en off-wiki. Daarnaast hebben we kansen geïdentificeerd om nieuwe generaties bij onze projecten te betrekken. Zo blijkt bijvoorbeeld dat jongeren actief deelnemen aan andere online sociale platforms, waar ze op een eenvoudige manier, met gebruik van hun mobiele telefoons, contact kunnen maken over onderwerpen die hen interesseren.

In het komende jaar zullen we de groei van het aantal vrijwilligers stimuleren door bijdragen gemakkelijker en aantrekkelijker te maken voor nieuwe generaties. Dit gaan we doen door mobiel eerst uit te breiden, nieuwe manieren van bewerken aan te bieden (“gestructureerde taken”) en intelligente workflows toe te voegen die constructief mobiel bewerken eenvoudig maken voor nieuwe bijdragers (“bewerkcontroles”). Om bestaande vrijwilligers meer te betrekken en te behouden, zullen we aanbevolen acties en taken aanbieden en deze weergeven in een centrale hub die het gemakkelijk maakt om on-wiki-activiteiten te organiseren. We zullen zorgvuldig AI gaan gebruiken om vrijwilligers in hun werk te versterken, waarbij we mensen altijd op de hoogte houden en prioriteit geven aan transparantie. Voor zowel nieuwe als ervaren vrijwilligers zullen we routes te ontwikkelen om verbinding te zoeken en samen te werken op onze sites. We laten ons hierbij inspireren door door succesvolle campagnes en WikiProjects - waardoor ze gelijkgestemde bewerkers kunnen vinden en inhoud kunnen verbeteren die verband houdt met hun interesses (dit is in lijn met dit aandachtsgebied van de wensenlijst).

Betrouwbare encyclopedische inhoud opleveren

Omdat AI-gegenereerd materiaal zich steeds verder over het internet verspreidt, heeft de wereld meer dan ooit behoefte aan betrouwbare encyclopedische inhoud. We willen de mogelijkheden van vrijwilligers vergroten om nieuwe inhoud te maken, ervoor te zorgen dat bestaande inhoud betrouwbaar blijft, en betrouwbare informatie te verstrekken aan een nieuwe generatie lezers met andere behoeften en voorkeuren.

Om vrijwilligers te helpen bij het maken van nieuwe inhoud, bouwen we voort op bestaande hulpmiddelen en workflows (zoals de Vertaaltool), zodat zowel grote als kleinere gemeenschappen essentiële inhoud kunnen leveren. Om ervoor te zorgen dat bestaande inhoud betrouwbaar blijft, zullen we ervaren vrijwilligers helpen hun groeiende werklast beter te beheren door de hulpmiddelen uit te breiden die ze gebruiken om taken te vinden die hun aandacht nodig hebben - waardoor het voor hen gemakkelijker wordt om artikelen bij te werken en om nutteloze bewerkingen terug te draaien (in lijn met dit aandachtsgebied op de wensenlijst).

We zullen ook de Wikimedianen met functies ondersteunen bij het beschermen van onze inhoud door nieuwe signalen zichtbaar te maken (naast IP-adressen) die kwaadwillende gebruikers identificeren. Dit maakt het mogelijk om gebruikers te blokkeren op een manier die het risico verkleint dat goedbedoelende gebruikers onterecht worden meegeblokkeerd.

Om encyclopedische inhoud aan een nieuwe generatie te leveren, zullen we functies bouwen die nieuwe soorten lezers helpen om artikelen eenvoudig te begrijpen, informatie te vinden die hen interesseert, en actief deel te nemen terwijl ze lezen. Deze veranderingen zijn bedoeld om nieuwe Wikipedialezers aan te stimuleren om toegewijde lezers te worden. Daarom kunnen sommigen van hen uitgroeien tot donateur (in lijn met dit aandachtsgebied van de wensenlijst).

Het zorgen voor betrouwbare inhoud betekent ook het ondersteunen van een "knowledge as a service"-model, waarbij het hele internet afhankelijk is van Wikimedia-inhoud. In dit model is onze infrastructuur niet alleen een waardevolle bron voor mensen die naar onze website komen, maar ook voor bedrijven met zoekmachines en voor en AI-bedrijven, die automatisch toegang hebben tot onze inhoud als een fundamentele input voor en output van hun producten. Dit soort bedrijven zijn slechts een van de vele toepassingen die steeds meer een onhoudbare grote belasting van onze infrastructuur veroorzaken. In het afgelopen jaar heeft een aanzienlijke toename van het aantal aanvragen van scrapers en bots het voor ons urgenter gemaakt om deze trend om te buigen. We moeten duurzame manieren vinden voor ontwikkelaars en hergebruikers om toegang te krijgen tot de kennis, zodat mensen voorrang krijgen boven bots.

De toekomst van 'gratis' financieren

De afdeling Product & Technology speelt een belangrijke rol om ervoor te zorgen dat onze beweging duurzaam is. In het komende jaar zullen we nauw samenwerken met het team Fundraising, zodat onze donateurs een steeds duidelijkere en lonender ervaring hebben. Op onze sites en mobiele apps zullen we mogelijkheden creëren voor lezers om hun waardering voor Wikipedia te uiten door te doneren, en we zullen nieuwe manieren creëren voor donateurs om zich erkend te voelen, zodat ze hun donaties jaar na jaar voortzetten.

Vormgeven aan een veranderend internet

Om gratis kennis naar iedereen in de wereld te brengen, moeten we hen ontmoeten waar ze zijn, met de ervaringen die hen helpen leren. Mensen van 18 tot 24 jaar hebben minder kennis en gebruik van Wikipedia dan de generaties die hen voorgingen. Ze leren grotendeels van en interacteren met korte videoplatforms, vertrouwde online persoonlijkheden, sociale game-ervaringen en, steeds vaker, AI-toepassingen. Dit jaar zullen we Wikipedia beschikbaar maken voor die doelgroepen op de plekken waar ze online tijd doorbrengen, zodat ze Wikipedia kennen als een bron van betrouwbare en door mensen gecreëerde kennis. We zullen onze aanwezigheid op populaire videoplatforms vergroten, Wikipedia-inhoud verspreiden en een community in die ruimtes genereren. En we zullen ideeën verkennen om Wikipedia-kennis naar gaming- en sociale platforms te brengen.

Binnen Infrastructuur is dit verdeeld in drie werkportefeuilles (die "buckets" worden genoemd): Wiki Experiences, Signals and Data Services en Future Audiences. Deze zijn hetzelfde als vorig jaar en het jaar ervoor.

Samen geloven we dat dit plan een cruciaal moment in de geschiedenis van internet vormt en ons in staat stelt ervoor te zorgen dat gratis kennis voor alle generaties toegankelijk en gevormd blijft. Onze doelstellingen en belangrijke resultaten geven meer nadruk op de structuur en inhoud van dit plan en wij kijken ernaar uit om vragen en ideeën van de bredere gemeenschap te horen.

Bouwen, verbeteren en onderhouden van de infrastructuur voor Wikimedia-projecten en vrijwilligers, geworteld in onze waarden

"De Foundation zal nuttige informatie uit haar projecten kosteloos op internet beschikbaar stellen en houden, voor altijd."

De teams Product en Technologie hebben een permanente, jaar door prioriteit om de infrastructuur die de Wikimedia-projecten bedient te bouwen, te verbeteren en te onderhouden. We investeren in het hosten van de Wikimedia-projecten, het ontwikkelen van open source software en ontwerpsystemen, en het onderhouden en verbeteren van de infrastructuur voor dataproducten en AI-modellen.

Een deel van ons essentiële werk is gericht op de basisprincipes van het ontwikkelen en hosten van een grote populaire website. We hosten onze Wikimedia-projecten in datacenters, op servers en hardware die we kopen, installeren en onderhouden, verbonden met elkaar en met de rest van het internet via een hogesnelheidsnetwerk. We monitoren en voegen capaciteit toe waar nodig, en vernieuwen apparatuur wanneer deze te oud wordt. Dit jaar verwachten we bijvoorbeeld onze capaciteit uit te breiden en onze hardware te vernieuwen in onze datacenters in Ashburn, Virginia en Carrollton, Texas.

We ontwerpen en ontwikkelen open-source software (met name MediaWiki). We gebruiken en implementeren ook veel bestaande open-source applicaties, bibliotheken en frameworks van derden. Belangrijke bugs in onze software krijgen prioriteit en worden opgelost. Het onderhouden van open source-software vereist hooggekwalificeerd werk van mensen met speciale expertise op het gebied van open source-softwareontwikkeling, site-betrouwbaarheidsengineering (SRE), productbeheer, programmabeheer, ontwerp en meer. Onze medewerkers zorgen ervoor dat onze software en systemen up-to-date zijn en zich aanpassen aan een steeds veranderende omgeving. Dit omvat het moderniseren van onze code om te blijven profiteren van beveiligingsoplossingen en om goed te werken met nieuwe software van derden. MediaWiki is bijvoorbeeld geschreven in PHP en in het afgelopen jaar zijn we gemigreerd van PHP 7.4 naar 8.1, wat wijzigingen vereiste in zowel de code als de infrastructuur waarin we onze sites en services hosten. Dit jaar bouwen we voort op die inspanning en migreren we naar 8.3, met behulp van de lessen die we hebben geleerd en de hulpmiddelen die zijn ontwikkeld in de 8.1-upgrade. Door te updaten worden onze systemen sneller voor lezers, gemakkelijker te gebruiken voor personeel en vrijwilligers, en veiliger voor iedereen. Het bespaart ook toekomstige ontwikkelingstijd dankzij beveiliging-, prestatie- en ondersteuningsverbeteringen die worden geleverd met updates.

Om ervoor te zorgen dat onze projecten en inhoud beschikbaar blijven op het internet, zowel vandaag als voor altijd, doen onze teams veel moeite om een hoge beschikbaarheid van onze sites en diensten te garanderen. Een aspect van dit werk richt zich op noodherstel na catastrofale of kwaadwillige gebeurtenissen. We zorgen er bijvoorbeeld voor dat we back-ups hebben van belangrijke gegevens en deze kunnen herstellen. Op dezelfde manier testen we twee keer per jaar ons vermogen om onze sites op geautomatiseerde wijze tussen onze datacenters te schakelen en eventuele problemen die we tegenkomen op te lossen. Een ander aspect van dit werk is gericht op het identificeren van en aanpassen aan evoluerende trends in de soorten en volumes van het verkeer dat we ontvangen. Bijvoorbeeld, met een ongekende groei in geautomatiseerde "scrapers", geven we prioriteit aan werk om ervoor te zorgen dat onze sites en services toegankelijk blijven voor menselijke gebruikers, waarbij we een systematische aanpak hanteren om normen vast te stellen rond verantwoord gebruik van onze infrastructuur.

Niet alle werkzaamheden worden ver van tevoren gepland. We reageren ook op onverwachte gebeurtenissen en incidenten, zoals uitval van sites, beveiligingsrapporten of beveiligingsincidenten, of grootschalige vandalisme-aanvallen op onze projecten. We monitoren onze prestaties en barrières voor bereikbaarheid over de hele wereld (inclusief problemen met de internetverbinding of censuurblokkades) en onderzoeken eventuele afwijkingen die we vinden. Sommige van deze onverwachte gebeurtenissen of zich herhalende patronen van problemen leiden ertoe dat het personeel prioriteit geeft aan kortetermijnvervolgprojecten die gericht zijn op het verzachten of volledig voorkomen van verdere negatieve impact. Dit soort inspanningen waren bijvoorbeeld cruciaal om onze Wikimedia-projecten in staat te stellen bestand te zijn tegen wereldwijde verkeerspieken als gevolg van grote nieuwsgebeurtenissen (bijv. spraakmakende sterfgevallen van beroemdheden), door een combinatie van prestatie-optimalisatie, architectonisch herontwerp van knelpunten en capaciteitsverhogingen. Evenzo hebben recente verbeteringen in de bruikbaarheid van onze hulpmiddelen en systemen voor het beheer van het verkeer dat we ontvangen, ons in staat gesteld sneller en effectiever te reageren op veranderende omstandigheden. Dit soort adaptief werk is een integraal onderdeel van ons vermogen om te reageren op opkomende gebeurtenissen, vaak op korte tijdschalen, en ervoor te zorgen dat onze projecten en inhoud beschikbaar blijven.

Product en Technologie doelstellingen

De hier gepresenteerde doelstellingen zijn in conceptvorm en staan open voor commentaar en discussie.

De Doelstellingen vertegenwoordigen een richting op hoog niveau.
De "Belangrijkste resultaten (KR)" vormen een meetbare manier om het succes van hun doelstellingen te volgen.
De onderliggende "Hypothesen" voor elk belangrijkste resultaat vertegenwoordigen het daadwerkelijke werk dat we doen om dat resultaat te behalen. Ze worden bijgewerkt in dit document en op de wikipagina's van het relevante project of team naarmate er gedurende het jaar inzichten worden verkregen.
is voor werk dat de Foundation prioriteit geeft op de wensenlijst van de gemeenschap.

Wiki-ervaringen (WE)

Ervaringen van bijdragers (WE1)

Doel: Bijdragen nemen toe omdat vrijwilligers interessante kansen krijgen en de impact daarvan begrijpen. Discussie
- Context: Deze doelstelling zal de basis vormen voor het leveren van de nieuwe bijdragestrategie met zijn 3 pijlers: 1- vrijwilligers een gecentraliseerde manier bieden om hun on-wiki-activiteit te organiseren, 2- kleinere, afzonderlijke taken bieden om meer duidelijkheid te creëren en vrijwilligers te helpen hun potentieel te bereiken, en 3- bijdragen zinvoller maken. In boekjaar 25/26 zijn we van plan om de basisinfrastructuur te leveren om vrijwilligers te helpen hun on-wiki-activiteit op een gecentraliseerde manier te organiseren, te beginnen met interventies die specifiek gericht zijn op ervaren redacteuren en moderators. In de daaropvolgende jaren zullen we interventies toevoegen aan alle bijdragerollen en meer probleemgebieden opnemen. Daarnaast zullen we blijven investeren in Edit Check en Structured Tasks, waarmee we een basis bouwen voor hoe AI op een schaalbare manier kan worden gebruikt, zowel als begeleiding tijdens het bewerkingsproces als een manier om vrijwilligers te wijzen op aantrekkelijke kansen. En tot slot zullen we investeren in het zichtbaarder maken van de impact die vrijwilligers hebben om een zinvollere ervaring voor hen te creëren.
  - Belangrijkste resultaat WE1.1: Verhoog de snelheid waarmee bewerkers met ≤100 cumulatieve bewerkingen constructieve bewerkingen publiceren op mobiel internet [i] met 4% [ii], zoals gemeten door gecontroleerde experimenten (aan het einde van Kwartaal 2).
    - i. "Constructieve bewerkingen" = bewerkingen op pagina's in de namespace Main die niet binnen 48 uur na publicatie worden teruggedraaid.
    - ii. T389403#10960480
    - Nieuwe vrijwilligers worstelen om succesvol te beginnen met het bewerken. Vooral mensen die mobiele apparaten gebruiken, waar de ruimte op het scherm beperkt is en de aandacht vaak gefragmenteerd is.
    - Sommigen worden moe van de context, geduld en beproevingen en fouten die nodig zijn om opbouwende wijze bij te dragen. Anderen hebben nog geen dwingende gelegenheid gehad om het te proberen.
    - WE 1.1 zal deze problemen aanpakken door:
      - Suggesties voor het bewerken beoordelen
      - Het aanbieden van bruikbare begeleiding tijdens het bewerken
      - Het maken van meer taakspecifieke bewerkingswerkstromen
    - De kern van deze inspanningen is de noodzaak van schaalbare manieren om te ontdekken hoe in progressie zijnde bewerkingen en bestaande inhoud kunnen worden verbeterd. Om deze capaciteit te laten groeien, zullen we blijven experimenteren met machine-learning om te leren hoe het editors het beste van dienst kan zijn, in alle rollen en ervaringsniveaus.
    - Voorgestelde KR-scoremethodologie: Per platform berekenen we het aandeel interventies dat we hebben ingezet en geëvalueerd door middel van gecontroleerde experimenten die het constructieve bewerkingsdoel hebben bereikt en/of overtroffen dat we aan het begin van dit jaar hadden gesteld. Zie phab:T379285#10782051 voor de opzet.
      - NB: op 30 juni 2025 heeft WE 1.1 twee gecontroleerde experimenten gepland.
  - Belangrijkste resultaat WE1.2: Toename van het aantal samenwerkingen op de wiki's met 55% op jaarbasis tegen het einde van Kwartaal 4.
    - De bijdragers hebben vaak moeite om te vinden hoe ze met elkaar kunnen samenwerken, vooral rond de onderwerpen en taken waar ze om geven. Dit kan voor nieuwkomers leiden tot een gevoel van alleen zijn op de wiki's, en het kan leiden tot uitputting voor ervaren redacteurs. Bovendien is de impact van samenwerkingsactiviteiten vaak onduidelijk, wat kan leiden tot minder mensen die zich willen aansluiten, organiseren of de samenwerking op de wiki's willen ondersteunen.
    - We willen de waarde van samenwerking duidelijker maken door het volgende te doen:
    1. Nieuwe manieren maken om de impact van samenwerkingsactiviteiten op de wiki's te delen
    2. Begin met het verzamelen van gegevens over de impact van samenwerkingsactiviteiten op het gebied van de movement
    3. De basisinfrastructuur opzetten voor het volgen van de bijdragen van samenwerking, zodat we innovatieve nieuwe manieren kunnen bieden om bijdragen in de toekomst te erkennen en te belonen
    - Samenwerking wordt gemeten door nieuwe activiteiten die worden gecreëerd via Event Registration in de extensie CampaignEvents. Het doel is dat we tegen het einde van dit KR meer gebruikers van de extensie hulpmiddelen en nieuwe manieren hebben om de impact van samenwerking te laten zien. Dit zal ons in een goede positie brengen om onze bestaande infrastructuur te verbinden met andere manieren om werk op de wiki's te erkennen en te belonen (zoals de impactmodule, bedankjes, enz.).
    - Aandachtsgebied van de wensenlijst: Bijdragers verbinden
  - Belangrijkste resultaat WE1.3: Aan het einde van Kwartaal 3 bezocht 10% van de bijdragers die een homepage kregen die gericht was op nieuwe moderators, deze twee weken op rij.
    - Wij geloven dat we het beter kunnen doen om bijdragemogelijkheden voor vrijwilligers onder de aandacht te brengen. Op de lange termijn geloven we dat een homepage nuttig kan zijn voor elke bewerker om zijn werk te organiseren, nieuwe kansen te vinden en de impact ervan te begrijpen. Ons doel in boekjaar 2025/2026 is om nieuwe mogelijkheden te bieden aan ervaren bewerkers om moderatietaken op zich te nemen waar ze anders niet per se aan zouden zijn blootgesteld.
    - We zullen deze theorie eerst testen door te begrijpen hoeveel ervaren bewerkers zich zouden bezighouden met een startpagina, vergelijkbaar met waar nieuwkomers toegang toe hebben.
    - We zullen dan specifieke moderatieactiviteiten (details moeten nog worden bepaald) onder de aandacht brengen van bijdragers die nieuw zijn in dat soort moderatieacties, met als doel de last voor ervaren bewerkers te verminderen door achterstanden te verminderen (onder een nieuwe KR).
    - Als het concept van de homepage succesvol is, zijn we van plan deze pagina modulair te maken om tegemoet te komen aan de behoeften van gemeenschappen. Deze modules kunnen zaken bevatten als het gemakkelijker maken voor bewerkers om hun impact te begrijpen.
    - Opmerkingen over de methodologie:
    - We zullen een hypothese hebben om ons publiek te definiëren, die deel zal uitmaken van WE1.3.1.
    - "Moderators" zullen de definitie volgen die is gestart in Research:Develop a working definition for moderation activity and moderators, hoewel er vervolgwerk nodig zou zijn om de kwantitatieve definitie te verfijnen.
    - De tweede week wordt bepaald op basis van de timing van het eerste bezoek van elke gebruiker. In dit geval beoordelen we alle nieuwe moderators die de homepage gedurende een bepaalde periode hebben bezocht en vervolgens ten minste nog één keer (7 tot 14 dagen) opnieuw hebben bezocht.
    - Aandachtsgebied van de wensenlijst: Taakprioritering
  - Belangrijkste resultaat WE1.4: Verbeter het % unieke bezoekers op de volglijst en/of recente wijzigingen die klikken om een bewerking te bekijken.
    - Ons doel is om bewerkers met meer dan 100 bewerkingen te helpen om efficiënter bewerkingen te vinden en te openen die betrekking hebben op hun interesses. We zullen het aandachtsgebied Taakprioritering, wensen laten leveren op dit gebied en om aanvullende feedback van vrijwilligers vragen over hoe deze delen kunnen worden verbeterd. We kunnen succes meten door de doeltreffendheid van elke pagina bij het "vinden van werk" te verbeteren, gedefinieerd door de indicatormetriek van de verhouding van het doorklikken.
  - Belangrijkste resultaat WE1.5: Definieer en operationaliseer zeven statistieken met hoge prioriteit die nodig zijn voor het volgen van de voortgang bij het bereiken van de doelen die zijn uiteengezet in de bijdrager-strategie tegen het einde van Kwartaal 4, door een dashboard te creëren en maandelijkse actieve moderator-statistieken te operationaliseren.
    [1] Behouden bewerkers, constructieve activering, constructieve bewerkingen, accountregistraties behouden nieuwkomers, actieve bewerkers per ambtstermijn, actieve bewerkers per ervaringsniveau.
    - De strategie voor de bijdrage-ervaring voorziet in een inspanning van 3-5 jaar om "vrijwilligersgroei te stimuleren" en "het behoud en de activatie van nieuwe en bestaande bijdragers te verhogen" door middel van drie hoofdgebieden van activiteiten:
    1. Stroomlijnen van hoe vrijwilligers aanbevelingen kunnen ontvangen, hun taken en interesses kunnen beheren, zien wat er op de wiki's gebeurt en hun impact kunnen begrijpen
    2. Aanbieden van gepast gestructureerde taken om meer duidelijkheid te creëren en vrijwilligers te helpen hun potentieel te bereiken door de werkstromen te optimaliseren waartoe we hen sturen, met inbegrip van een voortdurende investering in het leveren van gestructureerd begeleiding en het automatiseren van herhaalde taken, met een speciale focus op de mobiele webervaring
    3. Een betekenisvolle bijdrage leveren door vrijwilligers hun impact te laten zien en door te investeren in manieren voor menselijke verbinding en een milieu op basis van positieve feedback
    - Een meetstrategie schetste vervolgens een uitgebreid netwerk van statistieken voor deze veranderingstheorie. Het concludeerde dat de primaire maatregel van succes ("kernmeting") een aantal behouden redacteuren zou moeten zijn, aangevuld met een smaller indicator meting zoals de constructieve activatie en de bedoeling van de bijdragen om terug te keren en bredere "downstream" meting zoals actieve redacteuren en kwaliteitsinhoud. We moeten ervoor zorgen dat deze statistieken in een dashboard worden geopereerd en zichtbaar zijn, zodat we onze vorderingen kunnen volgen om de strategie te implementeren.
  - Belangrijkste resultaat WE1.6: Aan het einde van Kwartaal 3 kunnen gebruikers van de volglijsten hun werk gemakkelijker organiseren en effectiever handelen bij het ondernemen van patrouillerende of bewerkbare acties, gemeten aan de hand van kwalitatieve feedback.
    - Ons doel is om redacteurs met meer dan 100 bewerkingen te helpen om efficiënter bewerkingen te vinden die verband houden met hun interesses. We zullen het aandachtsgebied Task Prioritization onderzoeken, wensen uitbrengen op dit gebied en extra feedback vragen van vrijwilligers over hoe dit kan worden verbeterd.
  - Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
    [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
    Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
    - 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
    - WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
  - Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
    - Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
    - This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
    - We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
  - Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
    - Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
    - Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
    - Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
  - Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
    - The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Essentiële kennis (WE2)

Doel: Meer essentiële kennis beschikbaar maken en duidelijk illustreren, in verschillende talen en over verschillende onderwerpen. Discussie
- Objectieve context: Deze doelstelling zal de groei van content stimuleren die reageert op zowel de interesses van bijdragers in specifieke onderwerpen en talen, als de vraag van lezers naar essentiële kennis die goed wordt geïllustreerd. Essentiële kennis is een set artikelen die de breedte en diepte van onderwerpen levert die nodig zijn voor een bruikbaar Wikipedia-taalproject. Het wordt gedefinieerd door gemeenschappen met betrekking tot notabiliteit, relevantie, voorspelde lezersaantallen en verbindingen tussen artikelen.
- We zullen een sociaal-technische benadering nemen, waardoor de effectiviteit van functies, hulpmiddelen en sociale processen zal worden verbeterd. We zullen bouwen op high-impact productfuncties zoals voorgestelde taken, media zoek en content vertaling, maar ook faciliteren de onboarding en ontwikkeling van kleinere taal Wikipedia's. We zullen de organisatoren van Wikimedia ondersteunen die bijdragers werven, trainen en ondersteunen om te werken aan gedeelde inhoudsdoelen door middel van collaboratieve opstellingen zoals WikiProjects en campagnes. (We schatten dat er minstens 300 organisatoren per kwartaal actief zijn.) We zullen ook relaties met de meest relevante uitgevers ontwikkelen om barrières voor bronmateriaal te verwijderen. (We hebben momenteel partnerschappen met meer dan 100 van de grootste databases ter wereld met alleen abonnementen.)
- Om ervoor te zorgen dat onze interventies een positieve impact hebben op vitale kennis, zullen we zowel de toename van prioritaire inhoud van de gemeenschap als de kwaliteit van die inhoud meten, door te kijken naar factoren zoals terugkeercijfers en het aantal citaten en afbeeldingen.
  - Belangrijkste resultaat WE2.1: Experimenteer en evalueer tegen het einde van Kwartaal 2 drie interventies die bijdragers helpen de status van essentiële content op hun Wikipedia's te verbeteren.
    - Deze KR zal tekortkomingen in bewerkingsmechanismen, zoals het ontdekken van beelden op Wikipedia, inhoudsvertaling en het leiden van het maken van nieuwe artikelen, benadrukken. We zullen ook een sociaal-technische interventie implementeren en testen om de inhoudscreatieactiviteiten voor kleine taalgemeenschappen te ondersteunen. Succes wordt gemeten binnen elke hypothese.
  - Belangrijkste resultaat WE2.2: Tegen het einde van Kwartaal 4 de platformmogelijkheden bouwen die nodig zijn om te valideren dat we de Abstract Wikipedia-visie op schaal kunnen ondersteunen. We weten dat we succesvol zijn als we laten zien dat het systeem rijke, meertalige encyclopedische inhoud produceert met behulp van Wikidata en het genereren van natuurlijke taal, wordt beheerd door de Wikimedia-gemeenschap en blijft presteren in brede uitrol.
    - Nu we Wikidata kunnen gebruiken om eenvoudige inhoud in platte tekst op Wikipedia's uit te voeren, is de volgende stap om door te gaan met het bouwen van platformmogelijkheden die Abstracte Wikipedia op schaal kunnen ondersteunen. Het platform moet rijke, meertalige inhoud ondersteunen die door de gemeenschap kan worden beheerd en op schaal kan blijven presteren. Dit is een mijlpaal KR als we gaan van 0-1.
  - Belangrijkste resultaat WE2.3: Tegen het einde van Kwartaal 4, een eerste vorm van de nieuwe wiki implementeren voor het vroege maken van abstracte artikelen en hun integratie in een contentwiki prototype doen.
    - Dit resultaat stelt ons in staat om volgend jaar de platformmogelijkheden van een abstracte wiki te testen. De nieuwe, zelfstandige wiki zal de bibliotheek met abstracte artikelen hosten die zijn gebouwd op Wikifunctions, en de platformmogelijkheden bieden die nodig zijn om later abstracte artikelen in de toekomst in Wikipedia te integreren.
  - Belangrijkste resultaat WE2.4: WMF en WMDE op één lijn brengen over de definitie van succes voor de verbeteringen aan de technische infrastructuur die een Wikidata-kritieke use-case ondersteunt tegen het einde van Kwartaal 2, inclusief statistieken en doelen tot en met boekjaar 25-26.
    - Het WMF Wikidata Platform (WDP)-team is in augustus 2025 opgericht en bemand - één Product Lead en één Tech Lead. Als een nieuwe toevoeging aan een programma met jaren van ontwikkeling door technische en producteigenaren in respectievelijk WMF en WMDE, weerspiegelt dit doel onze intentie om eigendom over te dragen door afstemming op gebruiksscenario's, afhankelijkheden en belangrijke succescriteria. Dit resultaat zal de basis leggen voor wederzijds begrip van de probleemruimte, waarop we de rest van het boekjaar (mei 2026) zullen voortbouwen.
  - Belangrijkste resultaat WE2.5: Aan het einde van Kwartaal 4 is onze backendvervanger parallel aan Blazegraph opgezet en kan het de cutover van geselecteerde gebruikers ondersteunen. Wij definiëren "migratieklaar" voor dirt resultaat als in staat om de pilotfase van onze migratie in het eerste kwartaal van boekjaar 2026-27 te ondersteunen."
    - Na de vooruitgang die is geboekt bij het definiëren van de succescriteria als onderdeel van WE2.4, schakelen we nu over op de uitvoeringsmodus. In de komende twee kwartalen zullen we alle variabelen die samenhangen met de Blazegraph-cutover in een migratieplan uiteenzetten, bepalen welke cruciaal zijn voor pilotlancering, deze implementeren in een nieuwe RDF-database en de migratietijdlijn definiëren voor alle vereisten buiten onze pilotpersona's. Ons werk tussen nu en onze beoogde lancering van een nieuwe WDQS-backend (gestart juli 2026) zal worden geleid door de eisen die in dit plan zijn vastgelegd.

Consumentenervaringen (WE3)

Doel: Lezers van verschillende generaties betrekken bij Wikipedia en dat zo houden, wat leidt tot een meetbare toename in behoud en donatieactiviteit. Discussie
- Objectieve context: Deze doelstelling zal zich richten op het behouden van nieuwe lezers door middel van innovatieve inhoudsformaten, kerndoelgroepen door het versterken van vertrouwde leeservaringen en het verzekeren van duurzaamheid op de lange termijn door het verdiepen van lezersverbindingen en het diversifiëren van donaties. Het zal een voortzetting van ons werk omvatten om inhoud gemakkelijker te ontdekken te maken door middel van nieuwe en meer experimentele functies zoals AI-samenvattingen of gepersonaliseerde rabbit holes. Het zal ook werk omvatten om de kwaliteit van de leeservaring dieper in de leestrechter te behouden en te verbeteren en om leescuratie te verkennen door middel van leeslijsten en andere niet-bewerkende deelname. Voor donoren zal dit werk zich blijven richten op het diversifiëren van inkomstenbronnen binnen het platform.
  - Belangrijkste resultaat WE3.1: Tegen het einde van Kwartaal 2 een praktisch significante toename aantonen in het vasthouden van uitgelogde lezers, zoals gemeten door middel van A/B-testen van één functie per platform
    - Deze KR zal zich richten op het blijven investeren in ervaringen die optimaliseren voor nieuwe manieren van bladeren en leren van inhoud, vaak door het gebruik van nieuwe technologieën en formaten - het presenteren van bestaande inhoud op nieuwe en boeiende manieren. In dit boekjaar willen we verder experimenteren met nieuwe functies en tegelijkertijd ons richten op het uitbreiden van succesvolle experimenten op wiki's en platforms. Het werk in de KR zal zich uitstrekken over de mobiele en desktopwebsite, evenals de iOS- en Android-apps en zich richten op het ontdekken van inhoud (browsing entry points en aanbevelingen) en aanpasbare leerformaten (machine-geassisteerde samenvattingen, content remixing).
    - Wensenlijst aandachtsgebied: Ervaringen nieuwe klanten
  - Belangrijkste resultaat WE3.2: Verhoging van het aantal donaties via niet-banner- of e-mailmethoden met 5% op jaarbasis per platform door productinterventies die diepere verbindingen bevorderen en de wrijving voor donoren verminderen tegen het einde van Kwartaal 2
    - In deze KR willen we de nieuwe toegangspunten verkennen voor donatie en andere mogelijkheden om lezers om te zetten in donateurs en ze te behouden door hun connecties met de wiki's te verdiepen, met meer gepersonaliseerde inhoud. De KR zal zich richten op het introduceren van nieuwe toegangspunten en het itereren van bestaande toegangspunten op apps en web, in samenwerking met het team fundraising.
  - Belangrijkste resultaat WE3.3: Tegen het einde van Kwartaal 2 een praktisch significante toename van het aantal ingelogde lezers aantonen, zoals gemeten door middel van A/B-testen van één functie per platform
    - In deze KR richten we ons op het verbeteren van de lezervaring en het leren van bestaande en ervaren lezers, met als doel het huidige publiek te behouden en hun verbinding met de site te verdiepen zodat ze meer kunnen leren, evenals klaar en open zijn om paden te nemen naar donatie en bewerking. Het werk hier zal zich richten op het verbeteren van de leerervaring op het web en apps (verbetering van de leesbaarheid, betere navigatie en ontdekking), evenals het uitbouwen en itereren van onze curatie- en personalisatie aanbiedingen (leeslijsten, gepersonaliseerde suggesties, gebruikers- en artikelgeschiedenis, enz.)
  - Belangrijkste resultaat WE3.4: Tegen het einde van Kwartaal 4, verwijder alle geïdentificeerde blokkers voor kleinschalige geïmplementeerde cachesites (PoPs) die voldoen aan onze huidige kwaliteits- en beveiligingsnormen, conform onze huidige cachesite-implementaties
    - Deze KR zal zich richten op het bewijzen van het concept dat we de prestaties van de website kunnen verbeteren en latentie voor onze lezers kunnen verminderen door onze caching-infrastructuur te vereenvoudigen en de processen voor de implementatie van een caching-site te verbeteren door de baseline-implementatietijd te verminderen van ongeveer een jaar gemiddeld tot maximaal een kwart. De focus zal hier zijn om de vereenvoudiging af te ronden, een PoC te implementeren, een beveiligingsonderzoek uit te voeren en een besluitbrief te voltooien over het gaan met het implementeren van onze edge caches in openbare clouds. Verminderde latentie kan leiden tot een bewezen toename van paginabeelden en een geografisch meer diverse lezerbasis.
  - Belangrijkste resultaat WE3.5: Verbeter de identificatie van donoren. Zorg ervoor dat alle ingelogde lezers die toestemming hebben gegeven, kunnen worden geïdentificeerd op basis van hun donorstatus, voor een gepersonaliseerde ervaring.
    - We zullen strategieën voor donoridentificatie implementeren om ervoor te zorgen dat alle ingelogde lezers die toestemming hebben gegeven, kunnen worden geïdentificeerd op basis van hun donorstatus. Dit zorgt voor een meer gepersonaliseerde en aantrekkelijke ervaring. Donoridentificatie zal tot en met het vierde kwartaal prioriteit krijgen om in de toekomst effectievere personalisatie- en activeringsinitiatieven te ondersteunen.
  - Belangrijkste resultaat WE3.6: Tegen het einde van Kwartaal 4 een strategie voor de Wikipedia-lezers- en consumentenervaring op verschillende platforms afronden, publiceren en communiceren, met gedefinieerde doelen en basisstatistieken, ontwikkeld in samenwerking met belanghebbenden en de gemeenschap, om ons werk tot 2030 te begeleiden.
    - Het werk aan de consumentenstrategie zal worden voortgezet, met de nadruk op het opbouwen en communiceren van de strategie, zowel intern als met de gemeenschap, en het definiëren en vaststellen van kernstatistieken voor consumenten en hun respectieve basiswaarden.
  - Belangrijkste resultaat WE3.7: Verhoog het aantal donaties via niet-banner of e-mailmethoden met 10% jaar-tot-jaar per platform via productinterventies die diepere verbindingen bevorderen en wrijving voor donateurs verminderen tegen het einde van Kwartaal 3.
    - Dit zal ons nieuwe instapmogelijkheden voor donaties en andere mogelijkheden bieden om lezers om te zetten in donateurs en hen te behouden door hun connecties met de wiki's te verdiepen, inclusief meer gepersonaliseerde inhoud. Dit doel zal zich richten op het introduceren van nieuwe instappunten en het itereren van bestaande instappunten op apps en web, in samenwerking met het fondsenwervingsteam.
  - Belangrijkste resultaat WE3.8: Aan het einde van Kwartaal 4 moet er ten minste één experiment per platform (web en apps) opschalen dat verbetering in retentie of een indicator-metriek voor actieve lezers in een testomgeving laat zien, waarbij een leidraad wordt bewaakt die geschikt is voor de functie.
    - Dit zal zich richten op schaalfuncties die veelbelovend zijn in het verbeteren van betrokken lezersbehoud (of gerelateerde indicatormetriek) over web en apps, gebaseerd op experimentresultaten uit de Kwartalen 1 en 2. Dit omvat het opschalen van de leeslijst op het web (om accountaanmaak en interne doorverwijzingssnelheid te stimuleren), het tabblad activiteit op iOS (voor accountaanmaak en -behoud), en een mogelijk langere productieanalyse van tabblad activiteit op Android (al uitgebracht) om verbeteringen in het behoud van functies te valideren.
  - Belangrijkste resultaat WE3.9: Aan het einde van Kwartaal 4 moet ten minste één experiment per platform (web en apps) worden uitgevoerd dat een verbetering van het retentievermogen of een indicatormetingen voor uitgelogde lezers in een testomgeving toont, waarbij een voor de functie geschikte grenswaarde wordt gevolgd.
    - Hiermee zullen we succesvolle experimenten uitbreiden die bewezen hebben een hoge waarde te bieden aan lezers, nieuw en inactief, die nu niet aan wiki-projecten deelnemen. We zullen verbeteringen op schaal brengen die gericht zijn op uitgelogde lezers ervaringen die kennis zoeken ondersteunen - ervaringen van contentontdekking, visuele presentaties en modaliteiten voor het delen (kennis, inhoud, onderwerpen van belang). Dit punt strekt zich uit over mobiele web- en appsplatforms (iOS en Android).
  - Belangrijkste resultaat WE3.10: Tegen het einde van Kwartaal 4 voeren we ten minste één experiment per platform uit (web en apps) dat een praktisch significante verbetering laat zien in het behouden van uitgelogde casual lezers of een andere indicator-meting over controle (waarbij casual lezersbehoud wordt gedefinieerd als 21-daagse cumulatieve behoud voor web, en 14-dagen cumulatieve behoud voor apps).
    - We blijven investeren in experimenten die de waarde van Wikipedia overbrengen aan lezers, zowel nieuw als inactief, die zich nu niet met wiki-projecten bezighouden. We zullen verbeteringen aan de ervaring van de uitgelogde lezer testen met als focus op contentdiscovery (bijv. Minerva TOC, semantische zoekopdracht, Q&A), visuele presentaties (bijv., visueel aantrekkelijke linkkaarten) en de modaliteiten voor delen (bijv, delen van actie). Dit punt omvat het web (mobiele en desktop, hoewel met de nadruk op mobiele door het publiek) en apps (iOS en Android).

Safety and Security (WE4)

Doel: Onze systemen beschermen standaard de accounts en privégegevens van onze bewerkers beter, terwijl ze meer mogelijkheden bieden voor bewerkers en gebruikers met uitgebreide rechten om misbruik te voorkomen en erop te reageren. Discussie
Belangrijkste resultaat WE4.1: Implementeer een levensvatbaar en werkend incidentrapportagesysteem op al onze wiki's, dat wordt gebruikt en geaccepteerd door hun gemeenschappen, tegen het einde van Kwartaal 2.
- Het verzekeren van de veiligheid en het welzijn van de gebruikers is een fundamentele verantwoordelijkheid van ons platform. Veel jurisdicties hebben regelgeving die vereist dat online platforms zoals het onze om toezicht te houden en actie te ondernemen tegen intimidatie, cyberpesten en andere schadelijke inhoud op hun platform. Als deze niet worden aangepakt, kunnen platforms worden blootgesteld aan wettelijke aansprakelijkheid en wettelijke sancties.
- We willen onze gebruikers in staat stellen om onmiddellijke dreigingen van schade te melden via een gemakkelijk te ontdekken en intuïtief meldingsmechanisme om ervoor te zorgen dat we in staat zijn om te leren over dergelijke incidenten en om snel actie te ondernemen indien nodig. Dit is een stap om onze gebruikers veilig te laten voelen bij het bijdragen aan ons platform. We doen dit door een incidentenrapportering systeem op onze wiki's te implementeren.
Belangrijkste resultaat WE4.2: Verbeter de nauwkeurigheid en effectiviteit van anti-misbruikhulpmiddelen door 2 verbeteringen eind Kwartaal 2.
- Wij en onze gemeenschap moeten niet-authentieke en kwaadaardige activiteiten op de wiki's beter detecteren en voorkomen. We zullen dit doen door het aantal en de kwaliteit van de signalen die beschikbaar zijn voor het platform te vergroten, deze signalen te combineren met hulpmiddelen die we beschikbaar stellen aan gebruikers met uitgebreide rechten, en te identificeren waar we veilig geautomatiseerde beperkingen kunnen opleggen aan verdachte activiteiten.
- We zien ook mogelijkheden om tegelijkertijd de toegankelijkheid van Wikipedia en onze andere projecten te verbeteren. Een van de projecten is bijvoorbeeld het vervangen van de zeer conventionele zelfbeheerde CAPTCHA van de wiki's, die de gebruiker ervan weerhoudt in te loggen totdat hij een puzzel heeft opgelost, door een risicoscoreservice die de gebruiker zelden uitdaagt. In plaats daarvan zou het accounts stilletjes taggen met een niveau van achterdocht dat we kunnen gebruiken om functionaliteit uit te schakelen, en deze status zichtbaar maken voor moderators met hoge privileges om te helpen bij hun werk.
- Meer in het algemeen zijn Wikimedia-projecten sterk afhankelijk van het blokkeren van IP-adressen om misbruik door kwaadwillenden te beperken. Dit is steeds minder effectief in het stoppen van misbruik en heeft een negatieve invloed op gebruikers te goeder trouw die worden beïnvloed door IP- en IP-bereikblokkades. In deze KR streven we ernaar om bestaande mogelijkheden te verbeteren en nieuwe tools te leveren die het mogelijk maken om kwaadwillenden nauwkeuriger en effectiever te blokkeren en de nevenschade veroorzaakt door IP- en IP-bereikblokken te verminderen.
- Om onze effectiviteit te meten, zullen we kijken naar kwalitatieve feedback van vrijwilligers die zich bezighouden met anti-misbruikwerk, en kwantitatieve indicatoren zoals de snelheid van IP-blokkades die worden ingezet, de acceptatie van IP-reputatie en op browsersignalen gebaseerde mitigaties, de snelheid van waarschijnlijk-menselijke interacties wanneer een gebruiker wordt geblokkeerd, en de acceptatie van nieuwe signalen van hulpmiddelen voor anti-misbruik.
- Het werk in deze KR omvat verbeterde detectie en beperking van sockpuppet- en banontwijking, het naar boven halen van informatie over het potentieel voor nevenschade, het versterken van bot-detectie, het naar boven halen van signalen aan anti-misbruik vrijwilligers, verbeterde efficiëntie de interfaces van hulpmiddelen voor anti-misbruik, het verbeteren van statistieken met betrekking tot misbruik en het verstrekken van suggesties voor verdachte accountactiviteit voor onderzoek aan CheckUsers.
Belangrijkste resultaat WE4.3: Verminder, tegen het eind van Kwartaal 4, het aantal grootschalige aanvallen waarvoor menselijke tussenkomst in SRE vereist is met 50% (vergeleken met boekjaar 2019)
- De evolutie van het internetlandschap, met inbegrip van de opkomst van botnetten op grote schaal en frequente aanvallen, heeft onze traditionele methoden om grote schaalmisbruik te beperken, verouderd gemaakt. Dergelijke aanvallen kunnen onze sites niet beschikbaar maken door onze infrastructuur te overspoelen met verzoeken, of het vermogen van onze gemeenschap om grootschalige vandalisme te bestrijden, overweldigen. Dit brengt onze geprivilegieerde redacteurs en onze technische gemeenschap ook onder onredelijke druk.
- We moeten dringend ons vermogen verbeteren om dergelijke aanvallen automatisch te detecteren, te weerstaan en te beperken of te stoppen.
- Dit jaar zullen we ons vooral richten op het automatiseren van het detecteren van IP-adressen en netwerken die regelmatig aanvallen tegen ons doen, en het verminderen van de hoeveelheid belasting die de aanhoudend schadelijke entiteiten op onze systemen mogen plaatsen.
Belangrijkste resultaat WE4.4: Vanaf Kwartaal 2 zijn tijdelijke accounts bij 100% van onze projecten geïmplementeerd, waardoor de persoonlijke, identificeerbare informatie van onze niet-geregistreerde redacteuren beschikbaar is voor minder dan 0,1% van de gebruikers.
- Tijdelijke accounts zijn bedoeld om de privacy en daarmee de veiligheid van onze niet-geregistreerde redacteuren te verbeteren door hun persoonlijk identificeerbare informatie (IP-adres) te beschermen tegen het publiek en de toegang te beperken tot alleen degenen die deze nodig hebben voor patrouilledoeleinden. Naast een grote verbetering van de veiligheid van de gebruikers is dit project ook belangrijk om aan verschillende wettelijke voorschriften te voldoen.
Belangrijkste resultaat WE4.5: Evalueer de impact van generatieve AI op vertrouwen en veiligheid, en bepaal productinterventies om kansen te benutten en bedreigingen voor Wikimedia-projecten te voorkomen, tegen het einde van Kwartaal 3.
- Het gebruik van AI, en in het bijzonder generatieve AI, neemt snel toe op het internet. Er zijn kansen voor vertrouwen en veiligheid, maar ook bedreigingen die ontstaan nu AI alomtegenwoordig wordt. Content is bijvoorbeeld gemakkelijker en goedkoper te genereren, maar moderatie vereist meer inspanning. Ook kan onderzoek met veel minder moeite worden uitgevoerd, maar AI-hallucinaties zijn moeilijk te identificeren.
- Dit project is gericht op de 'Human Rights Impact Assessment' van ML/AI, door de impact van AI op vertrouwen en veiligheid van het ecosysteem van Wikimedia te beoordelen. Dit omvat:
  - Overleg met gebruikers met uitgebreide rechten.
  - Voorbeelden identificeren van generatief AI-ondersteund misbruik en mogelijke verminderingen.
  - Het identificeren van ML-mogelijkheden om de werklast voor gebruikers met uitgebreide rechten te verminderen.
  - Experimenten uitvoeren om te begrijpen waar we ons op moeten concentreren om de meeste impact te maken.
Belangrijkste resultaat WE4.6: Technisch afdwingen dat 100% van de privileges die gebruikers in staat stellen om beveiligings- of privacygevoelige acties uit te voeren, alleen kunnen worden uitgevoerd door accounts die tweefactorauthenticatie hebben ingeschakeld, tegen het einde van Kwartaal 4.
- We moeten de beveiliging van de gebruikersaccounts op onze wiki's versterken, vooral voor gebruikers met gevoelige rechten. Een belangrijk aandachtspunt is de eis dat gevoelige acties alleen kunnen worden ondernomen door gebruikers die tweefactorauthenticatie (2FA) hebben ingeschakeld. We zullen een uitgebreider systeem bouwen voor het afdwingen van bevoegdheden dat de noodzaak van audits en handmatige handhaving van 2FA omzeilt, en uitbreiden welke rechten vereisen dat 2FA op het platform wordt ingeschakeld.
- Als onderdeel hiervan zullen we onze authenticatie- en herstelsystemen verbeteren, zodat wij (WMF) en onze gebruikers gemakkelijker een strengere houding ten opzichte van 2FA kunnen ondersteunen. We zullen de algemene beschikbaarheid van 2FA op het hele platform uitbreiden, zodat elke gebruiker het naar wens kan inschakelen en ervoor kan zorgen dat het wordt ingeschakeld voordat gevoelige rechten worden verleend. We zullen ook onze aandacht richten op het verminderen van de operationele belasting die wordt gedragen door onze accountherstel- en ondersteuningssystemen, om onze reset- en herstelprocessen rond het inloggen op accounts te stroomlijnen. We zijn verder van plan om de bruikbaarheid van onze 2FA-implementatie te verbeteren door gebruikers meer opties te bieden om hun accounts te beveiligen en onbedoelde vergrendeling te voorkomen.
Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
- This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
- The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
  We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
- For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
- In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
- We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
- This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
- During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
- We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
- In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
- We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Verantwoord gebruik van infrastructuur (WE5)

Doel: Ontwikkelaars en hergebruikers krijgen toegang tot kennisinhoud via zorgvuldig samengestelde paden. Zo garanderen we de duurzaamheid van onze infrastructuur en verantwoord hergebruik van inhoud. Discussie
- Objectieve context: Deze doelstelling zal zich richten op het creëren van paden voor verantwoord hergebruik van content.
- Wikimedia beheert de grootste collectie door mensen samengestelde kennis op het web. Dit heeft onze kennisinfrastructuur tot een onschatbare bron gemaakt, niet alleen voor mensen, maar ook voor automatische dataconsumenten. Onze content wordt gebruikt in zoekmachines, socialemedia-platforms, e-commerce en sinds de opkomst van AI wordt het gebruikt om grote machine learning-modellen te trainen. Consumenten verkrijgen data door het scrapen van pagina's, door API's te gebruiken en door content te downloaden – meestal zonder bronvermelding. In de wereld van niet-geverifieerd verkeer kunnen we de ene gebruiker niet betrouwbaar van de andere onderscheiden, wat onze mogelijkheden om verantwoord gebruik van onze infrastructuur mogelijk te maken en af te dwingen sterk beperkt. Hoe kunnen we onze community blijven ondersteunen en tegelijkertijd grenzen stellen aan automatisch contentgebruik? Hoe kunnen we gebruikers naar voorkeurskanalen leiden die worden ondersteund? Welke richtlijnen hebben we nodig om verantwoord hergebruik van content te stimuleren? Hoe kunnen we een samenhangende ontwikkelervaring creëren en producten bouwen die voldoen aan de behoeften van zowel vrijwillige ontwikkelaars, medewerkers als hergebruikers? Hoewel deze vragen niet allemaal nieuw zijn, is de urgentie om ze aan te pakken exponentieel toegenomen: sinds 2024 zien we een dramatische stijging in het aantal verzoeken, waarbij het grootste deel van de toename afkomstig is van scraping bots die trainingsgegevens verzamelen voor AI-gestuurde workflows en producten. De belasting van onze infrastructuur is niet houdbaar en brengt de menselijke toegang tot kennis in gevaar: we moeten nu actie ondernemen om een gezonde balans te herstellen, zodat we de Wikimedia-projecten effectief kunnen ondersteunen en het blijvende succes van onze missie kunnen waarborgen.
  - Belangrijkste resultaat WE5.1: Tegen het einde van Kwartaal 4 kan 50% van de verzoeken van programmatische toegang worden toegeschreven aan een bekende ontwikkelaar of applicatie.
    - We hebben nu beperkte mogelijkheden om te identificeren wie verantwoordelijk is voor geautomatiseerd verkeer en, in tegenstelling tot on-wiki, beperkte mogelijkheden om contact op te nemen met gebruikers of hun toegang te reguleren. We hebben een aanzienlijke toename gezien in het volume van extern geautomatiseerd verkeer, wat voor ons niet houdbaar is en de menselijke toegang tot kennis in gevaar brengt. We streven ernaar het percentage geautomatiseerd verkeer dat aan een bekend account wordt toegeschreven te verhogen door authenticatie en autorisatie te vereisen op basis van gelaagde toegangsniveaus voor grootschalige scraping en API-gebruik. Dit zal ons helpen te identificeren wie content op grote schaal hergebruikt, waardoor we onze infrastructuur kunnen beschermen en de governance rond fair use kunnen verbeteren, terwijl we effectiever aan hun behoeften voldoen. We zullen ook onderzoeken hoe we de technische community beter kunnen ondersteunen met een meer samenhangende ontwikkelervaring die voorkeurstoegang voor communityleden beschermt en nieuwe functionaliteit voor ontwikkelaars mogelijk maakt.
  - Belangrijkste resultaat WE5.2: Tegen het einde van Kwartaal 4 zal 70% van de Wikimedia web API-endpoints worden ondersteund door een gemeenschappelijke infrastructuur.
    - We streven ernaar de ervaring en duurzaamheid van onze ontwikkeltrajecten te verbeteren door consistentere, stabielere en vindbaardere web-API's aan te bieden voor alle Wikimedia-ontwikkelaars. We vereenvoudigen ons API-aanbod door een meer gecentraliseerde infrastructuur te introduceren voor de belangrijkste API-functionaliteiten. Dit stelt ons in staat om consistente trajecten en governance te bieden voor: OpenAPI-specificaties en -documentatie, identificatie en toegangscontrole van ontwikkelaars, handhaving van API-beleid, routering, versiebeheer en foutafhandeling. Door ons API-aanbod te stroomlijnen, maken we het sneller, eenvoudiger en aantrekkelijker om hulpmiddelen, bots, onderzoeksprojecten en functies te bouwen die de Wikimedia-missie dienen. Dit jaar richt zich op het bouwen van fundamentele infrastructuur en functies, met als MVP-doel dat 70% van de API-endpoints ten minste één functie uit de drie hoofdgebieden van API-infrastructuur moet overnemen: Hoe API's worden gebouwd om consistentie en kwaliteit te waarborgen; hoe API's worden gepresenteerd aan Wikimedia-ontwikkelaars; en hoe de onderliggende infrastructuur wordt gebruikt om onze API's te bedienen, te observeren en de toegang te beheren.Deze aanpak ondersteunt de multigenerationele toekomst van de missie door de onderhoudskosten voor de API-infrastructuur te verlagen, de zichtbaarheid en toegangscontrole te vergroten om kwaadwillenden te bestrijden en een sterkere ontwikkelcommunity te bevorderen.
  - Belangrijkste resultaat WE5.3: Tegen het einde van Kwartaal 4 worden nieuwe framework voor toeschrijving voor het web, apps, spraakassistenten en LLM's gepubliceerd en gekoppeld op alle Wikimedia-sites, met twee hergebruikdemo's die meetbare betrokkenheid genereren en één externe hergebruikpartner die beste aanpakken voor toeschrijving toepast.
    - Om de juiste toeschrijving van Wikimedia-content te verbeteren, zullen we duidelijke richtlijnen voor beste aanpakken opstellen die verantwoord hergebruik bevorderen. Dit omvat het opstellen van framework voor toeschrijving voor belangrijke platforms (web, apps, spraak, multimedia) en het tonen van ten minste twee praktische voorbeelden die exemplarische toepassingen van Wikimedia-content benadrukken. Voorbeelden van resultaten zijn het stimuleren van mediaorganisaties om Wikimedia Commons-afbeeldingen te crediteren, zoekmachines om relevante Wikimedia-data effectiever te presenteren, of AI-assistenten om Wikipedia-kennis op transparante en verantwoorde wijze te integreren, wat het vertrouwen in hun betrouwbaarheid vergroot. Het versterken van toeschrijvingspraktijken vergroot niet alleen de publieke bekendheid en stimuleert de betrokkenheid bij Wikimedia-projecten, maar helpt ook bij het ontwikkelen van verantwoorde en nieuwe manieren om kennis te remixen en misbruik te ontmoedigen.
  - Belangrijkste resultaat WE5.4: Verminder de hoeveelheid verkeer die door scrapers wordt gegenereerd met 20%, gemeten in termen van aanvraagsnelheid, en met 30% in termen van bandbreedte
    - Scraping is er altijd al geweest: zoekmachines vertrouwen al tientallen jaren op Wikipedia om hun gebruikers van informatie te voorzien. Maar sinds kort is er een andere belangrijke reden om onze data te scrapen: het is de grootste gecureerde, meertalige verzameling kenniscontent die u op internet kunt vinden en het is een fundamenteel hulpmiddel om grote taalmodellen te trainen. Dit geldt zowel voor onze encyclopedische content als voor onze multimediadatabase Wikimedia Commons, die van onschatbare waarde is voor machine learning-modellen die afbeeldingen genereren.
    - Als gevolg hiervan hebben we het afgelopen jaar een aanzienlijke toename gezien in het aantal scraper-gerelateerde verkeer en ook in de daarmee samenhangende incidenten met site-stabiliteit: Site Reliability Engineers hebben herhaaldelijk van geval tot geval snelheidsbeperkingen of blokkeringen voor crawlers moeten afdwingen om onze infrastructuur te beschermen. Scraping is zo prominent geworden dat onze uitgaande bandbreedte in 2024 met 50% is toegenomen. Bovendien toonde een recente analyse aan dat minstens 65% van onze duurste verzoeken (de verzoeken die we niet kunnen verwerken vanaf onze cachingservers en die in plaats daarvan via de hoofddatabases worden verwerkt) door bots worden uitgevoerd.
    - Onze computerbronnen zijn zeer beperkt in vergelijking met de hoeveelheid dataverkeer die we genereren. We moeten daarom prioriteiten stellen voor de mensen die we met die bronnen bedienen. Daarnaast willen we menselijke consumptie stimuleren en prioriteit geven aan het ondersteunen van Wikimedia-projecten en -bijdragers met onze schaarse bronnen.

Het pad versnellen naar productresultaten (WE6)

Doel: Wikimedia-ontwikkelaars kunnen hun producten snel en met vertrouwen aan eindgebruikers aanbieden. Discussie
- Objectieve context: Om effectief te zijn in het realiseren van de vier strategische pijlers, moeten Wikimedia-ontwikkelaars hun tijd en moeite besteden aan activiteiten met een hoog rendement die resulteren in het zo snel mogelijk opleveren van kwaliteitsproducten. Te ingewikkelde workflows, een gebrek aan standaardhulpmiddelen en onhoudbare systeemcomponenten staan deze resultaten in de weg.
- Dit werk bouwt voort op het momentum dat we hebben opgebouwd tijdens de afgelopen twee jaarplannen, waarbij MediaWiki als platform en de software die de ontwikkeling en implementatie ervan ondersteunt, verder zijn ontwikkeld. De werkzaamheden voor dit jaar zullen zich richten op het bieden van betrouwbaardere ontwikkelomgevingen, het vereenvoudigen van pre-productieworkflows en het verminderen van platform- en infrastructuurrisico's.
  - Belangrijkste resultaat WE6.1: Tegen het einde van Kwartaal 4 is het aantal bugs die de testwiki's passeren, met 10% verminderd
    - In 2024 moesten ontwikkelaars 144 keer hun werk herzien omdat er een noodsituatie was die de implementatie van MediaWiki verhinderde. In veel van die gevallen werden de bugs ontdekt nadat ze waren geïmplementeerd op testwiki's, wat betekent dat het probleem een potentieel publiek van miljarden gebruikers bereikte. We hebben geen controle over het feit dat er bugs zullen zijn, maar als we ze eerder zouden ontdekken, is er minder heldenwerk nodig. Het zou ontwikkelaars ook het vertrouwen geven dat er geen grote problemen zullen zijn als iets daadwerkelijk in productie gaat.
    - We zullen deze bugs eerder opsporen door omgevingen te creëren die ontwikkelaars nodig hebben om hun code met vertrouwen te leveren en te testen gedurende de hele ontwikkel- en implementatiecyclus. We moeten er ook voor zorgen dat deze verbeteringen niet ten koste gaan van de snelheid van ontwikkelaars.
  - Belangrijkste resultaat WE6.2: Tegen het einde van Kwartaal 4 kunnen 4 stappen uit de checklist voor de productiegereedheid worden uitgevoerd zonder SRE-interventie
    - Het implementeren van een nieuwe service of feature in productie is nu afhankelijk van een lijst met 24 stappen, waarbij elke stap doorgaans ondersteuning van SRE's vereist. We hebben het SRE-ambassadeursprogramma opgezet om eerder in de ontwikkelcyclus in te grijpen en capaciteit binnen de ontwikkelteams zelf op te bouwen, maar veel van de taken zouden volledig zelf te beheren moeten zijn. Momenteel komt dit neer op handmatig, repetitief en te automatiseren werk dat lineair schaalt met het aantal ontwikkelteams. Dit is op de lange termijn niet houdbaar voor het SRE-team.
    - In het verleden werd een groot deel van dit werk aan ontwikkelteams overgelaten door een set gedeelde, gemeenschappelijke bibliotheken en beste aanpakken te onderhouden voor de interactie met ons platform. Deze zijn verdwenen toen we overstapten naar onze nieuwe Kubernetes-infrastructuur en er is geen directe vervanging. Door vergelijkbare bibliotheken, documentatie en training te bieden die van toepassing zijn op de manier waarop we vandaag de dag bouwen en implementeren, geloven we dat we de benodigde betrokkenheid van SRE kunnen verminderen voordat een nieuwe service of functie in productie wordt genomen.
  - Belangrijkste resultaat WE6.3: Tegen het einde van Kwartaal 4 worden 100% van de Wikipedia-paginaweergaven via Parsoid verzorgd
    - Parsoid biedt verbeterde mogelijkheden voor wikitext-ontwikkeling en toekomstbestendigheid van het platform. Het gelijktijdig onderhouden van twee parsers is op de lange termijn niet houdbaar, omdat dit de technische schuld en complexiteit vergroot. Bovendien hangt het succes van sommige nieuwe projecten zoals Wikifunctions af van de brede beschikbaarheid van Parsoid.
    - We hebben de uitrol op kleinere projecten uitgebreid en dit jaar zullen we klaar zijn voor de Wikipedia's. Het bedienen van alle pagina-voorzieningen van Wikipedia door Parsoid is de belangrijkste volgende mijlpaal. Naast de uitrol zelf omvat dit werk ook het oplossen van prestatieproblemen en het effectief communiceren over de impact aan lezers en redacteuren.
  - Belangrijkste resultaat WE6.4: Tegen het einde van Kwartaal 2 zijn ten minste twee geïdentificeerde risico's die onze mogelijkheid om de wiki's te blijven implementeren of opschalen bedreigen, verminderd of teruggebracht tot een acceptabel niveau
    - Door middel van een aantal gerichte initiatieven zullen we diverse risico's op het gebied van schaalbaarheid, betrouwbaarheid en beveiliging verminderen of beperken die wij hebben geïdentificeerd als een waarschijnlijke potentiële bedreiging voor de groei en duurzaamheid van ons platform en onze openbare projecten.
    - Zo zullen we bijvoorbeeld de structuur van de kerndatabases van Commons refactoren om ervoor te zorgen dat de groei ervan de komende jaren niet wordt beperkt door de capaciteit van de beschikbare serverhardware. Ook zullen we PHP, de programmeertaal die MediaWiki en gerelateerde diensten aanstuurt, upgraden naar een modernere versie. Andere geïdentificeerde risico's zullen waarschijnlijk aanvullende beveiligingsmaatregelen vereisen om onze infrastructuur te beschermen en te versterken.
  - Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
    - One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
    - Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
    - With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
    - Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
  - Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
    - Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
    - To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
    - By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
  - Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
    - Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Signalen en datadiensten (SDS)

Metingen (SDS1)

Doel: Besluitvormers gebruiken meer betrouwbare en actuele metingen om over product- en strategische beslissingen te informeren. Discussie
- Objectieve context: We gebruiken statistieken om de Foundation te informeren over waar we onze inspanningen op moeten richten om de beweging zo goed mogelijk van dienst te zijn. Sommige van onze datapijplijnen zijn echter gevoelig voor storingen, wat leidt tot vertragingen in de levering. Wanneer er dataproblemen optreden, is de tijd tot identificatie en oplossing te lang. Bovendien zijn veel van onze datasets niet geoptimaliseerd voor eenvoudige verkenning van trends en ontbreken dimensies die belangrijk zijn gebleken voor de interpretatie van de data. Deze problemen vertragen en beperken ons vermogen om metingen te evalueren.
- In boekjaar 25-26 richten we ons op onze specifiek jaarplan use-cases als cases voor het oplossen van hiaten in de gegevenskwaliteit in onze huidige pijplijnen, het opzetten van infrastructuur en processen voor het bewaken en oplossen van problemen met de gegevenskwaliteit en het leveren van hulpmiddelen waarmee besluitvormers trends kunnen begrijpen.
- Eén use-case gaat over hoe we menselijk en botverkeer meten. De opkomst van geautomatiseerd verkeer in de afgelopen jaren heeft het moeilijker gemaakt om te begrijpen in hoeverre mensen interactie hebben met en bijdragen aan Wikimedia-projecten. We streven ernaar onze mogelijkheden te verbeteren om patronen in menselijk en botverkeer te evalueren, die cruciale input vormen voor plannings- en productbeslissingen.
  - Belangrijkste resultaat SDS1.1: Tegen het einde van Kwartaal 1 hebben analisten die gebruikmaken van paginaweergave-statistieken toegang tot basismetingen van de datakwaliteit en metingen van de prestaties van geautomatiseerde verkeersdetectieheuristieken
    - Met behulp van de hypothesen die in deze KR worden onderzocht, willen we hiaten in onze huidige geautomatiseerde heuristiek voor verkeersdetectie identificeren en begrijpen waar deze tekortschiet in het correct categoriseren van paginaweergaveverkeer. Deze inzichten zullen leiden tot verbeteringen in de pipelines die paginaweergavestatistieken genereren en classificeren. Daarnaast zullen we datakwaliteitsstatistieken definiëren om verbeteringen in de nauwkeurigheid van de gegevens te monitoren en te meten.
    - Deze KR legt de basis voor een vervolg-KR gericht op de implementatie van de hier geïdentificeerde noodzakelijke verbeteringen aan de pijplijn. De in deze fase vastgestelde datakwaliteitsmaatstaven zullen dienen als benchmarks om de effectiviteit van deze toekomstige verbeteringen te beoordelen.
  - Belangrijkste resultaat SDS1.2: Tegen het einde van Kwartaal 1, al de inhoud van de MediaWiki inhoudsgeschiedenis dataset zal beschikbaar zijn via een bestandsexport met wekelijkse leveringsgaranties (SLO's). De geëxporteerde bestandsgegevens zijn gelijk aan die van de verouderde XML-dumps 1-exportpipeline.
    - Het doel van FY24/25 KR 1.4 was om de afhankelijkheid van de maandelijks bijgewerkte datasets mediawiki_wikitext_history en mediawiki_wikitext_history_current voor de drie meest relevante downstream-pijpleidingen te verwijderen en een alternatieve dataset te bieden met gegarandeerde wekelijkse SLO's.
    - Hoewel KR 1.4 voor boekjaar 24/25 de betrouwbaarheidsproblemen voor de meest relevante afhankelijke pipelines heeft verholpen, zijn er nog steeds pipelines met de onbetrouwbare oude invoerbron. Deze zouden ook gemigreerd moeten worden, evenals de bestandsgebaseerde invoerbron naar de wikitext-historische dataset zelf.
  - Belangrijkste resultaat SDS1.3: Tegen het einde van Kwartaal 2 neemt botdetectie 1 extra signaal op en genereert geautomatiseerde waarschuwingen bij afwijkingen.
    - In de hele Foundation nemen teams product- en financieringsbeslissingen op basis van het kunnen bepalen van het verschil tussen menselijk lezerspubliek en geautomatiseerd verkeer. Het Data Platform is de centrale opslagplaats voor botdetectiesignalen en batchanalyse. Aan de hand van de hypothesen die we in de eerste 2 kwartalen hebben opgesteld, zijn we van plan om te beginnen met het introduceren van nieuwe botdetectiesignalen om onze analyse van geautomatiseerd verkeer aan te scherpen, en om te beginnen met het introduceren van nieuwe signalen die zowel efficiënt als herhaalbaar zijn.
  - Belangrijkste resultaat SDS1.4: Tegen het einde van Kwartaal 2 hebben besluitvormers een duidelijk inzicht in de huidige staat van inzichten die worden geboden door onze organisatorische statistieken. We weten dat we succesvol zijn als we een presentatiedesk bieden dat klaar is voor een bestuursvergadering en dat de analyse van onze statistieken situeert binnen zowel het Wikimedia-ecosysteem, als binnen bredere internettrends en uitdagingen in de markt.
    - Inzichten door onze organisatiestatistieken worden gebruikt om een groot aantal beslissingen te nemen in de hele Foundation, waaronder beslissingen over hoe we ons product bouwen, hoe we infrastructuurbronnen toewijzen en hoe we geld inzamelen. Tegelijkertijd evolueert het landschap van het internet, waarbij met name geautomatiseerd verkeer van invloed is op onze statistieken. Het doel is dat de leiding van de Foundation de bestuursvergadering van december ingaat met een duidelijk verhaal over bedreigingen voor en kansen binnen het Wikimedia-ecosysteem, ondersteund door een betrouwbare analyse van interne statistieken en externe trends. We kunnen dit verhaal vertellen door inzichten, statistieken en gegevenspunten te verzamelen die ons met vertrouwen vertellen over:
      - Trends in onze interne metingen van lezerspubliek (paginaweergaven)
      - Trends in ons ecosysteem van bijdragers
      - Trends uit externe gegevens en benchmarks van concurrenten
      - Inzichten door interne en externe onderzoeken en betrouwbaar onderzoek
  - 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.

Experimenteerplatform (SDS2)

Doel: Productmanagers kunnen snel, eenvoudig en met zekerheid de impact van wijzigingen in productfuncties op Wikipedia evalueren. Discussie
- Objectieve context: Om data-gedreven besluitvorming over de ontwikkeling van productfuncties mogelijk te maken en te versnellen, hebben productmanagers een experimentenplatform nodig waarmee ze functies kunnen definiëren, doelgroepen voor gebruikers kunnen selecteren en de impact kunnen meten. Het verkorten van de tijd tussen lancering en analyse is cruciaal, aangezien het verkorten van de leertijd experimenten en uiteindelijk innovatie zal versnellen. Handmatige taken en op maat gemaakte meetmethoden worden gezien als belemmeringen voor snelheid. Het ideale scenario is dat productmanagers van de lancering van een experiment tot de ontdekking kunnen komen met weinig tot geen handmatige tussenkomst van engineers en analisten.
- We richten ons het komende boekjaar op Wikipedia, omdat Core Experiences daar graag mee wil experimenteren (de organisatiestrategie vereist dat we ons volledig op Wikipedia richten), en omdat het ons in staat stelt om te focussen en duidelijker aan te geven met welke teams en projecten we bezig zijn. Andere teams hebben de componenten van het experimentele platform gebruikt en zullen dat mogelijk blijven doen, maar dat gebruik zal niet de focus van deze doelstelling zijn.
  - Belangrijkste resultaat SDS2.1: Tegen het einde van Kwartaal 2, maak de voltooiing van ten minste 2 volledige experimentcycli mogelijk met behulp van het experimenteerplatform.
    - Aangezien de organisatie steeds meer nadruk legt op gegevensgebaseerde productbeslissingen, moeten we experimenteren toegankelijk maken voor alle productteams, niet alleen voor degenen met gespecialiseerde vaardigheden. Productteams hebben gedeelde normen, hulpmiddelen en infrastructuur nodig die hen in staat stelt:
      - Snel ideeën testen met onze wereldwijde gebruikers
      - Meten van de impact van productwijzigingen met gestandaardiseerde metingen
      - De resultaten transparant delen met onze belanghebbenden van de movement
    - Waarom wij ons van het aantal geactiveerde teams naar het aantal voltooide experimenten gaan richten:
    1. Strategische afstemming: het is de belangrijkste succesmeting van het platform
    2. Data-geïnformeerde aanpak: Ons gebruikersonderzoek (in progressie) suggereert variabele teambereidheid in de organisatie, terwijl we weten dat het webteam interesse heeft bevestigd in twee specifieke experimenten.
    3. Resource optimalisatie: Onze MVP-platform zal een high-touch onboarding vereisen, waardoor het op korte termijn efficiënter is om te focussen op experimentele mogelijkheden in plaats van een breed netwerk te maken over meerdere teams. Wij zijn van plan om naar een algemene vrijstelling te gaan en willen niet opnieuw in trainingsteams investeren, als we dat kunnen voorkomen.
    4. Toekomstgericht: Feedback van de volledige experimentele cycli zal onze platformverbeteringen effectiever informeren dan de leer van de gedeeltelijke of onvolledige adoptie. Als we verder gaan naar algemene release, focussen op het voltooien van het experiment vermijdt het investeren in tijdelijke benaderingen die opnieuw moeten worden ontwikkeld.
    - We zijn bezig met gebruikersonderzoek om de behoeften en eisen van het team te bepalen: enquêtes en interviews zijn gepland om de behoeften van het productteam in de tweede helft van mei 2025 duidelijk te maken. Zodra het onderzoek is afgerond, maken we een experimentatie kalender die kan worden gebruikt om onze volgende KR-doelstellingen en prioriteiten te bepalen.
  - Belangrijkste resultaat SDS2.2: Voor het einde van Kwartaal 3 kunnen de resultaten van ten minste één webexperiment worden geanalyseerd en bekeken in GrowthBook.
    - Na een lang en moeizaam proces hebben we uiteindelijk besloten om GrowthBook te integreren als een experimentele oplossing van derden die experimentele markeringen, geautomatiseerde analyse en dashboarding biedt, met ondersteuning voor grens-metingen. Experiment Platform is van plan de gebruikersinterface om experimenten te definiëren en uit te rollen (1) en de experiment-analysepijplijn (5) te vervangen door GrowthBook.
    - Vanwege de risico's die verbonden zijn aan deze integratie, is het Experiment Platform Team van mening dat GrowthBook eerst moet worden geïntegreerd als een experiment-analysepijplijn omdat het niet-ontwrichtend is en omdat het de grootste bron van risico's is.
    - De architectonische beslissingen die we hebben genomen tijdens het boekjaar 24/25 SDS2 en de modulariteit van GrowthBook, stellen ons in staat om delen van het Experimentation Lab uit de orde te vervangen, d.w.z. dat WMF-personeel experimenten met xLab UI kan definiëren en implementeren terwijl ze met GrowthBook worden geanalyseerd. Verder kunnen we de huidige experimentele-analysepijplijn en GrowthBook's parallel uitvoeren, die vergelijkingen naast elkaar en User Acceptance Testing in real-world scenario's mogelijk maakt.
  - Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
    - After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
      In making GrowthBook the source of truth for experiment configuration, we aim to:
      - Reduce coordination when running an experiment
      - Enable more frequent and repeatable experimentation
      - Clearly delineate between instruments and experiments
      - Move toward a mental model centered on metrics rather than instruments
  - Belangrijkste resultaat SDS2.4: Ten minste 14 van de 20 productteams hebben Test Kitchen gebruikt om een strategische beslissing voor een OKR-initiatief te nemen, tegen het einde van Kwartaal 4.
    - Het werk dat onder SDS2.1 is verricht, heeft een kritisch inzicht geopenbaard: het bouwen van een experimentele platform is niet voldoende - Product & Tech teams worden geconfronteerd met enkele barrières voor de adoptie. Hoewel de teams waarde zien, hebben ze vaak geen tijd, infrastructuur, instrumenten of vertrouwen om te beginnen. Daarnaast kunnen zij technische blokkers tegenkomen die door een doordacht partnerschap moeten worden aangepakt.
    - Met SDS2.4 verplaatst onze focus van bouwen naar het schalen van adoptie. Door te blijven samenwerken met teams die aan boord zijn van het platform, technische barrières overwinnen en praktische migratieondersteuning bieden, willen we experimenteren consolideren op Test Kitchen als het verenigde platform voor productteams, waardoor snelle, self-service testcycli mogelijk worden die afhankelijkheid van engineering en analytische ondersteuning verminderen.
    - Deze punt werd gepland nadat we besloten hadden SDS2.2 in twee stukken te delen, en daarom werd de nummering beïnvloed. SDS2.3 is een komend punt die sequentieel is met GrowthBook for experimentele analyse.

Toekomstige gebruikers (Future Audiences, FA)

Toekomstige gebruikers (FA1)

Doelstelling: De Wikimedia Foundation heeft nu aanbevelingen over strategische investeringen die onze beweging kan doen om een nieuw publiek te bedienen in een veranderend internet. Discussie
- Objectieve context: Als gevolg van voortdurende veranderingen in technologie en online gebruikersgedrag (bijv. toenemende voorkeur voor het verkrijgen van informatie via sociale apps, populariteit van korte video edu-tainment, de opkomst van generatieve AI), staat de Wikimedia-beweging voor uitdagingen bij het aantrekken en behouden van lezers en bijdragers. Deze veranderingen bieden ook mogelijkheden om een nieuw publiek te bedienen door informatie op nieuwe manieren te creëren en aan te bieden. Wij als beweging hebben echter geen duidelijk, op gegevens gebaseerd beeld van de voordelen en afwegingen van verschillende mogelijke strategieën die we zouden kunnen volgen om de uitdagingen te overwinnen of nieuwe kansen te grijpen. Moeten we bijvoorbeeld...
  - Investeren in grote nieuwe functies zoals chatbots?
  - De kennis en paden van Wikimedia gebruiken om bij te dragen aan populaire platforms van derden?
  - Nog iets anders?
- Om ervoor te zorgen dat Wikimedia een project met meerdere generaties wordt, zullen we hypothesen testen om veelbelovende strategieën beter te begrijpen en aan te bevelen - voor de Wikimedia Foundation en de Wikimedia-beweging - om toekomstig publiek aan te trekken en te behouden.
  - Belangrijkste resultaat FA1.1: Als gevolg van experimentele inzichten en aanbevelingen van Future Audiences is aan het einde van Kwartaal 3 ten minste één doelstelling of belangrijk resultaat dat eigendom is van een niet-Future Audiences-team aanwezig in het ontwerp voor het jaarplan van het volgende jaar.
    - Sinds 2020 volgt de Wikimedia Foundation externe trends die van invloed kunnen zijn op ons vermogen om toekomstige generaties kennisconsumenten en kennisbijdragers van dienst te zijn en een bloeiende vrije kennisbeweging te blijven voor de komende generaties. Future Audiences, een klein R&D-team, zal:
      - Snelle, tijdgebonden experimenten uitvoeren (met als doel ten minste 3 experimenten per boekjaar) om manieren te onderzoeken om op deze trends in te spelen
      - Op basis van inzichten uit experimenten, aanbevelingen doen voor nieuwe niet-experimentele investeringen die WMF zou moeten nastreven - d.w.z. nieuwe producten of programma's die door een volledig team of teams moeten worden overgenomen - tijdens onze reguliere jaarlijkse planningsperiode.
    - Dit belangrijke resultaat wordt bereikt als ten minste één doelstelling of belangrijk resultaat dat eigendom is van een team buiten Future Audiences en wordt aangestuurd door een aanbeveling voor Future Audiences, voorkomt in het conceptjaarplan voor het volgende boekjaar.

Sociale video (FA2)

Objectief: Jonge (jonger dan 25 jaar) mensen houden, leren en zijn betrokken bij en delen Wikipedia-inhoud op platforms waar ze graag tijd online doorbrengen. Discussie
- Objectieve context: Future Audiences-experimenten met korte video dit boekjaar hebben aangetoond dat we op deze platforms op grote schaal een jonger publiek kunnen bereiken, maar onze Brand Health-gegevens laten zien dat onze huidige investering niet voldoende is om de afname van het bewustzijn en de affiniteit met Wikipedia onder het publiek van Gen-Z-leeftijd tegen te gaan.
- Om ervoor te zorgen dat we deze generatie effectief bereiken en betrekken, moeten we volgens ons verschillende tactieken inzetten en onze betrokkenheid op gebieden als betaalde marketing, influencermarketing en creatieve campagnes aanzienlijk vergroten. Ook moeten we inspelen op trends en meer experimenteren op deze kanalen.
- Wij verwachten dat de uitdagingen waar we voor staan, een grotere investering vergen om ze het hoofd te kunnen bieden. Dit geldt met name voor communicatie- en marketinginspanningen om betrokkenheid te creëren, maar ook voor samenwerking tussen afdelingen om nieuwe producten en ervaringen te creëren die erop gericht zijn de aanwezigheid van het merk en de content van Wikipedia op deze platforms te vergroten.
  - Belangrijkste resultaat FA2.1: Genereer 9.500.000 weergaven van korte videocontent op alle eigen kanalen tegen het einde van de eerste helft van het jaar.
    - Dit jaar bereikten we binnen drie maanden na de lancering van de korte video's op de @Wikipedia-kanalen op TikTok, Instagram en YouTube een bereik van ongeveer 1 miljoen views. Aan het begin van het volgende fiscale jaar verwachten we meer volgers op onze eigen kanalen en meer inzichten in effectieve/boeiende content die we in de praktijk kunnen brengen om nog meer kijkers te bereiken.
    - Door in de eerste helft van het jaar een ambitieus doel te stellen, hopen we een grotere impact te creëren, ruimte te maken voor het creëren van nieuwe strategieën/processen om het werk te vergemakkelijken en te kunnen pleiten voor extra middelen om dit doel te bereiken.
  - Belangrijkste resultaat FA2.2: Laat onze off-platform volgers op TikTok groeien van de mid-tier (100k-250k volgers) naar de macro-tier (250k-1M volgers) tegen het einde van boekjaar 25/26 (juni 2026).
    - We bevinden ons nu in de mid-tier van TikTok volgers (100k-250k volgers), en ons doel is om de macro-tier (250k-1M volgers) te bereiken tegen het einde van boekjaar 25/26 (juni 2026). Deze niveaus (Micro, Mid en Macro) zijn standaardbenchmarks in de branche voor de grootte en het bereik van het publiek. Om daar te komen, zullen we onze contentstrategie verfijnen om Gen Z-volgers beter aan te trekken en onze algehele zichtbaarheid te vergroten door middel van communitybeheer. H1-prestaties zullen tactische aanpassingen in H2 informeren om de groei te versnellen en deze mijlpaal te bereiken.
  - Belangrijkste resultaat FA2.3: Lanceer een product buiten het platform dat is gericht op de nieuwe leermethoden/mediaconsumptie van toekomstige doelgroepen en breng het op de markt via een gezamenlijke productbranding- en marketingcampagne.
    - Future Audiences werkt doorgaans aan kleinschalige experimenten met minimale/organische marketing. Dit jaar willen we tijd vrijmaken voor een grootschaligere campagne voor nieuwe producten en marketing, gericht op jongere doelgroepen buiten het platform.

Product- en technische ondersteuning (Product & Engineering Support, PES)

Product- en technische ondersteuning (PES1)

Doel: WMF Product- en Engineering-teams zijn effectiever dankzij verbeterde processen, wat een positieve verschuiving in onze cultuur bevordert. Discussie
- Doel context: Deze doelstelling gaat over het sneller, slimmer en beter maken van de manieren van werken van de Wikimedia Foundation. Het gaat erom hoe we werken. Dit betekent minder frictie en obstakels (inefficiënties en fouten) in processen en sneller impact. Deze doelstelling gaat ook over het aanleren van werkwijzen die in de hele afdeling en organisatie kunnen worden toegepast.
  - Belangrijkste resultaat PES1.1: Tegen het einde van Kwartaal 2 SLO's definiëren voor 6 productiediensten op basis van een prioriteringsrubriek die tot doel heeft ons leren te maximaliseren over het definiëren en gebruiken van SLO's om weloverwogen beslissingen te nemen over het prioriteren van betrouwbaarheidsgerelateerd werk door teams van belanghebbenden.
    - Een Service Level Objective (SLO) is een overeenkomst tussen teams van belanghebbenden over een doelserviceniveau (betrouwbaarheid/prestaties) waaraan teams samenwerken (en die niet veel worden overschreden). Het helpt bijvoorbeeld te bepalen wanneer betrouwbaarheids- of prestatiewerk prioriteit moet krijgen of deprioritair moet worden gegeven door een ontwikkelingsteam, of wat een probleem is. Teams moeten zich zorgen maken over het identificeren van wat onmiddellijk is (waarschuwing/incidentrespons/kritieke bugs) en wat niet. Het doel is om wrijving tussen functies te verminderen door te onderhandelen over doelen en te informeren over gedeelde en duidelijke prioritering.
  - Belangrijkste resultaat PES1.2: Tegen het einde van Kwartaal 2 hebben community-signalen (inclusief de wensenlijst) WMF beïnvloed om prioriteit te geven aan ten minste 5 productwerkstromen voor de Kwartalen 3 en 4.
    - Ons doel is om te identificeren en te vieren wanneer teams prioriteit geven aan werk op basis van evidence-based community-verzoeken.
    - Twee geplande hypothesen zijn uitsluitend gericht op de wensenlijst. Ze zijn ontworpen om het vertrouwen te verbeteren, processen te stroomlijnen en de participatie van personeel en vrijwilligers te vergroten. Een andere hypothese is een experiment dat is ontworpen om te zien of er voldoende waardevolle signalen zijn van de kroeg, enz., en of AI onze signaalverzameling kan ondersteunen.
  - Belangrijkste resultaat PES1.3: Twee afdelingsoverschrijdende experimenten in een vroeg stadium, gevalideerd door onze externe consumenten-, donor- en bijdragersdoelgroepen, worden door de Foundation opgenomen in het jaarplan.
    - Dit werk gaat over het creëren van experimenten en experimenteerprocessen die in onze hele organisatie kunnen worden toegepast.
    - De Foundation versterkt een cultuur van afdelingsoverschrijdende experimenten door twee gevalideerde experimenten in een vroeg stadium in haar jaarlijkse planning op te nemen. Dit initiatief bevordert de samenwerking buiten de functieteams van de afdeling Product & Technology, waardoor meer innovatie met andere afdelingen in de organisatie (zoals Communicatie en Vooruitgang) wordt aangemoedigd. Door niet-geteste nieuwere ideeën te zaaien en processen voor experimenten te stroomlijnen, verbeteren teams de productiviteit en schaalimpact. Succes wordt gemeten door twee afdelingsoverschrijdende experimenten per jaar te voltooien, deze te integreren in toekomstig OKR-werk en de acceptatie van experimenteerpraktijken te vergroten. Voorbeelden van resultaten zijn nieuwe prototypes om de groei en productiviteit van nieuwe bewerkers te vergroten, tot experimentele functies die de band tussen lezer en donateur met Wikipedia verdiepen. Een specifieke mogelijkheid die is geïdentificeerd, is het verbinden van kleine functieverkenningen om de 25e verjaardag van Wikipedia te vieren.
  - Belangrijkste resultaat PES1.4: Tegen het einde van Kwartaal 4 zullen we een toename van 10% in het adoptiepercentage van Codex zien onder P&T-teams.
    - Als gestandaardiseerde UI-bibliotheek vermindert Codex zowel de onderhoudslast van het creëren van aangepaste UI-componenten als de tijd die nodig is voor het implementeren van product-UI's aanzienlijk. Codex biedt ook een gedeeld vocabulaire om te praten over ontwerp en implementatie, wat de efficiëntie tussen ontwerp en engineering verhoogt.
    - Codex verliest bruikbaarheid als de adoptie niet toeneemt en Codex niet veel wordt gebruikt, en nu wordt het niet overgenomen of op sommige plekken veel gebruikt omdat de hulpmiddelen nog niet klaar zijn voor sommige gebruikssituaties. Het kan ook zijn dat er meer prominente reclame/bekendheid nodig is. Dit werk is een prioriteit omdat teams Codex organisch moeten kunnen adopteren, en nu kunnen niet alle dat zonder dat er eerst obstakels voor adoptie worden aangepakt.
    - We verwachten dat dit betekent:
      - Ontdekken - Wat laten verschillende teams zien dat hen blokkeert? Wat zijn de gebruiksscenario's en blokkers waarvan we nog niet op de hoogte zijn?
      - Verbetering - Voorbeeld: We weten dat Codex PHP 1.0 de server-side-adoptie zal ontblokken.
      - Diepgaande analyse van metingen - Voorbeeld: Wat vertellen de baseline-metingen die in Kwartaal 1 zijn vastgesteld over de plaatsen waar organische adoptie niet werkt (en zijn er lessen van OOUI-adoptie in de afgelopen jaren)?
    - Dit zal zich richten op het volgen van "officiële" gebruik (d.w.z. de adoptie die de gedocumenteerde richtlijn volgt) apart van gedeeltelijk of gedeeltelijk gebruik, bijvoorbeeld wanneer teams slechts een deel van een component of alleen de CSS gebruiken. Dit laatste type adoptie heeft hogere onderhoudskosten dan het gebruik van componenten die niet standaard beschikbaar zijn.
  - Belangrijkste resultaat PES1.5: 20% van de service-SLO's levert een impactvolle beslissing op tegen het einde van Kwartaal 4.
    - Service Level Objectives (SLO's) zijn een hulpmiddel dat wordt gebruikt om prioriteiten te bepalen op basis van gegevens uit servicebetrouwbaarheid. Bijvoorbeeld of het down zijn van een service onmiddellijke aandacht nodig heeft. SLO's werken het meest effectief wanneer het eigendom duidelijk is en iedereen ze gebruikt. Om dit te laten gebeuren moeten we de ontwikkelingscultuur verschuiven naar het invoeren van SLO's voor elke service. Voortbouwend op de afgelopen kwartalen van het creëren van SLO's en het testen ervan met serviceteams, hebben we een kans geïdentificeerd om de waarde van SLO's te verduidelijken, zodat we deze cultuur kunnen blijven verspreiden.
      - We hebben op dit moment 19 SLO's.
      - Wij willen SLO's stimuleren voor services die het meest waarschijnlijk van hen gebruik maken. Als we ~3-4 (~20% 0 van 19) "impactvolle beslissingen" krijgen van onze huidige oogst, geweldig, maar we anticiperen dat we meer moeten maken. De nominale waarde zal toenemen, maar dat stimuleert het verder om ons op de juiste services te richten.
      - Kwartaal 4 is het einde van de tijdvak omdat we meer dan één datacyclus willen, en elk kwartaal is een cyclus. Het geeft ons ook ruimte om hulpmiddelen te ondersteunen, SRE-alarming te laten zien, enz.
    - Succes lijkt op:
      - Impactvolle beslissing = "is deze service nu betrouwbaar genoeg, of moeten we prioriteit geven aan werk om het te herstellen" – dat wil zeggen, het is net zozeer een beslissing om een fout te vinden en te zeggen dat het oké is om die niet te prioriteren, als om een fout te vinden en te prioriteren bij het corrigeren.
      - We willen dat beslissingen divers zijn (bijv. architectonisch versus organisatorisch versus implementatie; of bevestigend versus besluit om niet iets te doen), omdat het gaat om het verspreiden van de waarde van SLO's en het verschuiven van cultuur. Alle beslissingen van hetzelfde type of van hetzelfde team bereiken dat niet, zelfs niet als het goed is.
      - Zelfs als we dit doel niet halen, veronderstellen we dat we waardevolle informatie hebben verkregen over waarom (bijv. we richten ons op de verkeerde services).
      - Belangrijk: 80% van onze SLO's hebben geen impactvolle beslissing is geen mislukking daarvoor, omdat het meeste van de tijd de services niet moeten falen.
  - Belangrijkste resultaat PES1.6: 20% van de kritieke services zonder eigenaar, volgens een risicoanalysekader, krijgen eigenaren tegen het einde van Kwartaal 4.
    - Duidelijke code en eigendom van services zijn cruciaal om ervoor te zorgen dat de technische infrastructuur van de Wikimedia Foundation betrouwbaar, schaalbaar en veilig blijft. Het aanpakken van huidige tekortkomingen in eigendom zal de verantwoordelijkheid verbeteren, de samenwerking tussen teams versterken, effectieve besluitvorming versnellen en risico's voor platformstabiliteit, veiligheid en duurzaamheid verminderen. Daarnaast zal het meer duidelijkheid bieden voor Wikimedia-partners en vrijwilligers, zodat zij begrijpen wie verantwoordelijk is voor het onderhouden en ondersteunen van belangrijke services.
      - We schatten dat er ongeveer 20 kritieke services zonder eigenaren zijn.
      - We denken dat we 4 eigenaren kunnen toewijzen over 4 maanden tijdens Kwartaal 3/4. De eerste twee maanden of zo zullen we ons voorbereiden op succes met het voorbereidende werk.
      - We willen een risicoanalyse-framework ontwikkelen om het kritiek zijn te bepalen, als onderdeel van het werk aan de hypothese onder dit resultaat.
  - Belangrijkste resultaat PES1.7: Aan het einde van Kwartaal 4, voor ontvangen wensen in Kwartaal 3 en 4, stijgt het percentage verbeterde verzonden wensen tot 5%.
    - Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Hypothesen

Kwartaal 1

Het eerste kwartaal van het WMF-jaarplan loopt van juli-september.

Wiki Experiences (WE) Hypothesen [ WE Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 1 tekst	Details en discussie
WE1.1.1	Als we nieuwe(re) vrijwilligers die tekst van een externe site plakken vragen om te bevestigen of ze de inhoud hebben geschreven die ze proberen toe te voegen, dan zullen we een afname van ≥10% zien in het percentage nieuwe inhoudsbewerkingen die nieuwe(re) vrijwilligers publiceren die worden teruggedraaid op grond van WP:COPYVIO (en gerelateerd beleid).
WE1.1.2	Als we een eerste bètaversie van de voorgestelde bewerking "Verbeteren tonen" leveren, kunnen we leren of dit nieuwe formaat van voorgestelde bewerkingen een zinvolle manier is om het aantal constructieve bewerkingen voor nieuwe bijdragers te vergroten zonder de moderatielast voor patrollers/beoordelaars te vergroten.
WE1.1.3	Als we een nieuwe suggestiemodus gericht op Senior Bijdragers implementeren in de visuele editor (mobiel + desktop) als een bètafunctie met minstens 3 nieuwe bewerkingssuggesties erin, zullen we ontdekken welke - indien van toepassing - aanpassingen moeten worden gemaakt voordat we de ervaring met nieuwe(re) vrijwilligers evalueren door middel van een gecontroleerd experiment.
WE1.1.4	Als we Reference Check op en.wiki inzetten via een gecontroleerd experiment, zullen we een toename van ≥10% zien in het aantal constructieve bewerkingen dat nieuwe(re) vrijwilligers publiceren en leren of er voldoende steun is onder patrollers en moderators om de functie op grotere schaal in te schakelen.
WE1.1.5	Als we een voortgangssysteem testen via ontwerpprototypes met nieuwkomers, dan kunnen we identificeren welke soorten mijlpalen, begeleiding en erkenning als het meest motiverend worden ervaren, en deze inzichten gebruiken om een ontwerp af te ronden voor toekomstige pilot-wiki-experimenten.
WE1.1.6	Als we de belangrijkste technische, sociale en gedragsbarrières en -factoren voor mobiele webbewerking onderzoeken door middel van gebruikersonderzoek en gegevensanalyse, zullen we ten minste 3 bruikbare inzichten genereren die belangrijke kennislacunes dichten en ons vermogen versterken om met vertrouwen productinvesteringen te prioriteren voor de tweede helft van FY25/26 en daarna.
WE1.2.1	Als we een proof of concept creëren voor het weergeven van gegevens over gezamenlijke bijdragen op de wiki's, kunnen we feedback verzamelen van ten minste 30 bijdragers, waarbij 70% van de respondenten deelt dat de functie nuttig is en kan helpen bij het stimuleren van gezamenlijke groei.
WE1.3.1	Als we gebruik maken van de behoeften die zijn geïdentificeerd uit eerder onderzoek en ontwerp en vroege prototypes (mockups) van de top X meest impactvolle moderatormodules delen, kunnen we de startpagina aanpassen voor moderatieacties met hen.
WE1.3.2	Als we de startpagina voor nieuwkomers aanpassen om moderatormodules voorwaardelijk weer te geven, kunnen we de haalbaarheid van het gebruik van de startpagina voor moderators bewijzen.
WE1.4.1	Als we een aantal verbeteringen aanbrengen die worden genoemd in T396489 zullen we de trage query's voor recente wijzigingen op grote wiki's met X procent verminderen. Dan zullen moderator-hulpmiddelen in staat zijn om homepage-modules op die wiki's te implementeren zonder speciale zorgen over de prestaties van de database.	T400696
WE2.1.1	Als we moedertaalsprekers van kleine wiki's uitnodigen via een CentralNotice-banner op een drukbezochte Wikipedia in hun regio om bij te dragen aan voorgestelde bewerkingen (SuggestedEdits) en andere groeifuncties, kunnen we beoordelen of deze aanpak nieuwe moedertaalsprekers aantrekt en of ze deze bewerkingshulpmiddelen gebruiken om essentiële inhoud te verbeteren.
WE2.1.2	Als we vertaalsuggesties zouden ontwikkelen en vrijgeven die zijn afgestemd op nieuwe bewerkers, zouden we kunnen testen of deze aanpak betere vertaalresultaten oplevert in vergelijking met onze huidige aanpak. Dit pakt de bekende uitdagingen aan waarmee nieuwe bewerkers worden geconfronteerd, die een grotere kans hebben om artikelen te verwijderen. Door hen te wijzen op het vertalen van beter beheersbare inhoud, is het doel om een minder overweldigende en meer toegankelijke inleiding tot het vertaalproces te bieden. Goede artikel- en sectiekandidaten kunnen eruitzien als een beperkte complexiteit in termen van opmaak en totale lengte.
WE2.1.3	Als we meer te weten komen over de ervaring van bewerkers bij het maken van nieuwe artikelen en secties (inclusief motivaties, pijnpunten en hun reactie op nieuwe ideeën over hoe we deze beter kunnen ondersteunen), dan zullen we gebruikersbehoeften en -gedrag blootleggen die bruikbare inzichten en strategieën bieden om product, ontwerp en engineering te informeren over het verbeteren van de ervaring bij het maken van artikelen.
WE2.1.4	Als we, door middel van participatieve workshops of interviews, onderzoeken hoe drie middelgrote Wikipedia's kennislacunes en het belang ervan benaderen, zullen we werkdefinities of kaderconcepten voor "vitale kennis" ontdekken die relevant zijn voor elke gemeenschap.
WE2.2.1	Als we de uitrol van Parsoid volgen en Wikifuncties integreren op de meeste Wikiwoordenboeken en sommige Wikipedia's met weinig verkeer, krijgen we de tests die we nodig hebben om vol vertrouwen uit te rollen naar grotere wiki's.
WE2.2.2	Als we Wikifuncties in staat stellen om HTML-tabellen, -stijlen en -links uit te voeren, zullen we door middel van een functie die een vervoegingstabel weergeeft, aantonen dat het in staat is om netto nieuwe kennis over Wiktionaries te genereren die verder gaat dan eenvoudige conversies.
WE2.2.3	Als we ondersteuning toevoegen voor Wikidata-entiteiten in ingesloten functieaanroepen, zullen we meer dan 200 nieuwe functies inschakelen die uitgebreide zinnen kunnen genereren met behulp van Wikidata-entiteiten, waardoor functies gemakkelijker kunnen worden gebruikt op Wikimedia-projecten.
WE2.2.4	Als we een architectuurplan opstellen voor waar abstracte inhoud zich zal bevinden en hoe het zal interageren met Wikipedia, zullen we meer klaar zijn om het abstracte Wikipedia-platform te implementeren om het aanbod van encyclopedische inhoud van hoge kwaliteit te vergroten.
WE2.2.5	Als we de product- en technologieteams definiëren en socialiseren over de productbehoeften voor citaten die nodig zijn voor abstracte inhoud, zullen we in staat zijn om cross-wikimedia-werk te stimuleren om herkomstinformatie te leveren die is gekoppeld aan abstracte inhoud, wat cruciaal is voor een succesvolle acceptatie op wiki's.
WE2.2.6	Als we ons backend-interne verzoekformaat expressiever en beknopter maken, kunnen we de stabiliteit van het systeem vergroten en zo een bredere uitrol ondersteunen.
WE2.2.7	Als we prototypefragmenten leveren met behulp van Wikidata- en Wikifunctions-aanroepen om natuurlijke taalfragmenten te genereren, zullen we laten zien dat we klaar zijn voor het project en zullen we klaar zijn om te worden gebruikt om AI te trainen, zodat mensen niet te veel hoeven na te denken over functies.
WE2.2.8	Als we het importeren van Wikidata-verklaringen voorzien van kwalificaties, zal het mogelijk zijn om veelzijdige feiten te genereren (feiten die meer vereisen dan alleen onderwerp/predikaat/waarde om uit te drukken), waaronder naar schatting 50% van de encyclopedische inhoud in Wikidata.
WE2.2.9	Als we caching van opgehaalde Wikidata-entiteiten aanbieden, zullen we de gemiddelde runtime van op Wikidata-inhoud gebaseerde functies met ten minste 50% verminderen, waardoor time-outs en frustratie bij gebruikers worden verminderd.
WE2.2.10	Als we een component voor Wikidata lexeem betekenissen toevoegen aan de Wikifunctions UI, dan zullen bijdragers in staat zijn om relevante lexemen te identificeren en te selecteren zonder het platform/Wikifuncties te verlaten, waardoor het wisselen van context wordt verminderd en het mogelijk wordt om sneller en succesvoller taalgerelateerde functies te maken.
WE2.2.11	Als we kijken naar de bruikbaarheidsbevindingen van de Dagbani-gemeenschap over Wikifunctions-integratie op Wikipedia, zullen we zien dat bewerkers minder of geen kritieke bruikbaarheidsproblemen tegenkomen bij het invoegen van een functie in een artikel tijdens het testen.
WE3.1.1	Als we een verbeterde versie van de functie Browsen met tabbladen testen op de IOS-app, zien we een toename van 5% in meerdaags gebruik onder Tabs-gebruikers.
WE3.1.3	Als we gebruikers een nieuwe manier bieden om door relevante afbeeldings- of video-inhoud op artikelpagina's te bladeren, zien we een klikfrequentie van ten minste 3% onder gebruikers die deze functie krijgen.
WE3.1.4	Als we lezers verschillende concepten laten zien voor het doorkruisen van het kennisnetwerk op de wiki's, komen we weg met een geprioriteerde lijst van concepten voor verdere ontwikkeling.
WE3.1.5	Als we weblezers de mogelijkheid bieden om een machinaal vertaalde versie van Wikipedia-inhoud te bekijken die niet beschikbaar is in hun taal, zullen we leren of de leesactiviteit is toegenomen, gemeten als een toename van 3% in pagina-interacties, waardoor lezers naar de lokale taalwiki worden getrokken met een mogelijke toename van lokale bewerkingsactiviteit. Dit zal worden aangeboden als een gecontroleerde A/B-testinstelling voor niet langer dan 6 maanden, en in 13 Wikipedia's met voorafgaande toestemming, met behulp van open machinevertalingsdiensten die al beschikbaar zijn voor Wikipedia-editors.
WE3.2.1	Als we samenwerken met fondsenwerving, zullen we in het iOS-jaaroverzicht meer boeiende, geïntegreerde en gepersonaliseerde donateursdia's ontwikkelen, zoals gemeten door middel van gebruikerstests. Dit zal worden gevolgd door een hypothese in Kwartaal 2 om te beoordelen of het verbeterde jaaroverzicht 5% meer donaties opleverde dan het jaaroverzicht van 2024.
WE3.2.2	Als we lezers van Android-apps in niet-campagnemarkten vragen om een optionele, aanpasbare herinnering (bedrag en frequentie) in te stellen voor donaties op basis van hun gebruik van Wikipedia, zien we een toename van 5% in donaties in het app-menu in die markten.
WE3.2.3	Als we een A/B-testexperiment uitvoeren op uitgelogde gebruikers om subtiele varianten van het donatie-ingangspunt voor zowel mobiel als desktop weer te geven, zien we een 2% hoger aantal donaties via de behandeltrajecten in vergelijking met controle.
WE3.3.1	Als we gepersonaliseerde elementen met een lage tot gemiddelde inspanning die door iOS-gebruikers in 2024 zijn aangevraagd, toevoegen aan het jaaroverzicht van 2025, zien we een toename van 3% in tevredenheid ten opzichte van vorig jaar, zoals gemeten door middel van bruikbaarheidstests of bèta-tests.
WE3.3.2	Als we het bestaande tabblad Bewerken op Android uitbreiden tot een gepersonaliseerde activiteitenhub met inzicht in deelname aan lezen en niet-bewerken, zien we een toename van 5% in meerdaagse betrokkenheid bij het tabblad in vergelijking met de oorspronkelijke versie.
WE3.3.3	Als we ten minste één ontgrendelbare avatar introduceren in de Android-app voor accounthouders, die is verdiend via zinvolle lezersacties, zoals het opslaan van een bepaald aantal artikelen, verhogen we de herhaalde betrokkenheid van ingelogde gebruikers bij de bijbehorende actie met 10% gedurende meerdere dagen.
WE3.3.4	Als we ingelogde lezers de mogelijkheid geven om artikelen op te slaan in een privé-leeslijst, verwachten we dat de betrokkenheid op de site zal toenemen, gemeten aan de hand van een toename van 5% in intern verwijzingsverkeer voor lezers die de functie gebruiken, en een statistisch significante toename voor alle gebruikers.
WE3.3.5	Als we een gebruikersonderzoek uitvoeren dat weblezers in staat stelt om inhoud van Wikipedia te verzamelen/beheren, dan zal ten minste 10% van de deelnemers twee of meer verschillende soorten inhoud (bijv. artikelen, fragmenten, media) in een verzameling opslaan.
WE3.4.1	Als we werken aan een hybride PoP/CDN-implementatie, kunnen we naar behoefte zowel volledige PoP's als mini-PoP's (fysiek en cloud) aanbieden, waarmee de basis wordt gelegd voor een prototype van een mini-PoP-implementatie in de toekomst.
WE3.6.1	Als we een A/A-test uitvoeren op het retentiepercentage voor uitgelogde gebruikers, stellen we een basislijn vast voor het retentiepercentage dat we voor toekomstige kwartalen kunnen gebruiken.
WE3.6.2	Als we een definitie van ingelogde lezer maken en publiceren, kunnen we deze definitie gebruiken voor alle teams en hypothesen met betrekking tot de WE 3.3 KR.
WE3.6.3	Als we gemeenschappen betrekken bij gesprekken over de veranderende behoeften van lezers en over de veranderende aard van kennis op internet, kunnen we een gedeelde focus opbouwen op hoe we lezers van dienst kunnen zijn en samenwerken aan het al dan niet testen van onze verschillende ideeën (inclusief die rond multimedia, zoeken en ontdekken, en machine learning).
WE3.6.4	Als we onderzoek doen naar de verschillende motivaties, gedragingen en behoeften achter wanneer, waarom en hoe lezers Wikipedia en andere kennisplatforms gebruiken, zullen we bevindingen hebben die we kunnen gebruiken om onze consumentenstrategie te informeren en te ontwikkelen.
WE4.1.1	Als we een prototype maken van een minimaal levensvatbare niet-nood-flow en een iteratieve feedback openhouden terwijl we deze ontwikkelen met gebruikers met uitgebreide rechten, dan zullen deze groepen een uitgebreide implementatie van deze flow ondersteunen.	Project page
WE4.2.1	Als we het hCaptcha-risiconiveau in verband met het maken van accounts onder de aandacht brengen van vertrouwde functionarissen, zullen we de tijd die nodig is om kwaadwillenden te identificeren verminderen en het aantal detecties van accounts met kwaadwillenden die op het platform zijn gemaakt, verhogen. We kunnen het succes van de hypothese meten door te kijken naar het aantal blokkades dat op accounts wordt toegepast, de afstemming van hCaptcha-risiconiveaus en blokken van accounts in het algemeen en kwalitatieve feedback van functionarissen.
WE4.2.2	Als we voorgestelde onderzoeken genereren voor CheckUsers om op te volgen, zullen we een afname zien in de tijd die nodig is om accounts van kwaadwillenden te identificeren en een toename van het aantal geïdentificeerde accounts van kwaadwillenden. We weten dat we succesvol zijn als we zien dat de functie 'Voorgestelde onderzoeken' regelmatig wordt gebruikt, dat er meer oplossingen worden toegepast op accounts die zijn geïdentificeerd via voorgestelde onderzoeken en als we zien dat er meer oplossingen worden toegepast op accounts die zijn geïdentificeerd via voorgestelde onderzoeken en als we feedback geven op kwalitatieve enquêtes.
WE4.2.3	Als we gegevens analyseren van de proef voor het aanmaken van een hCaptcha-account, krijgen we inzicht in de trechter voor het maken van accounts, de effectiviteit van de puzzel en scores van hCaptcha en beschikken we over de gegevens die nodig zijn om de verdere uitrol van hCaptcha bij het aanmaken van accounts te informeren.
WE4.2.4	Als we de UserInfoCard op alle wiki's uitrollen, zullen we functionarissen en moderatoren in staat stellen om accounts van kwaadwillenden efficiënter te identificeren en te beperken.	Project page
WE4.2.5	Als we onderzoek doen, overleggen met gemeenschappen en technische oplossingen onderzoeken, kunnen we een reeks gestructureerde blokredenen definiëren die op alle WMF-wiki's kunnen worden gebruikt.
WE4.2.6	Als we de mogelijkheid ontwikkelen om op OpenSearch gebaseerde clusters op het Data Platform te implementeren, zullen productkenmerken-engineeringteams in staat zijn om systemen te ontwikkelen die deze mogelijkheid integreren, met een grote mate van autonomie, veerkracht en isolatie van andere op zoekopdrachten gebaseerde systemen. De eerste en belangrijkste tenant voor dit systeem is de IPoid-service.
WE4.2.7	Als we hCaptcha Enterprise-integratie uitrollen verschillende productie-Wikipedia's als een pilotproef, zullen we in staat zijn om gegevens te verzamelen over de werkzaamheid en waarde van hCaptcha Enterprise op het gebied van antimisbruik, botdetectie, bruikbaarheid en toegankelijkheid.
WE4.3.1	Als we ondersteuning voor de nieuwe Edge Uniques-cookie integreren in requestctl, onze edge-rules engine voor SRE's die misbruik bestrijden, zullen we ons beter kunnen verdedigen tegen DDoS en hergebruik van inhoud.
WE4.4.1	Als we verbeteringen kunnen aanbrengen op basis van feedback van pilots en tijdelijke accounts kunnen inzetten voor alle projecten, kunnen we de blootstelling van persoonlijk identificeerbare informatie (IP-adressen) van niet-geregistreerde gebruikers op al onze projecten beschermen tot beschikbaar voor minder dan 0,1% van alle (geregistreerde) gebruikers.	Project page
WE4.4.2	Als we duidelijk en op tijd communiceren met de relevante belanghebbenden van de beweging (inclusief wiki-gemeenschappen en wereldwijde functionarissen), kunnen we het op alle resterende wiki's uitrollen, de werklast verminderen die op het laatste moment wordt ontdekt en voorkomen dat de implementatie wordt teruggedraaid.
WE4.4.3	Als we het voor patrollers gemakkelijker maken om acties te filteren op en de activiteit van tijdelijke accounts te bekijken, op basis van hun IP-adressen, dan zullen we het mogelijk maken dat tijdelijke accounts met succes worden uitgerold naar alle wiki's.
WE4.4.4	Als we toestaan dat toegang tot het onthullen van tijdelijke IP-accounts wordt ingetrokken in overeenstemming met het toegangsbeleid voor IP-onthullingen, en de functie op meer plaatsen weergeven, dan zullen we ervoor zorgen dat tijdelijke accounts met succes worden uitgerold naar alle wiki's.
WE4.5.1	Als we kwalitatief onderzoek uitvoeren om voorbeelden te identificeren van misbruik door kwaadwillenden met behulp van generatieve AI (zoals spam, intimidatie, langdurige misbruikers, geheime betaalde bewerkingen of desinformatiecampagnes), kunnen we het risico voor onze communitymodellen beoordelen en ideeën genereren om verschillende soorten generatief AI-ondersteund misbruik te beperken.
WE4.6.1	Als we het synchronisatie-accountproces binnen Zendesk voor het opnieuw instellen van wachtwoorden automatiseren, zal dit de last voor T&S verlichten en hen in staat stellen om meer inkomende 2FA-resetverzoeken te verwerken.
WE4.6.2	Als we gebruikers ondersteunen en aanmoedigen om meerdere authenticatiefactoren te registreren, zullen gebruikers met 2FA ingeschakeld minder snel geneigd zijn zichzelf uit te sluiten van hun account.
WE4.6.3	Als we alle gebruikers met een bevestigd e-mailadres toestaan om 2FA in te schakelen voor hun accounts, maar deze wijziging niet proactief aan gebruikers adverteren, blijft onze belasting van de herstelondersteuningsdesk op een duurzaam niveau.
WE5.1.1	Als we verschillende opslagbackends gebruiken voor geverifieerde en anonieme sessies, kunnen we Sessionstore beschermen tegen DDoS-aanvallen en scrapers met een hoog volume, door het niet te overbelasten met de anonieme sessies die zijn gemaakt om CSRF-preventie op authenticatiepagina's te bieden.	T398814
WE5.1.2	Als we MediaWiki-sessiecookies veranderen in een gestructureerd formaat met een cryptografische handtekening, kunnen we de aanwezigheid van een sessie gebruiken als een factor in bescherming tegen scrapers, door betrouwbare verificatie van sessies aan de edge op een performante en zeer schaalbare manier mogelijk te maken.	T398815
WE5.1.3	Als we een oplossing voor snelheidsbeperking voor de API-gateway maken met behulp van een lokale ontwikkelomgeving op basis van Kubernetes, kunnen we de beste optie bepalen om te testen met productieverkeer door de prestaties en functionaliteit van ten minste drie verschillende snelheidsbeperkende services te vergelijken.	T398913
WE5.2.1	Als we de Gebruikersinterface REST API Sandbox opnieuw ontwerpen om beter te voldoen aan de informatiebehoeften van ontwikkelaars, zullen we de duidelijkheid van de documentatie verbeteren, zoals gevalideerd door bruikbaarheidstests.
WE5.2.2	Als we alle API's onder de rest.php via een centrale gateway routeren, ontgrendelen we de middelen voor gecentraliseerd API-beheer en kunnen we beginnen met het consequent meten van REST API-verkeer en gebruikspatronen om inzichten te verkrijgen die toekomstige beslissingen en acties zullen informeren.
WE5.2.3	Als we monitoringdashboards en alarmen implementeren voor de MediaWiki REST API, dan kunnen we een duurzame, nuttige en reproduceerbare manier demonstreren om het inzicht in het gedrag van onze systemen te verbeteren en problemen eerder aan het licht te brengen, vooral tijdens kritieke wijzigingen.
WE5.3.1	Als we de richtlijnen voor UX-attributie uitbreiden en stroomlijnen terwijl we bestaande richtlijnen bijwerken, stellen we een set van verbeterde richtlijnen op die klaar zijn om intern te worden getest en iteratief te worden verfijnd om voorbereid te zijn op breder openbaar gebruik.
WE5.3.2	Als we een pitch maken die de voordelen van het toeschrijven van Wikipedia aan 3e partij inhoud hergebruikers en hun eindgebruikers demonstreert, kunnen we WME4.1 en WME4.2 ondersteunen door ten minste één extra hergebruikpartner in staat te stellen om tegen het einde van Kwartaal 1 in te stemmen met het verschijnen in een casestudy of demo van een attributie.
WE5.4.1	Als we ervoor zorgen dat de meeste webverzoeken een edge uniques-cookie krijgen, wordt het gemakkelijker om bots en vervalste verzoeken te identificeren.
WE5.4.2	Als we een schaalbare manier bouwen om bekende klanten te identificeren, kunnen we uitzonderingen op algemene tarieflimieten voor bots van geverifieerde oorsprong toestaan en overgaan tot systematische handhaving van onze regels.
WE5.4.3	Als we het filteren van tekstverzoeken op het CDN reorganiseren rond een aanpak met een allow/deny lijst, kunnen we strengere algemene snelheidslimieten voor bots afdwingen en het filteren van verkeer stroomlijnen.
WE5.4.4	Als we een uniforme meetstrategie ontwikkelen, zullen we evaluatie van de meerjarenstrategie voor 'verantwoord gebruik van infrastructuur' mogelijk maken en een routekaart definiëren om de ontwikkeling en rapportagemogelijkheden van metrieken te begeleiden.
WE6.1.1	Als we dagelijkse installatiekopieën opnieuw plaatsen op de implementatieserver en installatiekopie-updates toevoegen die worden geactiveerd door bepaalde implementatieacties, komen er beperkingen aan het licht en stellen we een basislijn vast voor de tijd die nodig is om meer continue implementaties uit te voeren.
WE6.1.3	Als we wikifarms toevoegen aan een pre-merge testomgeving, zullen ontwikkelingsteams die tegen productie moeten bouwen in staat stellen om hun patches afzonderlijk te testen, waardoor ze meer vertrouwen krijgen in de pre-productie en minder fouten hoeven te voorkomen.
WE6.2.1	Als we onze checklist voor productiegereedheid herzien en publiceren, waarin duidelijk de voorwaarden worden gedefinieerd om een service als klaar voor productie te beschouwen, samen met taken die zelf kunnen worden uitgevoerd, zullen we de verwachtingen afstemmen tussen SRE's en ontwikkelingsteams, waardoor onze algehele operationele efficiëntie en schaalbaarheid worden verbeterd.
WE6.2.2	Als we aankondigen dat we een Golang- en nodejs-bibliotheek maken die veel moeizame taken voor ontwikkelaars abstraheert, zullen ze met feedback en interesse reageren.
WE6.2.3	Als we een checklist/werkblad maken, kunnen ontwikkelaars zich volledig vooraf voorbereiden op de ontwerpbeoordeling van Data Persistence.
WE6.3.1	Als we in Kwartaal 1 ten minste 70 wiki's met weinig verkeer uitrollen, met uitzondering van wiki's met taalvariantondersteuning, zullen we ons vertrouwen vergroten voor de eventuele uitrol naar de top 10 wiki's die een grotere impact zullen hebben op de paginabezoeken die via Parsoid worden bediend.
WE6.4.1	Als we de splitsing van de linktabel van Commons in zijn eigen cluster gebruiken, zullen we de kans verhogen dat de groei van de database voor Commons duurzaam blijft.	T398709
WE6.4.2	Als we (SRE) hulp bieden aan de MediaWiki engineering teams - door het creëren van documentatie, het voorbereiden van de benodigde infrastructuur (bijv. PHP-pakketten, container-images) en het bieden van begeleiding en beoordeling - zullen ze in staat zijn om met vertrouwen de productie van PHP 8.3 upgrade te starten aan het begin van Kwartaal 2.	T360995
WE6.4.3	Als we een tweede fysieke factor (hardware security key) nodig hebben voor SSH-logins door gebruikers met verhoogde systeemprivileges, zullen we het risico verminderen dat een gecompromitteerde laptop een ernstige beveiligingslek veroorzaakt.
WE6.4.4	Als we onze domeinen verenigen door alle paginaweergaven op MediaWiki-sites via een canoniek domein aan te bieden, dan zullen we de complexiteit van het platform verminderen en Search Engine Optimization (SEO) risico's verkleinen door het elimineren van de doorverwijzing van het mobiele subdomein. Voltooiing wordt gemeten door het aantal doorverwijzingen van mobiele paginaweergaven op canonieke domeinen te verlagen van 100% naar 0%.	T214998
WE6.4.5	Als het team MediaWiki Engineering actief problemen in MediaWiki met betrekking tot de PHP 8.3 upgrade controleert en oplost, zal het SRE-team worden gedeblokkeerd om door te gaan met de PHP 8.3 upgrade aan het begin van Kwartaal 2.	T360995

Signals & Data Services (SDS) Hypothesen [ SDS Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 1 tekst	Details en discussie
SDS1.1.1	Als we de effectiviteit van de geautomatiseerde heuristieken over verkeersdetectie in onze datasets voor paginaweergaven analyseren, kunnen we gegevenskwaliteitsstatistieken ontwikkelen om hun prestaties te beschrijven en te bepalen of er behoefte is aan verdere investeringen in deze heuristieken.
SDS1.2.2	Als we het XML-dumpproces migreren van de huidige 'Dumps 1'-infrastructuur naar een datapipeline die gebruikmaakt van de MediaWiki Content Pipelines, kunnen we SLO's garanderen en de op 'Dumps 1' gebaseerde XML-export uitschakelen.
SDS1.2.3	Als we een walkthrough doen en de SLO's voor MediaWiki Content History en Event Platform / Event Gate beoordelen, kunnen we de klanten, statistieken en afhankelijke belanghebbenden valideren en verbeteringen identificeren die mogelijk nodig zijn voor de SLO's, wat ons zal helpen eventuele hiaten in onze wekelijkse leveringsgaranties te verklaren.
SDS2.1.1	Als we nauw samenwerken met teams die experimenten uitvoeren, leren we hoe we het systeem in de toekomst meer zelfvoorzienend kunnen maken en tegen welke conceptuele of technische uitdagingen ze kunnen aanlopen.
SDS2.1.2	Als we betere foutopsporing kunnen implementeren voor het loggen van gebeurtenissen, weten productteams dat hun experiment gegevens verzamelt zoals verwacht, waardoor het vertrouwen van degene die (laten) experimenteren toeneemt.
SDS2.1.3	Als we de logboekregistratie en waarneembaarheid verbeteren voor het A/B-testsysteem (xLab) -onderdeel van het experimenteerplatform, en voor de gerelateerde MediaWiki-onderdelen, kunnen we basislijnen vaststellen voor de prestaties van het systeem en reageren op experimentgerelateerde fouten.
SDS2.1.4	Als we één keer per maand verhalen over experimenten en -resultaten delen met de hele organisatie (via Product Ops-vergaderingen, ontwerpteamvergaderingen en teamoverschrijdende presentaties), dan creëren we een organische acceptatie van het experimenteerplatform.
SDS2.1.5	Als we gebruikers vertellen dat hun instrument, indien gemaakt in xLab, een set kenmerken bevat die de risicocategorie wijzigt, zullen we instrumentatiegebruikers ervan weerhouden om te veel gegevens te verzamelen en meer duidelijkheid te scheppen over welke combinatie van kenmerken privacybeoordeling vereist.

Future Audience (FA) Hypothesen [ FA Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 1 tekst	Details en discussie
FA1.1.1	Als we 1) manieren bieden voor mediaverzamelaars op andere platforms (zoals Letterboxd, Goodreads en RateMyMusic) om hun collecties te verrijken met exclusieve Wikipedia-kennis, of 2) deze mediaverzamelaars interessante deelbare media bieden, dan zullen we in staat zijn om het bereik van Wikipedia buiten het platform te vergroten.
FA2.1.1	Als we in Kwartaal 1 onze interne capaciteit opbouwen om korte videocontent te creëren (door onze teamomvang en auditing te vergroten en mogelijkheden te identificeren om de efficiëntie in ons huidige productieproces te verhogen), kunnen we in Kwartaal 1 handelen op basis van de lessen uit content die in FY2024-5 is gemaakt en een hoger YoY-bereik bereiken van content die in Kwartaal 2 FY2025-6 is geproduceerd.

Product- en technische ondersteuning (PES) Hypothesen [ PES Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 1 tekst	Details en discussie
PES1.1.1	Als we xLab, Charts en ToneCheck ondersteunen bij het definiëren van statistieken voor SLI's (Service Level Indicators) in Prometheus, en aan boord van de die Service Level Objectives (SLO's) op Pyrra, leren we de limieten en hoekgevallen van onze tooling in meerdere complexe scenario's, en verduidelijken we welke iteraties nodig zijn voor de SLO-sjabloon, wat ons zal helpen om de 6 geplande SLO's voor de KR beter te ondersteunen.
PES1.1.2	Als we twee sets SLO-waarschuwingsdashboards testen, zullen we leren hoe moeilijk het zou zijn om geschikte tooling te implementeren, zodat service-eigenaren hun verplichtingen duidelijk begrijpen, en ook of we moeten migreren naar een ander hulpmiddel die slechts één weergave van een specifieke SLO biedt. Eén dashboard is voor kwartaalrapporten (waarbij de werkelijke Service Level Agreement voor het foutenbudget is ingesteld) en een kleinere dynamische overeenkomst ('rollend' genoemd) is voor dagelijkse bewerkingen en waarschuwingen.
PES1.1.3	Als we de Abstract Wikipedia-groep blijven ondersteunen bij het opstellen van een SLO (Service Level Objectives) voor het Wikifunctions-project, zullen we leren hoe we een lijst met SLO-doelen kunnen definiëren (samen met hun Service Level Indicator-statistieken) voor een complexe functie die momenteel wordt toegevoegd aan een kritieke gebruikersworkflow: het renderen van Wiki-artikelen. We zullen ook leren hoe we de gerelateerde foutbudgetten op de juiste manier kunnen visualiseren en hierop kunnen waarschuwen met behulp van dashboards en monitors die worden geleverd door SRE.
PES1.1.4	Als we de Data Platform-groep ondersteunen met beoordeling en iteratie van de Service Level Objectives (SLO) voor het MediaWiki Content History project, zullen we leren hoe SLO's kunnen worden gebruikt om service-eigendom te ondersteunen wanneer een combinatie van batch- en streamverwerkingsservices samen worden georkestreerd om de dataset bij te werken, zodat deze consistent en beschikbaar blijft voor downstreamgebruikers.
PES1.2.1	Als we 3 gerichte verbeteringen aan de wensenlijst aanbrengen, zullen we 30% meer unieke deelnemers aan de wensenlijst aanmoedigen
PES1.2.2	Als we binnenkomende wensen sorteren en binnen 72 uur een Onderhouder toewijzen (bijv. Productmanagers) (inclusief weigeren, verduidelijken, markeren van niet-onderhouden services, enz.), door nieuwe wensen te vergelijken met de tabel Maintainers en een "Maintainer-categorie" toe te wijzen aan het meest relevante productteam of individu, kunnen de Onderhouders wensen binnen 10 dagen of minder beoordelen en erop reageren.
PES1.2.3	Als we pilots uitvoeren om gemeenschapssignalen in het algemeen te identificeren, zullen we meer stem van vrijwilligers opnemen in onze door de gemeenschap geïnformeerde prioriteringsinspanningen
PES1.2.4	Als we in Kwartaal 1 met 3 teams een driemaandelijkse beoordeling van wensen en communitysignalen testen, zullen we productmanagers inschakelen om communitysignalen te integreren in hun kwartaal- en jaarlijkse planningsprocessen.
PES1.3.1	Als we tegen het einde van Kwartaal 1 3 functionele planningssessies coördineren met de communicatieafdeling en productteams om de berichtgeving, creatieve behoeften en campagnetijdlijnen voor WP25-initiatieven op elkaar af te stemmen, dan zullen we de creatieve briefings voor alle 3 de campagne-experimenten (25YiR, Easter Eggs, WikiRun) afronden.
PES1.3.2	Als we een stuurgroep instellen met vertegenwoordigers van Design en feature engineering, kunnen we basismaatstaven definiëren voor bijdragen aan de Codex: bekendheid, gebruik, kwaliteit van de bijdrage en kwantiteit. Inzichten uit het beoordelen aan de hand van deze basismaatstaven zullen ons helpen een routekaart te bepalen voor het bundelen van groei en diversificatie van de Codex-bijdragers.

Kwartaal 2

Het tweede kwartaal van het WMF jaarplan gaat over oktober - december.

Wiki Experiences (WE) Hypothesen [ WE Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 2 tekst	Details en discussie
WE1.1.1	Als we een vooraf bepaalde set van leidende indicatoren analyseren ≥2 weken na de start van de A/B-test Paste Check, kunnen we identificeren welke – indien van toepassing – facetten van de end-to-end-ervaring moeten worden aangepast of onderzocht voordat we zeker kunnen zijn van evaluatie van de impact van de functie.
WE1.1.4	Als we Reference Check op en.wiki inzetten via een gecontroleerd experiment, zullen we een toename van ≥4% zien in het aantal constructieve bewerkingen dat nieuwe(re) vrijwilligers publiceren en leren of er voldoende steun is onder patrollers en moderators om de functie op grotere schaal in te schakelen.
WE1.1.7	Als we een vooraf bepaalde set van leidende indicatoren analyseren ≥2 weken na de start van de A/B-test Tone Check, kunnen we vaststellen welke – indien van toepassing – facetten van de end-to-end ervaring moeten worden aangepast of onderzocht voordat we zeker kunnen zijn bij het evalueren van de impactvan de functie.
WE1.1.8	Als we het Tone Check-model toepassen op gepubliceerde artikelen, zullen we leren of we de ≥ 10.000 toonproblemen (elke met een waarschijnlijkheidsscore van 0,8 of hoger) kunnen identificeren die nodig zijn om een pool van suggesties van hoge kwaliteit (nauwkeurigheid ≥ 70%) te bouwen om bewerkers te helpen bij het verbeteren van de toon van het artikel.
WE1.1.10	Als we ongeveer 10 ervaren vrijwilligers op en.wiki en fr.wiki interviewen die MisbruikFilters schrijven (en andere gadgets/scripts/templates/bewerking notificaties) om patrouille/moderatie werkstromen te automatiseren, zullen we ≥3 patronen/behoeften identificeren die de waardepropositie van door de gemeenschap geschreven Edit Checks zullen helpen vormgeven.
WE1.1.11	Als we een enquête verspreiden onder ≥500 succesvolle nieuwkomers[i] en gegevens van hoge kwaliteit verkrijgen die representatief zijn voor de bredere succesvolle nieuwkomerspopulatie, kunnen we ≥4 bruikbare inzichten identificeren die we kunnen gebruiken om prioriteit te geven aan welke aspecten van de ervaring bij het nieuw binnen komen moeten worden verbeterd.
WE1.1.12	Als we ≥3 vrijwilligers in staat stellen om ≥30 voorbeeldbewerkingen elk te evalueren, zullen we voor elk van de 10 nieuwe talen die we willen omschalen voor controle op de toon, leren hoe vaak vrijwilligers instemmen met modelvoorspellingen en kunnen we beslissen welke nieuwe wiki's we moeten benaderen om 'Tone Check' te implementeren.
WE1.1.13	Aangezien we "Een link toevoegen" hebben verkleind op 100% van de nieuwere vrijwilligers op de Engelse Wikipedia, zal de constructieve activering en behoud van nieuwkomers verbeteren, wat de constructieve bewerkingen van nieuwere vrijwilligers met ≥4% zal verhogen.
WE1.2.3	Als we de eis laten vallen dat iemand het recht van de evenementenorganisator nodig heeft om die registratie op kleine en middelgrote wiki's te gebruiken, dan zullen we tegen het einde van het boekjaar ten minste X meer evenementen* zien die op kleine en middengrote wiki's zijn gemaakt. de basislijn/doelstelling wordt nog niet berekend.
WE1.2.4	Als we de MVP van de gezamenlijke bijdragen met ten minste 2 verbeteringen herhalen, dan zullen er meer samenwerkingen worden gemaakt via de 'Event Registration'.
WE1.2.5	Als we een strategie voor het adopteren van 'Event Registration' op Wikimedia Commons in het begin van het tweede kwartaal vaststellen, kunnen we deze testen met organisatoren van minstens 1 grote campagne en 5 lokale organisatoren in staat stellen de functie te gebruiken.
WE1.3.3	Als we een experiment lanceren om een moderatordashboard te laten zien aan de nieuwere bewerkers, doet 10% van de bijdragers die het bezoeken dit twee weken achter elkaar.
WE1.4.1	Als we verbeteringen aanbrengen die zijn gedefinieerd in T396489 zullen we de trage query's voor recente wijzigingen op grote wiki's met ten minste 30% verminderen, waardoor Community Tech Volglijst Labels de database dus minder zal gaan belasten.
WE1.4.3	Als we recente veranderingen en een volglijst via hulpmiddelen laten doen, dan kunnen we een basislijn definiëren voor hoe vaak mensen op pagina's klikken.
WE1.5.1	Als we een dashboard implementeren om 7 bijdrager-statistieken te verkennen en de berekening van ten minste één metriek te standaardiseren met behulp van dbt, kunnen we bijdrager-productteams in staat stellen om zelf metrische inzichten te bieden en een standaard te ontwikkelen voor het opslaan van metrische berekeningslogica.
WE1.5.2	Als we in Kwartaal 2 bepalen welke moderatieacties moeten worden opgenomen in de definitie van wie een moderator is, dan kan het team Movement Insights de metriek van maandelijkse actieve moderators in de Kwartalen 3 en 4 uitbouwen.
WE2.1.3	Als we meer te weten komen over de ervaring van bewerkers bij het maken van nieuwe artikelen en secties (inclusief motivaties, pijnpunten en hun reactie op nieuwe ideeën over hoe we deze beter kunnen ondersteunen), dan zullen we gebruikersbehoeften en -gedrag blootleggen die bruikbare inzichten en strategieën bieden om product, ontwerp en engineering te informeren over het verbeteren van de ervaring bij het maken van artikelen.
WE2.2.12	Als we Wikifunctions uitrollen naar wiki's waar Parsoid is ingeschakeld, kunnen we blijven testen of het systeem performant en bruikbaar blijft in een steeds bredere uitrol.
WE2.2.13	Als we de beschikbaarheid van de functie conjugatietabel met de Wiktionary-gemeenschap socialiseren, zullen we waardevolle feedback krijgen over het gebruik van functies en inzichten in onze gebruikers die we kunnen toepassen op toekomstige uitrollen.
WE2.2.14	Als we kijken naar de Databox van de gemeenschap die werkt aan het gebruik van Wikidata voor infoboxen en onderzoeken of Wikifuncties kunnen helpen, zullen we in staat zijn om een eerste experiment voor Wikifuncties in infoboxen te identificeren.
WE2.2.15	Als we de gemeenschap bewust maken van de mogelijkheid om foutmeldingen te maken en te vertalen op Wikifunctions, zullen we een toename zien in het aantal nuttige foutmeldingen.
WE2.2.16	Als we de semantieke functies aan de gemeenschap laten zien, zullen we een toename van de grammaticale functies zien met 50%.
WE2.2.17	Als we een aangepaste component bieden voor het bekijken van Wikidata-verklaringen op Wikifunctions, zullen gebruikers beter in staat zijn om gegevens te begrijpen die uit Wikidata zijn opgehaald en zich minder overweldigd voelen.
WE2.2.18	Als we 10x pieken in het geheugengebruik kunnen voorkomen, zal de orchestrator beter in staat zijn om met Wikidata-objecten om te gaan, wat het nut van Wikifuncties als platform voor Abstracte Wikipedia ondersteunt.
WE2.2.19	Als we gebruikers in staat stellen om directe links naar specifieke functieaanroepen te delen - inclusief hun invoer - zullen bijdragers in staat zijn om functiegedrag gemakkelijker te reproduceren, te verifiëren en te bespreken, wat op zijn beurt het debuggen zal versnellen, testworkflows zal verbeteren en het gezamenlijk oplossen van problemen in de Wikifunctions-gemeenschap zal ondersteunen.
WE2.3.1	Als we de beslissing voor het maken van een nieuwe wiki afronden en een naam met de gemeenschap bepalen, kunnen we de oprichting van deze nieuwe wiki breder socialiseren met onze stakeholders en ons voorbereiden op de logistiek van een mogelijke productnaamswijziging.
WE2.3.2	Als we een MVP definiëren voor een abstract wiki-prototype dat de kleinst mogelijke ervaring bevat voor het testen van onze back-end en NLG-mogelijkheden, en ons in staat stelt iteratief te ontwerpen, kunnen we in Kwartaal 3 een productie prototype plannen en lanceren.
WE2.3.3	Als we met de gemeenschap beginnen te praten en potentiële ontwerpen te verkennen voor de gebruikerservaring van een Abstracte wiki, zullen we in Kwartaal 3 in staat zijn om het werk verder te zetten.
WE2.4.1	Als we Wikidata en WDQS-gebruiks-cases verzamelen van WMDE- en WMF-teams, kunnen we productvereisten voor infrastructuurverbeteringen definiëren.
WE2.4.2	Als we een geaggregeerd rapportage-weergave van de belangrijkste prestatie-indicatoren (KPI's) met bestaande service-level-doelstellingen (SLO's) voor Wikidata en WDQS produceren, zullen we in staat zijn om succescriteria te formuleren en te volgen voor verbeteringen van de technische infrastructuur die de kritische Wikidata-use-case ondersteunt.
WE2.4.3	Als we binnen het kwartaal alternatieve opslag voor Blazegraph kunnen evalueren en benchmarken met behulp van realistische criteria, kunnen we een datagestuurde migratiebeslissing nemen en een concrete routekaart formuleren met tijdlijn en vereisten aan resources.
WE3.1.1	Als we een verbeterde versie van de functie Browsen met tabbladen testen, zien we een toename van 5% in het meerdaagse gebruik onder Tabs-gebruikers.
WE3.1.3	Als we een nieuwe manier bieden voor gebruikers om door relevante afbeeldingsinhoud op artikelpagina's te bladeren, en deze testen met een subset van uitgelogde lezers via een A/B-test op een set wiki's, zullen we een klikfrequentie van ten minste 3% hoger zien onder gebruikers die deze functie te zien krijgen.
WE3.1.4	Als we lezers verschillende concepten laten zien voor het doorkruisen van het kennisnetwerk op de wiki's, krijgen we een geprioriteerde lijst van concepten voor verdere ontwikkeling.
WE3.1.5	Als we weblezers de mogelijkheid bieden om een machinaal vertaalde versie van Wikipedia-inhoud te bekijken die niet beschikbaar is in hun taal, zullen we leren of de leesactiviteit is toegenomen, gemeten als een toename van 3% in pagina-interacties, waardoor lezers naar de lokale taalwiki worden getrokken met een mogelijke toename van lokale bewerkingsactiviteit. Dit zal worden aangeboden als een gecontroleerde A/B-testinstelling voor niet langer dan 6 maanden, en in 13 Wikipedia's met voorafgaande toestemming, met behulp van open machinevertalingsdiensten die al beschikbaar zijn voor Wikipedia-editors.
WE3.1.6	Als we een prototype produceren voor semantisch zoeken en Q&A in het artikel, geleverd als een demo-interface die de huidige aanpak contrasteert met nieuwe verkennende benaderingen, dan kunnen de lezersteams kwalitatief evalueren hoe elke benadering presteert in verschillende gebruikerstrajecten en hiaten of kansen voor verdere iteratie aan het licht brengen.
WE3.1.7	Als we bestaand onderzoek bekijken over hoe lezers omgaan met zoek- en navigatiehulpmiddelen op Wikipedia en hoe ze extern zoeken gebruiken om kennis op Wikipedia te vinden, kunnen we de lezersteams voorzien van ≥3 bruikbare aanbevelingen en bevindingen die hen helpen bij het bepalen van een zoek- en ontdekkings-MVP om hiaten in de verwachtingen en behoeften van lezers aan te pakken.
WE3.1.8	Als we 2 semantische prototypes voor zoeken (natural language search, Q&A) evalueren met externe deelnemers, kunnen we leren of gebruikers waarde zien in verbeterde zoekhulpmiddelen, en de lezersteams een aanbeveling doen over hoe verder te gaan met een zoek- en ontdekkings-MVP.
WE3.1.9	Als we in een kwalitatief onderzoek high-fidelity ontwerpconcepten voor het ontdekken van inhoud door middel van semantisch zoeken laten zien aan 10-20 toevallige Wikipedia-lezers, zullen we een positief sentiment voor de functie zien en het vertrouwen krijgen dat nodig is om door te gaan met een MVP voor zoeken en ontdekken die vertrouwt op korte, door mensen geschreven fragmenten om zoekopdrachten te zoeken.
WE3.1.10	Als we 10 toevallige lezers een live prototype van de nieuwe browse-ervaring voor afbeeldingen laten zien in een niet-gemodereerd gebruikersonderzoek, zullen we ten minste één UX-verbetering ontdekken voor toekomstige iteraties van de functie.
WE3.1.11	Als we het matchen van trefwoorden in Zoeken versoepelen, ondersteunen we zoekopdrachten in natuurlijke taal beter en stellen we het Product in staat om deze mogelijkheid te evalueren, op te nemen in de manier waarop ze werk ontwerpen, prioriteren en leveren in de semantische zoekruimte.
WE3.1.14	Als we een A/B-test lanceren van een versie van de mobiele site die navigatie introduceert die standaard alle secties opent, zullen we vroege indicatoren zien die wijzen op een toename van de sessieduur (we rapporteren de volledige A/B-testresultaten in kwartaal 3)	T409163
WE3.2.5	Als we een functie Jaaroverzicht op Android introduceren die de impact op gebruikers benadrukt en geïntegreerde donateursberichten bevat, stimuleren we nieuw donatiegedrag en zien we een toename van 5% in het app-menu in vergelijking met 2024.
WE3.2.6	Als we de donateursdia's in het iOS-jaaroverzicht meer geïntegreerd en gepersonaliseerd maken, zien we een toename van 5% in donaties ten opzichte van 2024.
WE3.3.3	Als we ten minste één ontgrendelbare avatar introduceren in de Android-app voor accounthouders, die is verdiend via zinvolle lezersacties, zoals het opslaan van een bepaald aantal artikelen, verhogen we de herhaalde betrokkenheid van ingelogde gebruikers bij de bijbehorende actie met 10% gedurende meerdere dagen.
WE3.3.4	Als we ingelogde lezers de mogelijkheid geven om artikelen op te slaan in een privéleeslijst, verwachten we dat de betrokkenheid op de site zal toenemen, gemeten aan de hand van een toename van 5% in intern verwijzingsverkeer voor lezers die de functie gebruiken, en een statistisch significante toename voor alle gebruikers.
WE3.3.6	Als we gegevens over artikelonderwerpen beschikbaar stellen via een service die voldoet aan de overeengekomen vereisten voor schaalbaarheid en beschikbaarheid, plus eventuele noodzakelijke gegevensaanvullingen, hebben we de technische basis gelegd die nodig is om toekomstige gepersonaliseerde lezerservaringen te ondersteunen die afhankelijk zijn van deze gegevens.
WE3.3.7	Als we gebruikmaken van de verwerkingsmogelijkheden van het dataplatform om op maat gemaakte statistieken over bewerkers en impactgegevens samen te voegen en de geaggregeerde gegevens te leveren via geschikte services met gedefinieerde SLO's, kunnen we toekomstige iteraties van WE3.3.1 Jaar in beoordeling en WE3.3.2 Tab Activiteit verbeteren.
WE3.3.9	Als we Jaar in beoordeling op Android en A/B-tests uitbrengen die betrokken gebruikers een beloning bieden om een aangepaste leeslijst op te slaan, zullen we een toename van 1% zien in het totale retentiepercentage van apps onder lezers die de beloning krijgen aangeboden in vergelijking met degenen die dat niet krijgen aangeboden.
WE3.3.10	Als we een A/B-test uitvoeren waarbij een account de gepersonaliseerde leesinzichten van het jaaroverzicht kan bekijken, zien we een toename van 1% in het totale retentiepercentage voor gebruikers die een account moesten hebben, vergeleken met gebruikers die dat niet moesten hebben.
WE3.3.11	Als we een verbeterde versie van het tabblad "Activiteit" op iOS A/B-testen dat lees-, bewerkings- en ander participatiegedrag belicht, zien we een toename van 5% in meerdaagse bezoeken van ingelogde lezers aan het tabblad in vergelijking met de prototypeversie.
WE3.4.1	Als we werken aan een hybride point of presence (PoP/CDN) implementatie, kunnen we zowel volledige PoP's als mini PoP's (fysiek en cloud) naar voren brengen, zoals vereist, waardoor de basis wordt gelegd voor een prototype van een mini PoP-implementatie in de toekomst.
WE3.5.1	Als Product & Technology en Fundraising samen technische benaderingen voor het identificeren van donateurs binnen onze platforms evalueren en documenteren, kunnen we een korte- en langetermijnoplossing aanbevelen die privacy, haalbaarheid en impact in evenwicht houdt. Dit gedeelde begrip zal helpen om de besluitvorming op elkaar af te stemmen, aanhoudende erkenning van donateurs op verschillende platforms mogelijk te maken, evenals meer gerichte experimenten in toekomstige functies met betrekking tot fondsenwerving.
WE3.6.3	Als we gemeenschappen betrekken bij gesprekken over de veranderende behoeften van lezers en over de veranderende aard van kennis op internet, kunnen we een gedeelde focus opbouwen op hoe we lezers van dienst kunnen zijn en samenwerken aan het al dan niet testen van onze verschillende ideeën (inclusief die rond multimedia, zoeken en ontdekken, en machine learning).
WE3.6.4	Als we onderzoek doen naar de verschillende motivaties, gedragingen en behoeften achter wanneer, waarom en hoe lezers Wikipedia en andere kennisplatforms gebruiken, kunnen we prioriteitsgebieden en specifieke initiatieven voor de consumentenstrategie voorstellen.
WE3.6.5	Als Product & Technology en Fundraising samenwerken aan een gedeelde strategie om de donatiemogelijkheden op het platform te diversifiëren en lezers die doneren te beheren en te erkennen, zullen we duidelijke, op elkaar afgestemde doelen en statistieken vaststellen die zijn gekoppeld aan onze consumenten- en fondsenwervingsstrategieën.
WE3.6.6	Als we een uniforme meetstrategie ontwikkelen, zullen we de evaluatie van de meerjarenstrategie van de consument mogelijk maken en een routekaart definiëren om de ontwikkeling van metrieken en rapportage mogelijkheden te begeleiden.
WE4.1.1	Als we een prototype maken van een minimaal levensvatbare niet-nood-flow en een iteratieve feedback openhouden terwijl we deze ontwikkelen met gebruikers met uitgebreide rechten, dan zullen deze groepen een uitgebreide implementatie van deze flow ondersteunen.
WE4.1.3	Als we 7 Wikipedia's (Frans, Duits, Spaans, Hongaars, Italiaans, Pools en Portugees) tegen het einde van oktober bijwerken, zullen we fase 1 van de nieuwe Legal Footer-uitvoering voltooien als antwoord op de voorwaarden van de DSA.
WE4.1.4	Als we het incident reporting system MVP in minstens 15 wiki's gebruiken, met de focus op grotere complexe gemeenschappen, zullen we zien dat het wordt gebruikt zoals bedoeld door de gemeenschap, en zullen we een werkmodel hebben aangetoond voor het rapporteren van incidenten zonder noodgevallen.
WE4.1.5	Als we een flowdiagram ontwerpen voor het melden van misbruikincidenten aan wiki's zonder vastgestelde processen voor het afhandelen van misdrijf, zal dit de invoering van het incidenten melden systeem op dergelijke wiki's stimuleren en gebruikers op die wiki's in staat stellen een duidelijk en levensvatbaar pad voor ondersteuning te hebben.
WE4.2.3	Als we gegevens analyseren van de proef voor het aanmaken van een hCaptcha-account, krijgen we inzicht in de trechter voor het maken van accounts, de effectiviteit van de puzzel en scores van hCaptcha en beschikken we over de gegevens die nodig zijn om de verdere uitrol van hCaptcha bij het aanmaken van accounts te informeren.
WE4.2.5	Als we onderzoek doen, overleggen met gemeenschappen en technische oplossingen onderzoeken, kunnen we een reeks gestructureerde blokredenen definiëren die op alle WMF-wiki's kunnen worden gebruikt.
WE4.2.6	Als we de mogelijkheid ontwikkelen om op OpenSearch gebaseerde clusters op het Data Platform te implementeren, zullen productkenmerken-engineeringteams in staat zijn om systemen te ontwikkelen die deze mogelijkheid integreren, met een grote mate van autonomie, veerkracht en isolatie van andere op zoekopdrachten gebaseerde systemen. De eerste en belangrijkste tenant voor dit systeem is de IPoid-service.
WE4.2.7	Als we hCaptcha Enterprise-integratie uitrollen verschillende productie-Wikipedia's als een pilotproef, zullen we in staat zijn om gegevens te verzamelen over de werkzaamheid en waarde van hCaptcha Enterprise op het gebied van antimisbruik, botdetectie, bruikbaarheid en toegankelijkheid.
WE4.2.8	Als we de hCaptcha proxy productie-klaar maken door de beschikbaarheid en waarneming te verbeteren, zullen we in Kwartaal 1 een stabieler en betrouwbaarder service leveren aan productie-Wikipedia's.
WE4.2.9	Als we de hCaptcha SDK integreren in de interne mobiele apps, de interne app-gebruikerservaring evalueren met wat hCaptca-uitdagingen mogelijk maakt als onderdeel van de accountcreatie-API, zullen we voldoende kennis hebben om de verdere uitrol van hCaptça voor de accountcreation API te informeren.
WE4.2.11	Als we hCaptcha in staat stellen om bots te detecteren in scenario's met een hoger risico, zien we dat hCaptha automatisch misbruik kan verminderen.
WE4.2.16	Als we met relevante WMF-teams overleg hebben, kunnen we een overeengekomen plan ontwikkelen om meer gedetailleerde toegang van gebruikers tot niet-publieke gegevens te beheren en de implementatie van niet-publieke defensieve software-regels te ondersteunen.
WE4.2.17	Als we voorbeelden uit de praktijk analyseren en CheckUsers interviewen om ten minste 2 signalen van mogelijk misbruik uit het prototype van de bewerkingsgeschiedenis te identificeren, zal het team Product Safety and Integrity deze signalen later kunnen opnemen in de functie Voorgestelde onderzoeken met een hoger niveau van vertrouwen dat de signalen waarde zullen bieden.
WE4.3.2	Als we JA4H fingerprints gebruiken, die het gedrag van HTTP-cliënten samenvatten, kunnen we botverkeer beter identificeren en categoriseren.
WE4.4.1	Als we verbeteringen kunnen aanbrengen op basis van feedback van pilots en tijdelijke accounts kunnen inzetten voor alle projecten, kunnen we de blootstelling van persoonlijk identificeerbare informatie (IP-adressen) van niet-geregistreerde gebruikers op al onze projecten beschermen tot minder dan 0,1% van alle (geregistreerde) gebruikers
WE4.4.2	Als we duidelijk en op tijd communiceren met de relevante belanghebbenden van de beweging (inclusief wiki-gemeenschappen en globale functionarissen), kunnen we op alle resterende wiki's implementeren, de werklast verminderen die op het laatste moment wordt ontdekt en voorkomen dat de implementatie wordt teruggedraaid.
WE4.4.5	Als we de wrijving verminderen voor patrouilles om kwaadwillenden te identificeren die tijdelijke accounts gebruiken om te vandaliseren, zullen we in staat zijn om een toename van vandalisme te voorkomen door geen toename van het terugdraaipercentage te meten op alle wiki's met tijdelijke accounts.
WE4.4.6	Als we de extensie LiquidThreads laten vervallen, zullen we de tijdelijke accounts deblokkeren die worden geïmplementeerd voor alle projecten die nu gebruikmaken van deze extensie.
WE4.6.1	Als we het synchronisatie-accountproces binnen Zendesk voor het opnieuw instellen van wachtwoorden automatiseren, zal dit de last voor T&S verlichten en hen in staat stellen om meer inkomende 2FA-resetverzoeken te verwerken
WE4.6.3	Als we alle gebruikers met een bevestigd e-mailadres toestaan om 2FA in te schakelen voor hun accounts, maar deze wijziging niet proactief aan gebruikers adverteren, blijft onze belasting van de herstelondersteuningsdesk op een duurzaam niveau.
WE4.6.4	Als we doorgaan met het herzien van de gebruikerservaring van ons 2FA-systeem en ondersteuning voor passkeys toevoegen, zullen meer gebruikers meerdere authenticatiefactoren registreren en beter beschermd zijn tegen het verliezen van accounttoegang.
WE4.6.5	Als we een algemeen kader ontwerpen en bouwen voor het specificeren van vereisten waaraan de leden van een lokale of internationale groep moeten voldoen, zullen we dit kader gebruiken om af te dwingen dat leden van de groep "temporary-account-ip-viewer" voldoen aan bestaande beleidsvereisten.
WE4.6.6	Als we onderzoeken hoe gebruikers met uitgebreide rechten (UWER) vertrouwen op User Scripts, kunnen we een plan voorstellen, dat de UWER-gemeenschap zou kunnen ondersteunen, om een of meer belangrijke technische interventies uit te voeren die het systeem User Scripts op een zinvolle manier zouden beveiligen.
WE4.6.7	Als we de gebruikerservaring en technische wijzigingen evalueren die nodig zijn voor de native mobiele apps om de mobiele aanmeldingservaring af te stemmen op het webplatform, door alternatieve mechanismen zoals OAuth te verkennen, kunnen we de haalbaarheid van integratie bepalen, in het belang van het bieden van een veiligere en consistentere ervaring voor gebruikers.
WE4.6.8	Als we de impact monitoren van de Zendesk- en MediaWiki-formulieren die we in Kwartaal 1 hebben gebouwd, kunnen we technische interventies voor toekomstige kwartalen voorstellen die de rest van het accountherstelproces beter automatiseren.
WE5.1.2b	Als we meerdere methoden voor identificatie en verificatie van ontwikkelaars integreren in de API-gateway, kunnen we een passende snelheidslimiet toewijzen aan elk verzoek door verzoeken die afkomstig zijn van verschillende gebruikersgroepen correct te identificeren.
WE5.1.3b	Als we een dummy run uitvoeren voor snelheidsbeperking op ten minste 3 routes van de REST-gateway, kunnen we de haalbaarheid van snelheidsbeperking met betrekking tot het verbruik van hulpbronnen verifiëren en een eerste reeks limieten definiëren die kunnen worden afgedwongen met minimale impact op de gebruiker.
WE5.1.4b	Als we de voorgestelde mechanismen voor API-gebruikerssegmentatie valideren met bredere datasets en handmatige beoordelingen van de geïdentificeerde groepen, kunnen we de gebruikersgroepen afronden, de methodologieën die voor de berekening worden gebruikt, verfijnen en hun doeltreffendheid beter begrijpen.
WE5.1.5	Als we samenwerken met het team MediaWiki Platform op het gebied van verkeersidentificatie en snelheidsbeperking, kunnen we snelheidslimieten implementeren voor het testen van dummy runs in productie, door het team Platform te ondersteunen bij het maken en uitrollen van deze mogelijkheid.
WE5.2.1b	Als we in gesprek gaan met potentiële gebruikers van de nieuwe REST API Explorer, kunnen we belangrijke inzichten in bruikbaarheid identificeren die aangeven of het nieuwe ontwerp gebruiksvriendelijk is en is afgestemd op het mentale model van ontwikkelaars.
WE5.2.2b	Als we de Action-API via de centrale API-gateway routeren, kunnen we beginnen met het consequent meten van verkeers- en gebruikspatronen om inzichten te verkrijgen die toekomstige beslissingen en acties zullen onderbouwen.
WE5.2.4	Als we standaard documentatiepatronen implementeren voor 2 API's, kunnen we de inhoudsrichtlijnen verfijnen, begrijpen wat API-eigenaren nodig hebben om de richtlijnen toe te passen en de inspanning kwantificeren die nodig is om de richtlijnen te implementeren in de resterende Wikimedia API-documenten.
WE5.2.5	Als we experimenteren met het definiëren en toepassen van OpenAPI-specificatieregels op de MediaWiki REST API's, zullen we een manier demonstreren om API-stijlgidsen programmatisch af te dwingen om de kwaliteit en consistentie van API's die op Wikimedia en onze gemeenschappen worden gepubliceerd, te verbeteren.
WE5.3.1	Als we de richtlijnen voor UX-attributie uitbreiden en stroomlijnen terwijl we bestaande richtlijnen bijwerken, stellen we een kernset van verbeterde richtlijnen op die klaar zijn om intern te worden getest en iteratief te worden verfijnd om voorbereid te zijn op breder openbaar gebruik.
WE5.3.1b	Als we de concept-UX-richtlijnen en demo's publiceren en herhalen, zullen we een kernraamwerk opstellen dat klaar is om intern te worden getest en iteratief te worden verfijnd om te worden voorbereid op breder openbaar gebruik.
WE5.3.2	Als we een pitch maken die de voordelen van het toeschrijven van Wikipedia aan 3e partij inhoud hergebruikers en hun eindgebruikers demonstreert, kunnen we WME4.1 en WME4.2 ondersteunen door ten minste één extra hergebruikpartner in staat te stellen om tegen het einde van Kwartaal 1 in te stemmen met het verschijnen in een casestudy of demo van een attributie.
WE5.4.2b	Als we een schaalbare manier bouwen om bekende klanten te identificeren, kunnen we uitzonderingen op algemene tarieflimieten voor bots van geverifieerde oorsprong toestaan en overgaan tot systematische handhaving van onze regels.
WE5.4.5	Als we beginnen met het afdwingen van tarieflimieten die zijn afgestemd op verschillende classes van individuele klanten, zullen we de last van het "crawlen / schrapen" op onze infrastructuur verminderen.
WE5.4.6	Als we aan het einde van Kwartaal 2 de top N spiders hebben geclassificeerd als bekende bots, kunnen we de hoeveelheid bronnen die ze gebruiken beperken.
WE5.4.7	Als we genoegen nemen met een gestandaardiseerde set van toegestane miniatuurformaten op onze media-infrastructuur, en we genereren de duurste vooraf terwijl het genereren van verschillende afbeeldingsformaten de snelheid beperkt, zullen we de last voor de media-infrastructuur verminderen.
WE6.1.2	Als we wikifarms toevoegen aan een pre-merge testomgeving, zullen ontwikkelingsteams die tegen productie moeten bouwen in staat stellen om hun patches afzonderlijk te testen, waardoor ze meer vertrouwen krijgen in de pre-productie en minder fouten hoeven te voorkomen.
WE6.2.1	Als we onze Production Readiness Checklist herzien en publiceren, waarin duidelijk de voorwaarden worden gedefinieerd om een service als productieklaar te beschouwen, samen met zelfservicebare taken, zullen we de verwachtingen tussen SRE's en ontwikkelingsteams op elkaar afstemmen, waardoor onze algehele operationele efficiëntie en schaalbaarheid worden verbeterd.
WE6.2.2	Als we aankondigen dat we een Golang- en nodejs-bibliotheek maken die veel moeizame taken voor ontwikkelaars abstraheert, zullen ze reageren met feedback en interesse.
WE6.2.4	Als we de Data Persistence-ontwerpbeoordeling toepassen en actief ondersteunen, kunnen we betere paden naar productie identificeren.
WE6.3.2	Als we nieuwe metrieken ontwikkelen, de cache-infrastructuur van Parsoid verbeteren en implementeren op twee "top-tien" wikipedia's, zullen we prestatiecriteria ontwikkelen voor het betrouwbaarheidskader, die zullen helpen bij het valideren van onze gereedheid voor implementatie op andere grote wiki's en ons vermogen zullen aantonen om op grote schaal met grote verkeersvolumes om te gaan.
WE6.3.3	Als we kritieke verbeteringen in de ondersteuning voor taalvarianten implementeren en Parsoid in Kwartaal 2 met succes implementeren op ten minste 3 taalvariantwiki's, zullen we de belangrijkste technische uitdagingen identificeren en oplossen die nodig zijn om met vertrouwen uit te rollen naar alle andere taalvariantwiki's.
WE6.4.6	Als SRE assistentie biedt aan de MediaWiki engineering teams - door middel van capaciteits- en verkeersbeheer, voorbereiding en beoordeling van configuratiewijzigingen, en samenwerking om problemen te onderzoeken en op te lossen - zullen we samen de productie PHP 8.3 upgrade in Kwartaal 2 voltooien en een reeks aanbevelingen documenteren om de afhankelijkheid van SRE van kritieke paden voor toekomstige upgrades te minimaliseren.	T360995
WE6.4.7	Als we zorgen dat ten minste 90% van alle gebruikers met globale root-toegang een hardware-ondersteunde SSH-sleutel gaat gebruiken voor toegang tot Wikimedia-productieservers, verminderen we het risico dat een gecompromitteerde laptop een ernstige inbreuk op de beveiliging veroorzaakt.
WE6.4.8	Als het MediaWiki Engineering Team actief problemen in MediaWiki met betrekking tot de PHP-upgrade controleert en oplost, zal dit het SRE-team in staat stellen om de productie van PHP 8.3-upgrade in november 2025 te voltooien.	T360995

Signals & Data Services (SDS) Hypothesen [ SDS Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 2 tekst	Details en discussie
SDS1.2.1	Als we het XML-dumpproces migreren van de huidige 'Dumps 1'-infrastructuur naar een datapipeline die gebruikmaakt van de MediaWiki Content Pipelines, kunnen we SLO's garanderen en de op 'Dumps 1' gebaseerde XML-export uitschakelen.
SDS1.2.2	Als we een walkthrough doen en de SLO's voor MediaWiki Content History en Event Platform / Event Gate beoordelen, kunnen we de klanten, statistieken en afhankelijke belanghebbenden valideren en verbeteringen identificeren die mogelijk nodig zijn voor de SLO's, wat ons zal helpen eventuele hiaten in onze wekelijkse leveringsgaranties te verhelderen.
SDS1.3.1	Als we signalen aan de clientzijde introduceren en deze controleren in vergelijking met de logboeken van webverzoeken aan de serverzijde, zullen we aanvullende botpatronen vinden die kunnen worden gekarakteriseerd.
SDS1.3.2	Als we uitgaan van de huidige bot-vs-mens-verdeling als basislijn en geautomatiseerde waarschuwingen maken voor verschuivingen in de distributie, zullen we de detectietijd van het volgende onvoorziene patroon van geautomatiseerd verkeer terugbrengen van weken naar minuten.
SDS1.3.3	Als we het aanvulmechanisme voor webverzoeken automatiseren en gebruiken in de logboeken van mei, zullen we de hersteltijd voor toekomstige incidenten terugbrengen van maanden naar dagen en het incident "stijging van het aantal paginaweergaven in mei" oplossen.
SDS1.3.4	Als we een regelmatig, geoperationaliseerd intern auditproces opzetten voor de output van botclassificaties, zullen we vertrouwen in onze oplossingen opbouwen en anticiperen op veranderingen in verkeerspatronen die niet automatisch worden gedetecteerd.
SDS1.3.5	Als we het basissignaal aan de clientzijde analyseren en in onze heuristieken opnemen, zullen we extra botpatronen in het dataplatform detecteren.
SDS1.3.6	Als we de Spur.us IP-reputatie importeren, analyseren en opnemen in onze heuristieken, zullen we extra botpatronen in het dataplatform detecteren.
SDS1.3.7	Als we een signaal van de rand importeren, analyseren en opnemen in onze heuristieken, zullen we extra botpatronen in het Data Platform detecteren.
SDS1.4.1	Als we de bestaande analyse van trends binnen het Wikimedia-ecosysteem opnieuw bevestigen - paginaweergaven, statistieken voor bijdragers en lezers, verkeer, enz. - zullen we in staat zijn om met vertrouwen de meest opvallende gesprekspunten te ondersteunen voor onze belangrijkste inzichten in de beweging.
SDS1.4.2	Als we de bestaande analyse van trends binnen het Wikimedia-ecosysteem opnieuw bevestigen - paginaweergaven, statistieken voor bijdragers en lezers, verkeer, enz. - zullen we in staat zijn om met vertrouwen de meest opvallende gesprekspunten te ondersteunen voor onze belangrijkste inzichten in de beweging.
SDS2.1.1	Als we nauw samenwerken met teams die experimenten uitvoeren, leren we hoe we het systeem in de toekomst meer zelfvoorzienend kunnen maken en tegen welke conceptuele of technische uitdagingen ze kunnen aanlopen.
SDS2.1.2	Als we een betere foutopsporing kunnen implementeren voor eventlogging, weten productteams dat hun experiment gebeurtenisgegevens verzamelt zoals verwacht, waardoor het vertrouwen van experimenteigenaren toeneemt.
SDS2.1.3	Als we de logboekregistratie en waarneembaarheid verbeteren voor het A/B-testsysteem (xLab) onderdeel van het experimenteerplatform, en voor de gerelateerde MediaWiki-onderdelen, kunnen we basislijnen vaststellen voor de prestaties van het systeem en reageren op experimentgerelateerde fouten.
SDS2.1.4	Als we één keer per maand verhalen over experimenten en -resultaten delen met de hele organisatie (via Product Ops-vergaderingen, ontwerpteamvergaderingen en teamoverschrijdende presentaties), dan creëren we een organische acceptatie van het experimenteerplatform.
SDS2.1.5	Als we gebruikers vertellen dat hun instrument, indien gemaakt in xLab, een set kenmerken bevat die de risicocategorie wijzigt, zullen we instrumentatiegebruikers ervan weerhouden om te veel gegevens te verzamelen en meer duidelijkheid te scheppen over welke combinatie van kenmerken privacybeoordeling vereist.
SDS2.1.6	Als het Growth Team werkt aan het instrumenteren van 2 use-cases (één met een A/B-test om inzicht te krijgen in bucketing-mogelijkheden, en één met langetermijninstrumentatie om meer te weten te komen over ondersteuning voor KPI-achtige metrieken) met het Experiment Lab, dan kunnen we evalueren of het voldoende voldoet aan de vereisten om onze op maat gemaakte experimenten in GrowthExperiments te vervangen.

Future Audience (FA) Hypothesen [ FA Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 2 tekst	Details en discussie
FA1.1.4	[Vervolg van vorig boekjaar] Als we een nieuwe Wikipedia-ervaring op Roblox bouwen, zullen we leren of dit een effectieve manier kan zijn om ons merk te introduceren bij een jonger (Gen Alpha) publiek.
FA1.1.2	Als we een centrale hub bouwen voor nieuwe Wikipedia-ervaringen op itch.io, dan kunnen we een publiek van >50 geïnteresseerde niet-Wikipedianen laten groeien die ons feedback geven, wat ons zal helpen te leren wat wel en niet werkt in games.
FA2.2.1	Als we investeren in gemeenschapsbeheer op platforms voor korte video's, zullen we tegen het einde van Kwartaal 2 (december 2025) een toename van 30% op kwartaalbasis zien in het percentage weergaven van nieuwe kijkers op TikTok - en op alle SFV-platforms zullen we in totaal 50.000 engagementen (likes en antwoordreacties) verdienen op merkreacties die zijn achtergelaten op externe inhoud, wat ons zal helpen de zichtbaarheid te vergroten en de betrokkenheid te vergroten bij doelgroepen die we nu niet bereiken.
FA2.2.2	Als we een interne strategie en externe deelbare producten van het Wikipedia Creator Partnerships Program ontwikkelen en ondertekenen (inclusief een overzicht van onze waarde voor makers, partnerschapscriteria, contractproces en hoe inhoud van makers zal worden weergegeven in eigen kanalen en kanalen van makers), zullen we in staat zijn om een robuuste strategie voor makers op te zetten die ons zal helpen met onze kennisinhoud nieuwe doelgroepen te bereiken op sociale media.

Product- en technische ondersteuning (PES) Hypothesen [ PES Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 2 tekst	Details en discussie
PES1.1.5	Als we de service level objectives (SLO's) voor MediaWiki Content History en Wikifunctions onboarden naar Sloth/Pyrra, krijgen we nog 2 SLO's in productie.
PES1.1.6	Als we Sloth testen met retroactieve gegevens van bestaande SLO's, zullen we begrijpen of Pyrra of Sloth (of iets anders) het juiste hulpmiddel is voor onze fixed-window-benadering van foutbudgetvensters. We zullen leren hoe we service-eigenaren kunnen ondersteunen met een selfservice-benadering van SLO-statistieken en deze kunnen gebruiken bij de besluitvorming.
PES1.2.4	Als we in Kwartaal 1 met 3 teams een driemaandelijkse beoordeling van wensen en communitysignalen testen, zullen we productmanagers inschakelen om communitysignalen te integreren in hun kwartaal- en jaarlijkse planningsprocessen.
PES1.2.5	Als we de mogelijkheid om op wensen te filteren en te sorteren op de extensie Wishlist toevoegen aan de verbeteringen die categorisatie met tags en stemmen mogelijk maken, zullen de 3 verbeteringen het aantal unieke deelnemers aan de wensenlijst met ten minste 30% verhogen.
PES1.3.3	Als we ten minste 5 goede interventies op het platform maken die plaatsvinden op basis van gebruikersinteracties, zullen we bepalen wat de triggers zullen zijn voor de portaalpagina en de gadget Birthday Mode. Door bruikbaarheidstesten zien we dan welke interventies positieve associaties met ons merk oproepen. Deze hypothese is tijdgebonden om eind oktober te eindigen op WikiCon Noord-Amerika.
PES1.3.4	Als we een meeslepende website maken die de geschiedenis, het heden en de toekomst van Wikipedia verkent, in samenwerking met leden van de afdeling Communicatie, gericht op het betrekken van online doelgroepen tussen 18-34 jaar in campagnedoelgebieden, zal het een grotere verbinding met Wikipedia simuleren via sociale netwerken en andere online activiteiten. Dit zal bijdragen aan de belangrijkste resultaten van Comms om de merkaanwezigheid met 10 procentpunten te vergroten, terwijl het ons vertelt of dynamische benaderingen van inhoud de sympathie van het merk verbeteren.

Kwartaal 3

Het derde kwartaal van het WMF-jaarplan beslaat januari-maart 2026.

Wiki Experiences (WE) Hypothesen [ WE Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 3 tekst	Details en discussie
WE1.1.3	Als het team Editing een eerste set bewerkingssuggesties beschikbaar stelt binnen VE via een URL-parameter en ≥10 nieuwkomers en patrouilleurs uitnodigt om feedback te geven, zullen we leren welke verbeteringen nodig zijn voordat we een gecontroleerd experiment uitvoeren om de impact van de interventie te evalueren.
WE1.1.4	Als we Reference Check op en.wiki inzetten via een gecontroleerd experiment, zullen we een toename van ≥4% zien in het aantal constructieve bewerkingen dat nieuwe(re) vrijwilligers publiceren en leren of er voldoende steun is onder patrollers en moderatoren om de functie op grotere schaal in te schakelen.
WE1.1.12	Als we ≥3 vrijwilligers in staat stellen om ≥30 voorbeeldbewerkingen elk te evalueren, zullen we voor elk van de 10 nieuwe talen die we willen schalen Tone Check ook, leren hoe vaak vrijwilligers instemmen met modelvoorspellingen en kunnen we beslissen welke nieuwe wiki's we moeten benaderen om Tone Check te implementeren.
WE1.1.14	Als we nieuwe(re) vrijwilligers aansporen om rekening te houden met de toon waarin ze schrijven wanneer een AI-model hen detecteert met niet-neutrale taal, dan zien we een daling van ≥4% in het percentage nieuwe contentbewerkingen die nieuwe(re) vrijwilligers publiceren en die op grond van WP:NPOV (en aanverwante beleid) worden teruggedraaid.
WE1.1.17	Als we een taakgeneratie-engine ontwikkelen voor de gestructureerde taak Revise Tone, zullen onze recente inzichten integreren over welke inhoud we moeten opnemen of filteren, en pipelines bieden die de takenlijst automatisch verversen, maken we een kwalitatieve evaluatie van de gegenereerde taken mogelijk en een A/B-experiment dat test of dit type taak nieuwkomers helpt om constructievere bewerkingen te maken.
WE1.1.18	Als we een vooraf bepaalde set leidende indicatoren ~2 weken na de start van de A/B-test Revise Tone Structured Task analyseren, kunnen we identificeren welke – indien aanwezig – facetten van de end-to-end ervaring moeten worden aangepast of onderzocht voordat we met zekerheid de impact van de functie kunnen beoordelen.
WE1.1.19	Als we mensen op het mobiele web in staat stellen om elk artikelgedeelte te bewerken, ongeacht het bewerkingspictogram waarop ze het eerst tikken, zal het verminderen van het aantal mobiele bewerkingen bij nieuwkomers met #% dalen omdat ze gemakkelijker de inhoud kunnen vinden die ze hebben gekozen om te veranderen.
WE1.1.20	Als het team Growth de taak "Voeg een link toe" op minstens 10 extra Wikipedia's schaalt, kunnen we de toonaangevende indicatorenanalyse voltooien om te bevestigen dat de taak presteert zoals verwacht en alle wiki's identificeren die mogelijk een verdere review vereisen.
WE1.1.21	Als we de nieuwe modelversie Voeg-een-link-toe inzetten op zowel nieuw geïntegreerde wiki's als wiki's die nu Voeg-een-link-toe gebruiken, dan zal het groeiteam Voeg-een-link-toe als een gestructureerde taak kunnen uitvoeren op wiki's waar het niet eerder bestond, en wiki's die de taak al hadden, zullen een bijgewerkt model ontvangen met frisse trainingsgegevens en verbeterde offline prestaties.
WE1.1.22	Als we de eerste e-mail "Welkom op Wikipedia" ter verificatie verbeteren, zal het percentage nieuwe accounts dat hun e-mailadres verifieert, toenemen. Dit zou Growth in staat stellen deze accounts opnieuw te betrekken via vervolg e-mails en ervoor te zorgen dat ze op de overlegpagina's meldingen ontvangen.
WE1.1.23	Als we gemakkelijk beschikbare GenAI-modellen opdracht geven om een set bewerkingssuggesties te genereren en te rangschikken voor een gevarieerd aantal van 150 Engelstalige Wikipedia-artikelen, dan leren we welke soorten bewerkingstaken deze generieke modellen op schaal kunnen produceren en krijgen we een globaal, anekdotisch begrip van het nut van deze suggesties. Dit vroege signaal helpt ons te beoordelen of sommige taaktypes plausibel op schaal met generieke modellen (met of zonder fine-tuning) kunnen worden gegenereerd, of dat ze meer gespecialiseerde benaderingen vereisen – wat ons uiteindelijk helpt te valideren of het nastreven van deze richting van "één model met veel suggesties" de moeite waard is.
WE1.1.24	Als we nieuwe(re) vrijwilligers die tekst van een externe site plakken vragen om te bevestigen of ze de inhoud hebben geschreven die ze proberen toe te voegen, dan zullen we een afname van ≥10% zien in het percentage nieuwe inhoudsbewerkingen die nieuwe(re) vrijwilligers publiceren die worden teruggedraaid op grond van WP:COPYVIO (en gerelateerd beleid).
WE1.2.6	Als we via "Event Registration" een functie doelstelling-instelling ontwikkelen, dan zullen er meer samenwerkingen worden gestart via "Event Registratie".
WE1.3.3	Als we een experiment lanceren om een moderatordashboard te laten zien aan de nieuwere bewerkers, doet 10% van de bijdragers die het bezoeken dit twee weken achter elkaar.
WE1.3.4	Als we het Revert Risk filter gebruiken voor 150+ andere Wikipedia's die nu geen schadelijke/goodfaith modellen hebben, dan zien we een toename van de aantal moderatorpatrouille voor medewerkers die het persoonlijke moderator dashboard gebruiken in vergelijking met degenen die geen toegang krijgen tot het dashboard.
WE1.5.1	Als we een dashboard implementeren om 7 bijdrager-statistieken te verkennen en de berekening van ten minste één metriek te standaardiseren met behulp van dbt, kunnen we bijdrager-productteams in staat stellen om zelf metrische inzichten te bieden en een standaard te ontwikkelen voor het opslaan van metrische berekeningslogica.
WE1.5.3	Als Data Engineering een dataproduct van bewerkingstypen produceert tegen het einde van Kwartaal 3, dan worden de 6 moderatoracties die "Ingewikkeld" zijn om te meten "Simpel", waardoor Movement Insights een maandelijkse actieve moderatormeting als volgende stap kan definiëren.
WE1.5.4	Als we een prototype dashboard met actieve moderatormetingen produceren die nu beschikbaar zijn, zullen we een volledig dashboard kunnen produceren tegen het einde van Kwartaal 4.
WE1.6.1	Als we aangepaste volglijstlabels introduceren, verwachten we dat de labels in de eerste maand door 5% van de gebruikers met meer dan 100 pagina's op hun volglijst zullen worden gebruikt.
WE2.2.13	Als we de beschikbaarheid van de conjugatietabel socialiseren met de Wiktionary-gemeenschap, zullen we vroege signalen verzamelen over het begrip en de bruikbaarheid van de redacteur waardoor we toekomstige verbeteringen kunnen sturen.
WE2.2.20	Als we Wikifuncties uitrollen naar wiki's waar Parsoid is ingeschakeld, kunnen we blijven testen of het systeem performant en bruikbaar blijft in een steeds bredere uitrol.
WE2.2.21	Als we een beperkte reeks reentrant-functies in de evaluator toestaan, zal het mogelijk zijn om de afhankelijkheid van geëvalueerde implementaties te verhogen en daarmee het meest presterende deel van de backend te benutten.
WE2.2.22	Als we een expliciete interpreter voor de compositietaal schrijven, zal de orkestrator meer uitvoerend zijn en zullen verdere prestatieverbeterende functies gemakkelijker te implementeren zijn.
WE2.2.23	Als we de bijdragers in staat stellen om volledige compositieblokken over functies te hergebruiken, zullen we herhalende werk verminderen en de oprichting van nieuwe implementaties, vooral voor vergelijkbare taalfuncties, aanzienlijk versnellen.
WE2.2.24	Als we een duidelijke documentatiestructuur en toegangspunten definiëren, zullen makers van functies gemakkelijker relevante begeleiding vinden en minder wrijving ervaren bij het maken van functies.
WE2.2.25	Als we systematisch de grootste wrijvingspunten in de functiecreatie-ervaring identificeren, kunnen we een kleine reeks impactvolle verbeteringen aantonen die het creëren en itereren van functies efficiënter maken.
WE2.2.26	Als we een lichte, lokale referentieoplossing (via pop-ups) introduceren voor Abstract Wikipedia, kunnen we een initiële mechanisme opzetten om te bepalen of complexere oplossingen nodig zijn.
WE2.3.4	Als we een eerste versie van het Abstract Wikipedia-platform bouwen en uitbrengen, kunnen we de technische haalbaarheid aantonen van het ecosysteem dat werkt in meerdere talen.
WE2.3.5	Als we met een klein aantal onderbedeelde Wikipedia-taalgemeenschappen in contact komen met een concreet voorbeeld van abstracte inhoud, kunnen we valideren of inhoud die buiten hun lokale wiki is gemaakt acceptabel is en voorwaarden identificeren die nodig zijn voor adoptie.
WE2.3.6	Als we ontwerpen hoe abstracte Wikipedia-inhoud wordt gepresenteerd binnen lokale Wikipedia's, en hoe lokale gemeenschappen integratiebeslissingen nemen, kunnen we het voorstel socialiseren, overeenstemming bereiken en met vertrouwen het ontwikkelingswerk in Kwartaal 4 plannen.
WE2.5.1	Als we de kandidaatvervanger voor Blazegraph in eqiad implementeren en het bestaande evaluatiewerk aanvullen met een productie-WDQS verkeersreplay-analyse, dan bevestigen we dat de nieuwe backend vergelijkbaar presteert, echte SPARQL-queries ondersteunt en klaar is voor beperkte live-traffic zodra het omliggende ecosysteem (UI, monitoring, onboarding en realtime indexupdate-pipeline) is voorbereid.
WE2.5.2	Als we toegangsrichtlijnen voor het Wikidata-platform definiëren, kunnen we beter controle hebben over de belasting die op WDQS-servers wordt geplaatst op het moment van onze backend-migratie.
WE2.5.3	Als we een groep gebruikers definiëren om ons nieuwe backendsysteem te testen, zijn we voorbereid op de pilot- en volgende fasen van de migratie van Blazegraph.
WE2.5.4	Als we een migratieplan in één document opstellen, kunnen we de uitvoering van alle aspecten van de migratie aanpassen en stimuleren.
WE2.5.5	Als we het Wikidata Revert Risk-model optimaliseren voor inferentie met lage latentie en het op een stabiele, schaalbare manier op LiftWing implementeren, zal het team Wikimedia Enterprise in staat zijn om revert-risicosignalen in hun productpijplijn te integreren, waardoor klanten tijdige, hoogwaardige modeluitkomsten kunnen ontvangen.
WE3.1.8	Als we twee semantische prototypes voor zoeken (natuurlijke taalzoek, Q&A) evalueren met externe deelnemers, kunnen we leren of gebruikers waarde zien in verbeterde zoekhulpmiddelen en de lezersteams een aanbeveling geven over hoe verder te gaan met een zoek- en ontdekkings-MVP.
WE3.1.12	Als we een benchmark dataset verzamelen bestaande uit een set representatieve vragen en annotaties van relevante zoekresultaten, kunnen we offline (d.w.z. zonder gebruikersstudies) zoekbeoordeling uitvoeren van de kwaliteit van zoekresultaten van verschillende zoekmodellen.
WE3.1.15	Als we in de Android-app hybride zoek-MVP's testen die zoekwoorden, natuurlijke taal en betekenisgebaseerde zoekopdrachten combineren, zullen we snel de aanpak en ontwerppatronen identificeren die de totale zoekbetrokkenheid met 10% verhogen zonder negatieve impact op tevredenheid, latentie of retentie.
WE3.1.16	Als we eisen voor een Q&A-model definiëren, produceren we model-uitkomsten om met de gemeenschap te delen voor feedback dat we kunnen integreren in een productie-experiment.
WE3.1.17	Als Search een productie-gereed (stabele, prestatieve) vectorzoekinfrastructuur biedt die semantische zoekverwerking ondersteunt - inclusief een MediaWiki-endpoint, kunnen ML en Research embeddings genereren en hun modellen integreren met het systeem, waardoor de MVP's embedding-powered ophalen mogelijk wordt.
WE3.1.18	Als we een Qwen3-embeddings-inferentieservice implementeren die compatibel is met onze bestaande OpenSearch-stack, kunnen mobiele apps experimenteren met het genereren van artikel-chunk- en query-embeddings via Qwen3, wat beter zou moeten presteren dan de embeddings die door de ingebouwde modellen van OpenSearch worden geproduceerd.
WE3.3.6	Als we gegevens over artikelonderwerpen beschikbaar stellen via een service die voldoet aan de overeengekomen vereisten voor schaalbaarheid en beschikbaarheid, plus eventuele noodzakelijke gegevensaanvullingen, hebben we de technische basis gelegd die nodig is om toekomstige gepersonaliseerde lezerservaringen te ondersteunen die afhankelijk zijn van deze gegevens.
WE3.4.1	Als we werken aan een hybride point of presence (PoP/CDN) implementatie, kunnen we zowel volledige PoP's als mini PoP's (fysiek en cloud) naar voren brengen, zoals vereist, waardoor de basis wordt gelegd voor een prototype van een mini PoP-implementatie in de toekomst.
WE3.5.2	Als we donateurs een badge aanbieden die hun status erkent, zal minstens 70% van de donateurs die zich aanmelden positief reageren op een gekoppelde enquête.
WE3.6.5	Als Product & Technology en Fundraising samenwerken aan een gezamenlijke strategie om donatiemogelijkheden op het platform te diversifiëren en lezers die doneren te beheren en te erkennen, zullen we duidelijke, afgestemde doelen en meetpunten stellen die aansluiten bij onze consumenten- en fondsenwervingsstrategieën.
WE3.6.6	Als we een uniforme meetstrategie ontwikkelen, zullen we de evaluatie van de meerjarenstrategie van de consument mogelijk maken en een routekaart definiëren om de ontwikkeling van metrieken en rapportage mogelijkheden te begeleiden.
WE3.6.7	Als we een secundaire A/A-test uitvoeren op het retentietempo voor gebruikers die zijn uitgelogd, zullen we seizoensgebonden trends voor retentie-verhoudingen opstellen die we later kunnen gebruiken.
WE3.6.8	Als we systematisch de informatiezoekbehoeften en gedragingen van 1) nieuwe en zeldzame Engelstalige Wikipedia-lezers en niet-lezers vergelijken met die van 2) huidige Engelstalige Wikipedia-lezers door beide populaties gelijktijdig te onderzoeken, kunnen we belangrijke inzichten identificeren over de demografische kenmerken, online informatiebehoeften en online platforms die door deze doelgroepen worden gebruikt, en potentiële kansen voor het groeien van ons lezerspubliek en potentiële bedreigingen van onze bestaande lezerspubliek.
WE3.8.1	Als we extra modules toevoegen aan het tabblad Activiteit en het aan alle gebruikers schalen, zien we een toename van 5% in de totale aanmaak van iOS-app-accounts vergeleken met vóór de release
WE3.9.1	Als we de visuele basis, standaardcomponenten en navigatiegedrag van de Wikipedia iOS-app bijwerken om te passen aan de taal van Liquid Glass van Apple - terwijl we het ontwerp en gedrag voor prioritaire terugval duidelijk definiëren in alle OS-versies - dan zal de downstream engineering-implementatie helderder, minder risicovol zijn en zal de app zich meer platform-eigen voelen dan wanneer Apple gebruikers dwingt om over te schakelen
WE3.10.1	Als we een prototype van de Explore Feed met een gebruikerstest testen, gebouwd met lichte personalisatie, duidelijke versheidssignalen en herhaalbare Wikipedia-interne patronen (bijv. thematische rabbit holes, tijdsgebonden markeringen en interactieve elementen), zullen lezers aangeven het doel van de voorgestelde feed te begrijpen, sneller een "aha"-moment bereiken en een sterkere intentie voor dagelijks gebruik tonen. Het visuele ontwerp dat we aanbevelen om verder te gaan, zal worden beschreven als behapbaar en in lijn met de Wikimedia-beweging.
WE4.1.3	Als we 6 Wikipedia's (Engels, Frans, Duits, Spaans, Italiaans, Pools) aan het einde van het tweede kwartaal bijwerken, zullen we fase 1 van de nieuwe Legal Footer-uitvoering voltooien als antwoord op de eisen van DSA.
WE4.2.5	Als we onderzoek doen, gemeenschappen raadplegen en technische oplossingen onderzoeken, kunnen we een reeks gestructureerde blokkade redenen definiëren die kunnen worden gebruikt op alle WMF-wiki's.
WE4.6.8	Als we de impact monitoren van de Zendesk- en MediaWiki-formulieren die we in Kwartaal 1 hebben gebouwd, kunnen we technische interventies voor toekomstige kwartalen voorstellen die de rest van het accountherstelproces beter automatiseren.
WE5.1.3c	Als we een uitrolverhouding beperken tot alle API's die via de gateway worden geleid, kunnen we het aantal anonieme API-aanvragen dat onze backend-infrastructuur bereikt, verminderen door verzoeken te beperken op basis van gebruikersklassen die hogere grenzen geven aan geautenticeerde en gemeenschapsgebruikers.
WE5.1.5	Als we de duurzaamheid en betrouwbaarheid van onze OAuth 2.0 implementatie verbeteren, zullen we meer ontwikkelaars kunnen overtuigen om OAuth te gebruiken en de migratie van de mobiele apps van Wikipedia te ondersteunen, door het vertrouwen te vergroten dat deze op hoge profielen van toepassingen kunnen worden vertrouwd.
WE5.1.5b	Als we de ontwikkelaarservaring verbeteren voor het maken en beheren van OAuth 2.0-clients, zullen we het aantal applicaties dat OAuth 2.0 gebruikt, kunnen verhogen door OAuth 1.0 voor nieuwe applicaties af te schrappen en OAuth 3.0 te promoten als de voorkeursoptie voor API-authenticatie.
WE5.2.2c	Als we alle API's die nu via de API Gateway gaan via de gemeenschappelijke gateway omleiden, kunnen we de historische API Gateway volledig afschaffen en consistentie waarborgen voor alle gemeenschapsgerichte Wikimedia HTTP/web API's
WE5.2.6	Als we toegangscontroles invoeren in de sitemap API zodat alleen vertrouwde bots worden toegestaan, kunnen we de strategische afstemming verbeteren en het risico op misbruik van scraping verminderen.
WE5.2.8	Als we speciale API-modules maken voor alle API-extensies en zelfstandige functionaliteiten binnen MediaWiki Core, zullen we handhaving mogelijk maken voor documentatie van hogere kwaliteit met onafhankelijk beheer en met versies.
WE5.2.9	Als we een betere scheiding van zorgen maken voor API-registratie en specificatieprocessen, zullen we de complexiteit van API-beheer vereenvoudigen en een betere ontwikkelaarservaring creëren voor API-makers.
WE5.2.10	Als we rond gaan om te luisteren voor gesprekken die specifiek gericht zijn op v2 API-consolidatie en functie-hiaten, kunnen we sneller werken aan een v2-implementatie.
WE5.2.11	Als we experimenteren en processen opzetten voor het standaardiseren van documentatie die nu in het API-portaal zit, kunnen we informatiebronnen consolideren en de consistentie van documentatie verbeteren.
WE5.3.1b	Als we de concept-UX-richtlijnen en demo's publiceren en herhalen, zullen we een kernraamwerk opstellen dat klaar is om intern te worden getest en iteratief te worden verfijnd om te worden voorbereid op breder openbaar gebruik.
WE5.3.2b	Als we een partnerpilotprogramma opzetten om te experimenteren met Wikimedia-attributie, kunnen we de wederzijdse voordelen van attributie door hergebruikers tonen om betrokkenheid en bijdragen aan Wikimedia te stimuleren.
WE5.4.6	Als we aan het einde van Kwartaal 2 de top N spiders hebben geclassificeerd als bekende bots, kunnen we de hoeveelheid bronnen die ze gebruiken beperken.
WE5.4.8	Als we snelheidslimieten gaan handhaven die zijn afgestemd op verschillende klassen individuele clients voor mediabestanden, zullen we de last van crawling op onze infrastructuur verminderen.
WE5.4.9	Als we IP-reputatiegegevens op residentiële proxies toevoegen aan onze botdetectie, verbetert dat onze mogelijkheid om scrapers te blokkeren
WE5.4.10	Als we stoppen met het toestaan van het genereren van niet-standaard miniatuurformaten, zal dat de druk op onze backend media-infrastructuur verminderen
WE5.4.11	Als we twee hoog-vertrouwde signalen van de scraping/DDoS-incidenten van december 2025 identificeren en deze aan SRE doorgeven, zal SRE effectievere geautomatiseerde mitigatieregels kunnen ontwikkelen voor toekomstige soortgelijke incidenten.
WE5.4.12	Als we kunnen bevestigen waar en van wie een verzoek om een afbeelding afkomstig is, kunnen we beter geïnformeerde beslissingen nemen over het beperken van de verwerkingssnelheid
WE6.1.2	Als we wikifarms toevoegen aan een pre-merge testomgeving, zullen ontwikkelingsteams die tegen productie moeten bouwen in staat stellen om hun patches afzonderlijk te testen, waardoor ze meer vertrouwen krijgen in de pre-productie en minder fouten hoeven te voorkomen.
WE6.1.3	Als we de top 5 onbetrouwbare Selenium-tests in de komende 90 dagen oplossen, vergroten we het vertrouwen van ontwikkelaars in geautomatiseerd browsertesten als een waardevol onderdeel van de pre-deployment workflow.
WE6.2.4	Als we de Data Persistence-ontwerpbeoordeling toepassen en actief ondersteunen, kunnen we betere paden naar productie vinden.
WE6.2.5	Door samen te werken met de SLO-groep en feedback te verzamelen van teams die nu met hen samenwerken, helpen we niet alleen hiaten en verbeteringen in de checklist Production Readiness te identificeren, maar deze ook zo aan te passen dat SLO-adoptie en onboarding direct mogelijk wordt
WE6.2.6	Door de checklist productiegereedheid op de hCaptcha-proxyservice te testen tegen lancerings- en belangrijke items, zullen we niet-gevolgde technische tekortkomingen identificeren en een zichtbare backlog creëren, die de waarde van het framework aantoont en tegelijkertijd een herhaalbaar proces vormgeeft voor consistente adoptie over services heen.
WE6.2.7	Door samen de checklist voor productiegereedheid te verfijnen met input en bijdragen van SRE's, zorgen we ervoor dat deze inspeelt op de echte operationele behoeften, bouwt gedeeld eigendom op en creëert een praktisch hulpmiddel waar teams waarde in zien om te adopteren.
WE6.2.8	Door feedback te analyseren van onze samenwerking met de SLO-groep, de hCaptcha-proxypilot en SRE-samenwerking, zullen we identificeren welke items van de checklist en processtappen duidelijkere richtlijnen of ondersteunende middelen vereisen, en bepalen we de volgende stappen om het kader te stroomlijnen zodat adoptie haalbaar is vóór de break in december.
WE6.2.9	Als we node.js service-utils adopteren, kunnen we op geteste wijze ofwel service-mesh routing of OpenTelemetrie-publicatie uitbrengen.
WE6.3.2	Als we nieuwe metricen ontwikkelen, de cache-infrastructuur van Parsoid verbeteren en implementeren op twee "top-tien" Wikipedia's, zullen we prestatiecriteria ontwikkelen voor het betrouwbaarheidskader, wat helpt om onze gereedheid voor uitrol naar andere grote wiki's te valideren en ons vermogen aantoont om grote volumes op grote schaal te verwerken.
WE6.3.3	Als we kritieke verbeteringen aan ondersteuning voor taalvarianten implementeren en Parsoid succesvol implementeren op ten minste 3 taalvariant-wiki's in Kwartaal 2, zullen we de belangrijkste technische uitdagingen identificeren en oplossen die nodig zijn om met vertrouwen naar alle resterende taalvariant-wiki's uit te rollen.
WE6.3.4	Als we bugs in de leeservaring van Parsoid Read Views QA'en, identificeren, triageren en verhelpen, behouden we de kwaliteit van de leeservaring en halen we de blokkade weg voor verdere schaalvergroting tussen wiki's
WE6.3.5	Als we een metriek 'Time To First Byte' (TTFB) van <= 110% van legacy voor parser-cache-hits en <= 150% van legacy voor ontbrekende parser-cache, kunnen we tegen het einde van Kwartaal 3 op alle Wikipedia's uitrollen behalve Chinees en Engels zonder prestatieklachten. Dit helpt onze gereedheid voor implementatie op de Engelse Wikipedia te valideren, zodat we kunnen voorbereiden op grote hoeveelheden verkeer door onze cachecapaciteit te begrijpen.
WE6.4.4	Als we onze domeinen verenigen door alle paginaweergaven op MediaWiki-sites via een canoniek domein te laten gaan, zullen we de platformcomplexiteit en SEO-risico's verminderen door de mobiele subdomein-doorverwijzing te elimineren. Voltooiing wordt gemeten door het aantal doorverwijzingen voor mobiele bezoeken op canonieke domeinen te verlagen van 100% naar 0%.
WE6.4.7	Als we zorgen dat ten minste 90% van alle gebruikers met globale root-toegang een hardware-ondersteunde SSH-sleutel gaat gebruiken voor toegang tot Wikimedia-productieservers, verminderen we het risico dat een gecompromitteerde laptop een ernstige inbreuk op de beveiliging veroorzaakt.
WE6.4.8	Als het MediaWiki Engineering Team actief de problemen in MediaWiki met betrekking tot de PHP-upgrade monitort en oplost, zal dit het SRE-team in staat stellen de productie-PHP 8.3-upgrade uiterlijk november 2025 te voltooien.

Signals & Data Services (SDS) Hypothesen [ SDS Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 3 tekst	Details en discussie
SDS1.5.1	Als we een regelmatig, geoperationaliseerd intern auditproces opzetten voor de output van botclassificaties, zullen we vertrouwen in onze oplossingen opbouwen en anticiperen op veranderingen in verkeerspatronen die niet automatisch worden gedetecteerd.
SDS1.5.2	Als we een 'Test Kitchen instrument' implementeren met 100% sampling en een verzoekidentificatie, kunnen we alle verzoeken vastleggen, ongeacht of ze client-side events hebben gestuurd of niet, en deze analyseren op botgedrag.
SDS1.5.3	Als we het basissignaal aan de clientzijde analyseren en in onze heuristieken opnemen, zullen we extra botpatronen in het dataplatform detecteren.
SDS2.2.4	Als Product Safety and Integrity GrowthBook en FerretDB beoordeelt, kunnen we materiële risico's identificeren en vervolgens beperken en/of aanpakken voordat de productie wordt uitgerold.
SDS2.2.5	Als we "Test Kitchen JS" en "PHP-SDK's" bijwerken met methoden om experimentele blootstelling te registreren, hoeven we niet alle gebeurtenissen als zo te behandelen, wat de prestaties van experimenttoewijzingsqueries in GrowthBook zal verbeteren en nauwkeurigere experimentresultaten zal opleveren.
SDS2.4.2	Als we de "traffic enrolment" veilig uitbreiden via gemonitorde stresstests, zullen we de statistische kracht voor Reader-teamexperimenten vergroten, de tijdslijnen van experimenten verkorten en het vertrouwen in het besluit verbeteren.

Future Audience (FA) Hypothesen [ FA Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 3 tekst	Details en discussie
FA1.1.1	Als we een centrale hub bouwen voor nieuwe Wikipedia-ervaringen op itch.io, kunnen we een publiek van >50 geïnteresseerde niet-Wikipedianen opbouwen die ons feedback geven, wat ons helpt te leren wat in games werkt en wat niet.
FA1.1.2	Als we drie verschillende app-gebaseerde contentontdekkingsfuncties maken en testen als korte experimenten, kunnen we aanbevelingen delen met het team Apps over hoe we effectief kunnen communiceren met en behouden van een nieuwe generatie app-gebruikers
FA1.1.3	Als we 4 TikTok-filters maken en deze op ons TikTok-account publiceren, kunnen we leren hoe goed we het maken van Wikipedia-content buiten het platform kunnen stimuleren.
FA1.1.6	Als we drie verschillende mogelijke previews maken voor Wikipedia-links die op Discord worden gedeeld, kunnen we intern afstemmen op onze meet- en uitvoeringsstrategie en samenwerken met het team ProdEng van Discord.
FA2.2.1	Als we investeren in community management op short-video platforms, zullen we tegen het einde van Kwartaal 2 (december 2025) een QoQ-stijging van 30% zien in het percentage views van nieuwe kijkers op TikTok — en op alle SFV-platforms verdienen we in totaal 50.000 engagements (likes en reacties op reacties) op merkreacties die op externe content worden achtergelaten, wat ons helpt de zichtbaarheid te vergroten en de betrokkenheid te stimuleren bij doelgroepen die we nu niet bereiken.
FA2.2.2	Als we een interne strategie van het programma Wikipedia Creator Partnerships ontwikkelen en goedkeuring krijgen voor en externe shareables (inclusief een overzicht van onze waarde voor makers, partnerschapscriteria, contracteringsproces en hoe creator-content zal verschijnen over eigen en creator-kanalen), kunnen we een robuuste makersstrategie opzetten die ons helpt nieuwe doelgroepen te bereiken via sociale media met onze kenniscontent.

Product- en technische ondersteuning (PES) Hypothesen [ PES Belangrijkste Resultaten ] Overleg
Hypothese korte naam	Kwartaal 3 tekst	Details en discussie
PES1.3.5	Als we een gemeenschapsconfiguratie maken voor "Easter Eggs" en Reader Experience gebruiken voor code-review, kunnen we op 15 februari beginnen en de impact van het project volgen.
PES1.3.6	Als we op maat gemaakte social media-berichten maken voor 25 jaar Wikipedia, kunnen we vergelijkbaar succes behalen met sociale impressies als de bestaande sjablonen van Commons, en bewijzen dat we Commons kunnen ondersteunen door hun capaciteit te vergroten. Benchmarking zal plaatsvinden op basis van berichten van Truth Collective over hetzelfde project.
PES1.4.1	Als we met 4-5 teams afspreken die niet voornamelijk Codex gebruiken (inclusief, maar niet beperkt tot, teams die voornamelijk OOUI gebruiken), kunnen we blokkers documenteren aan die teams die Codex adopteren voor huidige en toekomstige projecten.
PES1.4.2	Als we Codex PHP makkelijker maken om te gebruiken en het stabiel genoeg is om een 1.0-release te maken, zullen teams Codex PHP aannemen voor server-genereerde UI's. Dit zal het gebruik van Codex PHP verhogen van 3 projecten naar 5.
PES1.5.1	Als we Sloth upgraden van een prototype naar een vervanging van Pyrra, kunnen we door het onboarding van bestaande diensten samenkomen op een uniforme set SLO-dashboards, onze meldingen verfijnen en de SLO-onboarding-ervaring stroomlijnen.
PES1.5.2	Als we SLI-metricen blijven inboarden voor Wikifuncties en MediaWiki Content History, en de metricen voor WikiData Query Service en EditCheck controleren, zullen we problemen oplossen met zowel dashboardrapportages als de betrokkenheid van service-owner bij opvallende maar niet opgeloste SLO-rapporten.

Q4

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

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

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

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

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

Samen plannen

Januari 2025 update.

Het Jaarplan is de beschrijving van wat de Wikimedia Foundation hoopt te bereiken in het komende jaar. Wij werken hard om het plan participatief, ambitieus en haalbaar te maken. Bij het vormgeven van het plan vragen we elk jaar aan de mensen die bijdragen om hun vergezichten, verlangens en specifieke verzoeken met ons te delen. Manieren waarop wij input zoeken zijn onder meer de gesprekken met de gemeenschap binnen het productteam, via de wensenlijst van de gemeenschap, via andere gesprekken met de gemeenschap, zoals de reeks van gesprekken op Commons, bij conferenties en op wikipagina's zoals deze.

Voor ons volgende jaarplan, dat zal lopen van juli 2025 tot juni 2026, zijn we aan het nadenken hoe we het beste tegemoet kunnen komen aan een visie voor meerdere generaties, rekening houdend met de snelle veranderingen in de wereld en op het internet en hoe dat invloed heeft op onze missie, die gericht is op vrije kennis.

Zoals ik vorig jaar zei, moeten we ons concentreren op wat ons onderscheidt: ons vermogen om betrouwbare inhoud te leveren, zelfs als desinformatie en misinformatie zich over het internet verspreiden. En ook als desinformatie en misinformatie zich verspreiden over de platforms die elkaar beconcurreren om de aandacht van de jongere generaties. Daarbij hoort dat we ervoor zorgen dat we onze missie bereiken - om de som van alle menselijke kennis te verzamelen en openbaar te maken - door ontbrekende informatie toe te voegen, terwijl dat ontbreken kan worden veroorzaakt door ongelijkheid, discriminatie en vooroordelen. Onze inhoud moet ook van vitaal belang blijven bij een veranderend internet dat wordt aangedreven door kunstmatige intelligentie en andere verrijkte ervaringen. En tenslotte moeten we manieren vinden om onze beweging duurzaam te financieren door een gedeelde strategie in te richten voor onze producten en fondsenwerving, zodat we ons werk op lange termijn kunnen blijven doen.

Om het komende jaar keuzes en afwegingen te kunnen maken voor de focus van onze inspanningen, hebben we enkele vragen en gedachten geformuleerd over hoe we onze eindige hulpmiddelen kunnen inzetten om een zo groot mogelijk effect te bereiken.

Als u specifiek geïnteresseerd bent welke functies en diensten de afdeling Product and Technology zal gaan bouwen, gebaseerd op de hier gestelde prioriteiten, dan volgt in maart dit jaar de mogelijkheid om commentaar te leveren op de specifieke doelstellingen en de belangrijkste resultaten. (Hier staan de doelstellingen en hier de de belangrijkste resultaten voor het huidige jaarplan, dit als referentie.)

Als u wilt nadenken over de uitdagingen en kansen in onze technische omgeving en over de richting die we in het volgende jaarplan moeten inslaan, kijk dan samen met ons naar de onderstaande vragen.

We verzamelen voortdurend en op veel manieren informatie over deze vragen -- via gesprekken met de gemeenschap, data die we verzamelen, via interviews die we houden, etc. Dit is niet de eerste keer dat we vragen stellen en dat we over deze zaken willen leren - we hebben ook al veel van deze kwesties eerder onderzoek gedaan! Wij willen het nu nogmaals vragen en blijven leren, want deze vragen zijn in dit stadium van de planning voor ons het belangrijkste.

Vragen:

Metingen en gegevens
- Op welke manieren kunnen metingen en gegevens uw werk als bewerker beter ondersteunen? Welke data over het bewerken, lezen en organiseren kunnen u helpen bij uw keuze hoe u uw tijd gaat besteden, of wanneer er aandacht nodig is? Het kunnen gegevens zijn over uw eigen activiteiten of de activiteiten van anderen.
Bewerken
- Wanneer is het bewerken het meest bevredigend en het leukst voor u? Wanneer is het frustrerend en moeilijk?
- We willen dat medewerkers meer feedback en erkenning krijgen voor hun werk, zodat het niet voelt alsof niemand opmerkt hoe hard ze aan de wiki's werken. Wat voor feedback en erkenning motiveert u? Wat stimuleert u om te blijven bewerken?
- Omdat de wiki's zo groot zijn, kan het moeilijk zijn voor bewerkers om te beslissen welk wikiwerk het belangrijkste voor hen is en waaraan zij dagelijks tijd willen besteden. Welke informatie en welke hulpmiddelen kunnen u helpen kiezen hoe u uw tijd besteedt? Zou het nuttig zijn om een centrale, persoonlijke plek te hebben waar u nieuwe mogelijkheden kan vinden, waar uw lopende taken beheerd worden en waarmee u inzicht krijgt in uw impact?
- We willen de ervaring van samenwerking op de wiki's verbeteren, zodat het gemakkelijker is voor bijdragers om elkaar te vinden en om samen aan projecten te werken, of het nu is via backlog drives, edit-a-thons, WikiProjects, of zelfs twee bewerkers die samenwerken. Hoe denkt u dat we meer bijdragers kunnen helpen om elkaar te vinden, om contact te maken en samen te werken?
Lezen / leren
- De laadtijd van wiki's is sneller of langzamer afhankelijk van waar mensen in de wereld wonen. Zijn er delen van de wereld waarvan u denkt dat betere prestaties het meest nodig zijn?
- Hoe kunnen we nieuwe generaties lezers helpen de inhoud van Wikipedia interessant en boeiend te vinden? We hebben in het verleden ideeën besproken rond interactieve inhoud en video, en in het lopende jaar hebben we ons gericht op grafieken en op experimenteren met nieuwe manieren om bestaande Wikipedia-inhoud naar boven te halen. Hoe kunnen we op deze weg doorgaan om onze bestaande inhoud op nieuwe manieren te gebruiken? Manieren die uniek zijn voor Wikimedia?
Moderatoren
- Wat zou er aan Wikipedia moeten veranderen om ervoor te zorgen dat meer mensen betrokken willen raken bij geavanceerde vrijwilligersrollen, om zich in te zetten voor het controleren en markeren van nieuwe bijdragen, of om zich in te zetten als moderator?
- Welke informatie of context over bewerkingen of gebruikers kan u helpen om sneller of makkelijker beslissingen te nemen over nog niet gecontroleerde bewerkingen of over andere besluiten die een moderator moet nemen?
Externe trends
- Wat zijn de belangrijkste veranderingen die u ziet in de wereld buiten Wikimedia? Dit kunnen trends zijn op het gebied van technologie, onderwijs of hoe mensen leren.
- Aan welke andere online gemeenschappen neemt u deel buiten de Wikimedia-beweging? Wat kunnen wij leren van de hulpmiddelen en processen op andere platforms met gemeenschappen?
- Hoe gebruikt u AI-hulpmiddelen binnen en buiten uw Wikimedia-werk? Waar vind u AI nuttig voor?
Commons
- Welke beslissingen kunnen we samen met de gemeenschap op Commons nemen om er een duurzaam project van te maken dat het creëren van encyclopedische kennis ondersteunt?
Wikidata
- Hoe zou u graag willen dat Wikidata zich in de toekomst ontwikkelt? Hoe kan het het meest nuttig zijn om te bouwen aan betrouwbare encyclopedische inhoud?

Overleg

–– Selena Deckelmann