Jump to content

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

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 100% complete.
Other languages:
Wikimedia Foundation Jaarplan 2025–2026

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 "Belangrijke resultaten (KR)" vormen een meetbare manier om het succes van hun doelstellingen te volgen.
  • De onderliggende "Hypothesen" voor elk belangrijke 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.
  • wishlist item 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.
      • item wensenlijst Belangrijk 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.
      • item wensenlijst Belangrijk 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
      • item wensenlijst Belangrijk 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
      • item wensenlijst Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk resultaat WE1.7: Primair: Behaal een ≥ 10% relatieve stijging van het bewerkingsvoltooiingspercentage van gekwalificeerde nieuwkomers en Junior Contributor mobiele bewerkingssessies, gebaseerd op gecontroleerde A/B-test(s).'[i]
        [i]         Gekwalificeerde bewerkingssessie = bewerkingssessie waarin een ingelogde gebruiker met ≤100 cumulatieve bewerkingen minstens ≥2 seconden in VE's "klaar-toestand" doorbracht.
        Vangrail: Geen betekenisvolle dalingen in constructieve bewerkingssnelheid onder mobiele bewerkingen gepubliceerd door nieuwkomers en Junior Contributors, gebaseerd op gecontroleerde A/B-tests.
        • 150.000–200.000 keer per dag tikt iemand op "Bewerken" op mobiel web, wacht tot de bewerkingsinterface laadt, kijkt minstens 2 seconden rond en vertrekt dan zonder iets te doen. Geen toetsaanslagen, geen tikken op de werkbalk... Niets.
        • WE 1.7 zal deze "nieuwsgierige klikken" beantwoorden met duidelijke, overtuigende en gestructureerde bewerkingssuggesties die ervoor zorgen dat de mensen die ze maken de voldoening, vreugde en betekenis ervaren die kunnen komen met het iets beter maken van Wikipedia, de bron die ze hebben gekozen om te bezoeken.
      • Belangrijk resultaat WE1.8: Streef tegen het einde van Kwartaal 4 naar een totale relatieve stijging van 5 procent in het voltooiingspercentage van het aanmaken van mobiele webaccounts, waarbij succes gemeten wordt door minstens drie gecontroleerde experimenten die elk een minimale relatieve verbetering van 2 procent opleveren.
        • Het aanmaken van een account is de toegangspoort tot betekenisvolle deelname aan Wikimedia-projecten, maar het blijft een verouderde ervaring voor nieuwkomers. De huidige stromen leggen een hoge cognitieve belasting met zich mee, presenteren beperkte of verwarrende waardeproposities en vertrouwen op oude interfacepatronen die niet langer de hedendaagse verwachtingen weerspiegelen. Daardoor trekken veel potentiële bijdragers zich terug voordat ze de kans krijgen om deel uit te maken van de gemeenschap.
        • Dit initiatief heeft tot doel de aanmaak van accounts te moderniseren, de wrijving voor goede trouw bijdragers te verminderen en doordachte experimenten in te voeren die de registratie aanmoedigen op momenten waar de motivatie vanzelfsprekend het hoogste is. Het werk legt essentiële grondslagen voor langetermijnverbeteringen in de activering, behoud en diversiteit van de redacteur.
        • We schatten dat een relatieve toename van 5 procent in de aanmaak van accounts op Wikipedia op mobiel zou leiden tot een meerdere duizend nieuwe accounts per maand en een paar honderd meer nieuwe redacteuren per maand, gebaseerd op de huidige registratievolumes.
      • Belangrijk resultaat WE1.9: Aan het einde van Kwartaal 4 kunt u één tastbare productaanbeveling geven voor doelstelling, ontwikkeling van nieuwkomers en erkenning, zodat junior medewerkers betrokken kunnen blijven en zich kunnen ontwikkelen.
        • Achtergrond: we weten dat het behoud van junior bijdragers vrij laag is ondanks recente groei (gegevens). Wij geloven dat een fundamentele uitdaging om deze lage retentie van deze bijdragers te overwinnen, is het ontwikkelen van onze platforms om redacteurs te helpen om sterk gemotiveerd te blijven om te bijdragen - dat wil zeggen niet alleen de barrière om te blijven bijdragen te verminderen, maar ook om de ervaring lonend te maken. Dit is echter niet triviaal - bijvoorbeeld, editors komen met verschillende motivaties in het project; interventies zoals spel-elementen die de aanvankelijke betrokkenheid kunnen stimuleren, kunnen niet helpen bij het behoud op lange termijn.
        • Waarom nu: veel van de focus van de Contributors Product teams tot nu toe is gericht op het verminderen van technische barrières voor activatie/betrokkenheid, maar er zijn een reeks aankomende projecten die meer gericht zijn op behoud – bijvoorbeeld, Progressiesysteem en Erkenning. Het onderzoek onder WE1.9 is bedoeld om het implementatiewerk voor te lopen en duidelijke aanbevelingen te geven aan productteams in deze sector over hoe zij hun platforms kunnen ontwerpen om de diverse motivaties van redacteuren beter te ondersteunen en de langetermijnbehoud te vergroten. Dit verwijst terug naar belangrijke vragen met betrekking tot nieuwkomers en junior redacteuren in de Bijdragerstrategie.
        • Voorgestelde scoringsmethodologie: voor elk geïdentificeerd project (doelstelling; voortgangssysteem; erkenning) zullen we ten minste één concrete aanbeveling doen met implicaties voor het ontwerp. Onderzoek is experimenteel werk en de projecten kunnen zich gedurende WE1.9 ontwikkelen, maar we zullen nauw contact houden met de relevante productteams. In de praktijk kunnen deze aanbevelingen inzichten bevatten over wat het meest demotiveert voor nieuwkomers (dingen om te vermijden), wat het meest bevredigend is (dingen om te benadrukken), veelvoorkomende "tripping points" in reizen die aangepakt moeten worden, strategieën om deze uitdagingen te overwinnen, enzovoort. De aanbeveling zou de PM moeten helpen om duidelijke volgende stappen voor ontwerp en/of engineering te identificeren.
      • Belangrijk resultaat WE1.10: Aan het einde van Kwartaal 4 implementeren van een nieuwe geleide artikelcreatie-flow waarbij de overlevingskans van artikelen gemaakt door junior-redacteuren op mobiel 5% hoger is op elke ingezette wiki dan artikelen die op andere manieren zijn gemaakt, terwijl het aantal overgebleven artikelen gelijk of hoger blijft, gemeten door een gecontroleerd experiment.
        • Het initiatief voor artikelrichtlijnen heeft als doel nieuwe benaderingen te ontwikkelen die redacteuren ondersteunen bij het creëren van eerste, goed gestructureerde bijdragen aan Wikipedia die aansluiten bij het beleid van de gemeenschap en de kwaliteit van de inhoud. Als eerste interventie werd er afgelopen kwartaal een nieuwe workflow voor het maken van artikelen ingevoerd, gebaseerd op door de community bewerkbare outlines die de richtlijnen voor specifieke soorten artikelen bevatten. In Q4 is het doel om een A/B-testexperiment uit te voeren om de impact op een set pilot-wiki's te meten om de impact te evalueren. Omdat de richtlijnen afhankelijk zijn van de gemeenschap, vereisen de experimentvoorbereidingen samenwerking met de gemeenschappen van de pilot-wiki's om het systeem aan te passen aan hun behoeften.

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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • item wensenlijst Belangrijk 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
      • Belangrijk 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.
      • Belangrijk 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.)
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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 4.
        • 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.
      • Belangrijk 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.
      • Belangrijk 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).
      • Belangrijk 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
  • Belangrijk 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.
  • Belangrijk 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.
  • Belangrijk 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.
  • Belangrijk 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.
  • Belangrijk 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.
  • Belangrijk 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.
  • Belangrijk resultaat WE4.7: Onze botdetectieproef publiekelijk afronden tegen het einde van Kwartaal 4.
    • Deze KR is een gerichte, kwart van de inspanning om de resultaten van deze proef te evalueren, binnen WMF te beslissen of dit systeem behouden en uitgebreid moet worden over onze wiki's en om de resultaten van de proef en onze toekomst openbaar te maken.
  • Belangrijk resultaat WE4.8: Vereenvoudig het patrouilleren van tijdelijke accounts door het sneller te maken om misbruik te identificeren en aan te pakken, tegen het einde van Kwartaal 4.
    • Het doel van tijdelijke accounts is om de deelname van niet-geregistreerde redacteuren te goeder trouw veilig te blijven ondersteunen. Sommige anti-vandalisme-workflows werden echter ingewikkelder door het vrijgeven van tijdelijke accounts. Om ervoor te zorgen dat tijdelijke accountvandalisme duurzaam kan worden beheerd, maken we het voor patrouilleurs gemakkelijker en sneller om tijdelijke accountactiviteiten, zowel te goeder als in kwade trouw, te begrijpen en erop te reageren. We zullen clusters van gerelateerde tijdelijke accounts aan patrouilleurs aan het licht brengen, terwijl we ook andere interventies onderzoeken die vroege identificatie en snelle respons kunnen verbeteren.
  • Belangrijk resultaat WE4.9: Geef vrijwillige onderzoekers de kracht om meer onechte activiteiten op wiki's waar ze actief gemarkeerde accounts beoordelen, te ontmoedigen en te blokkeren, gemeten aan een toename van 20% in het percentage verzachtende acties op die accounts, tegen het einde van Kwartaal Q4.
    • Voor Kwartaal 3 en 4, in het besef van het strategische potentieel dat "Suggested Investigations" heeft aangetoond, zullen we investeren in het inzetten van nieuwe signalen onafhankelijk van bot-detectie, en zullen we tijd vrijmaken om prioriteit te geven aan een verscheidenheid aan efficiëntie en kwaliteit van leven functies die zijn aangevraagd door SI-gebruikers sinds de oorspronkelijke MVP release.
  • Belangrijk resultaat WE4.10: Tegen het einde van Kwartaal 4 verhogen we de dekking van hCaptcha-botdetectie van 18% naar 100% van accountaanmaak en van 18% naar 90% van de bewerkingen met een hoger risico.
    • In Kwartaal 3 hebben we onze hCaptcha-test afgerond, waarbij we hCaptca tijdens de aanmaak van een account hebben ingeschakeld en later uitgebreid hebben om nieuwe gebruikers op de desktop wikitext-editor te omvatten, op acht grote Wikipedia's, waaronder de Engelse Wikipedia. Op basis van de resultaten van die test, breiden we hCaptcha uit naar meer bewerkingsinterfaces en op meer wiki's. Onze belangrijkste prioriteit zal zijn om te breiden wat we nu hebben naar alle wiki's, maar we zullen ons ook concentreren op nieuwe wegen naar (discussies-hulpmiddelen, uploads), evenals categorieën gebruikers wiens acties worden beschermd door hCaptcha.
  • Belangrijk resultaat WE4.11: Aan het einde van Kwartaal 4 een IRS-proef op enwiki voltooid met een geleidelijke implementatie, waarbij minstens 50% van de ingelogde gebruikers wordt bereikt en 5 nieuwe rapportage-metrics worden bereikt.
    • We testen een "incident reporting system" (IRS) op de Engelse Wikipedia die is ontworpen om minder ervaren gemeenschapsleden te helpen gemakkelijker potentieel slecht gedrag te melden aan de door de gemeenschap beheerde plaats die het best kan omgaan met het. Voor zeldzamer en ernstigere gevallen biedt het ook een formulier om dreigende schadebeveiliging rechtstreeks aan het WMF-team Trust and Safety te melden.
    • Deze test zal zich vooral richten op het kalibreren van het eerste gebruikskader: het helpen van redacteurs om potentieel slecht gedrag te melden, zonder het systeem te overbelasten.
    • Tijdens de test zullen we ons richten op het monitoren van het volume van nieuwe rapporten, het controleren of de rapporten correct worden geleid en het identificeren van eventuele onmiddellijke problemen. We zullen nauw samenwerken met alle communityleden om bugs te repareren als ze zich voordoen en om het proces anders te stroomlijnen. We onderzoeken bijvoorbeeld manieren om de gebruikerservaring te vergroten en mensen te helpen hun rapporten rechtstreeks in te dienen, die we ook kunnen gebruiken en meten tijdens de proefperiode.
  • Belangrijk resultaat WE4.12: Tegen het einde van Kwartaal 4 zullen we een detectie-manier hebben gedefinieerd voor classifiers die automatisch door het beleid verboden inhoud van het Engelse Wikipedia detecteren, en de impact geëvalueerd van ten minste één classifier die ten minste één type verboden inhoud detecteert, gevalideerd aan de hand van datasets van de gemeenschap, op het potentieel om de werklast van vrijwilligers te verminderen.
    • We willen vrijwilligers en UWER's ondersteunen door het werk te verminderen dat nodig is om schadelijke inhoud uit de projecten te verwijderen, zodat vrijwilligers moeilijker zaken kunnen gaan behandelen.
    • In dit kwartaal willen we ervaring opdoen met het definiëren van herhaalbare processen voor het bouwen van detectie-manieren voor verschillende soorten inhoud en de eerste stappen ondernemen om deze manieren veilig te evalueren bij grote projecten (A/B-testen, log-only-mode-implementaties, enz.). We gaan beginnen met een focus op inhoud die waarschijnlijk moet worden onderdrukt, zoals dreigingen of het onthullen van persoonlijke informatie.
    • We zijn van plan deze initiatieven in het Boekjaar 26-27 uit te breiden als onderdeel van een herziening van anti-misbruik-hulpmiddelen die UWER's en vrijwilligers ondersteunt bij het verkleinen van de tijd voor het verminderen van misbruik van ons vertrouwen bij een zachtere aanpak.

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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk resultaat WE6.5: Bepaal tegen het einde van Kwartaal 4 de haalbaarheid en volgende stappen voor schaalbare samenwerking tussen wiki-codes en ondersteuning voor ingelogde lezers.
        • Een van de centrale kenmerken van wiki's is het creëren van gezamenlijke content. In de context van de Wikimedia-beweging zijn de samenwerkingsbehoeften zeer specifiek voor de evolutie van de projecten en de uitdagingen die ontstaan op de schaal waarin sommige grotere projecten opereren.
        • Code-samenwerking (cross-wiki of on-wiki) is een legitieme behoefte en moet worden ondersteund. Dit is minder een enkel probleem en meer een probleemruimte die meerdere overlappende problemen rondom code omvat (voornamelijk sjablonen en modules), en het oplossen van problemen in deze ruimte vereist gedeeld begrip over de belangrijkste prioriteiten.
        • Met een experimentele denkwijze verkennen we een slankere aanpak om gedeelde codebibliotheken te testen die samenwerking tussen wiki's kan verbeteren in een kleine en gecontroleerde omgeving. Dit betekent dat we een fase van technische haalbaarheid en scope verkenning zullen doorlopen om de experimentele uitrol in kleine iteraties te benaderen en inzichten te verzamelen die ons kunnen helpen beslissen hoe we het eerder genoemde probleem willen aanpakken. Onze intentie is om onze lessen en vooruitgang te tonen tijdens de Wikimedia Hackathon 2026.
        • Evenzo, als we de ervaring van ingelogde gebruikers willen verbeteren, moeten we weten waar de prestatieverbeteringen liggen, welke productwerk eisen zal stellen en hoe een duurzame aanpak eruit zal zien voor dit werk volgend boekjaar. Onderzoek op dit gebied zal ons voorbereiden om snel met platformwerk te beginnen volgend boekjaar.
      • Belangrijk resultaat WE6.6: Tegen het einde van Kwartaal 4 kunnen ontwikkelaars de resultaten van MediaWiki Core CI in minder dan 10 minuten ontvangen.
        • Onze huidige mediane CI-cyclusbasis ligt boven de 24 minuten, terwijl een DevEx-industriestandaard voor hoog presterende teams 10 minuten of minder is.
        • Om deze kloof te overbruggen, willen we de CI-werkstromen optimaliseren, de belangrijkste knelpunten aanpakken zoals onze browsertests door te optimaliseren hoe we ze uitvoeren, het onderliggende testraamwerk en de configuratie ervan.
        • Door de gemiddelde IC-wachttijden van 24 tot 10 minuten te verlagen, zorgen we voor de snelle feedback-lus die nodig is om problemen snel te testen en op te lossen, waardoor de iteratie snelheid aanzienlijk wordt versneld. Bovendien versnelt het verbeteren van deze meting de tijd om samen te sluiten, waardoor de tijd tussen het gereed zijn van een verandering en het beschikbaar zijn voor implementatie verkort wordt, wat direct bijdraagt aan de top-level OW5-meting om het "gemakkelijker en sneller te maken om producten te bouwen".
      • Belangrijk resultaat WE6.7: Tegen het einde van Kwartaal 1 van het boekjaar 2026-27 kunnen ontwikkelaars MediaWiki-code binnen 1 dag na de samenvoeging in productie testen.
        • Nu kunnen ontwikkelaars hun code gemiddeld ongeveer 4 dagen na het samenvoegen, op productie uitvoeren. Door deze tijd te verkleinen, kunnen ontwikkelaars eerder testen en door testomgevingen te verbeteren, zullen ze meer vertrouwen hebben dat hun tests minder bugs tot productie zullen leiden.

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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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
      • Belangrijk resultaat SDS1.5: Tegen het einde van het 4e kwartaal van boekjaar 25-26 zal de detectie van analytics-bots 2 signalen bevatten die zijn gekalibreerd tegen 1 vertrouwde classificatie.
        • In de Kwartalen 1 en 2 pakte SDS1.3 het grote gat in incidentdetectietijd aan en analyseerde extra signalen voor botdetectie. We hebben geleerd dat:
          • Moderne en haalbare signalen een aantal kanttekeningen en onzekerheden met zich meebrengen die in onze metingen moeten worden uitgedrukt.
          • De kwaliteit van ons model te evalueren en een robuuste analyse van signalen te doen om toekomstige iteraties mogelijk te maken, vereist dat er gelabelde gegevens worden gebruikt, die volgens definitie worden vertrouwd en bij voorkeur afkomstig zijn van onafhankelijke systemen (voorheen "grondwaarheden" genoemd).
          • Wij zullen kennis en kalibratie van derden die zich in dit domein hebben gespecialiseerd nodig hebben om onze huidige toestand te kunnen kwantificeren en toekomstige verbeteringen te kunnen prioriteren.
        • In Kwartalen 3 en 4 volgen we dat met drie punten:
          • Onze metingen van paginaweergave verbreden om een numerieke betrouwbaarheidscore op te nemen naast de bestaande labels, berekend uit minstens 2 nieuwe signalen, waardoor analisten de nuances van die signalen kunnen kwantificeren en overbrengen.
          • Betrouwbare labels beheren, bij voorkeur afkomstig van een derde die zich speciaal in dit domein heeft gespecialiseerd, en het gebruiken om onze huidige prestaties te evalueren en de nieuwe signalen beter te begrijpen.
          • Een signaal van de klant kant operationeel maken, dat de meest veelbelovende intern ontwikkelde detectiemethode blijft.
      • Belangrijk resultaat SDS1.6: Geef regelmatig een Movement Insights-rapport, met consistente dekking over lezers, bijdragers en thematische inhoudsgebieden. We weten dat we succesvol zijn als we het volgende hebben vastgesteld aan het einde van Kwartaal 4:
        • Een consistent voordrachtsritme
        • Meest waardevolle content voor onze stakeholders
        • Mogelijkheden voor toekomstige automatisering
        • Tegenwoordig zijn kritieke signalen over de gezondheid van de Wikimedia-beweging gefragmenteerd over systemen en teams. Lezerstrends, bijdragergezondheid, merkperceptie, SEO/AEO en concurrentie-intelligentie worden onafhankelijk gevolgd, zonder een consistent proces of systemen om ze samen te interpreteren. We hebben bestaande maandelijkse meetmethoden, maar die pakken niet de reikwijdte en focus aan die uitvoerende besluitvormers nodig hebben. De Movement Trends Brief is een beknopte, terugkerende inlichtingenbrief die leiderschap en productteams een gedeeld begrip geeft van hoe de Wikimedia-beweging week na week evolueert. In plaats van alles te beschrijven wat er is gebeurd, beantwoordt deze communicatie consequent de volgende vragen:
          • Wat is er de afgelopen week / 2 weken significant veranderd?
          • Hebben we iets nieuws geleerd over bestaande trends die we bekijken?
          • Waarom is het nu belangrijk?
          • Wat vereist aandacht of actie?
        • De brief is ontworpen om het situationeel bewustzijn te ondersteunen en een forum te bieden om een diepere analyse te presenteren. Het maakt vroege signalen bekend, verbindt de daarmee verband houdende trends met verschillende gegevensbronnen en creëert een toegangspunt voor het informeren van de besluitvorming.

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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk resultaat SDS2.3: Aan het einde van Kwartaal 4 zijn alle nieuwe Test Kitchen-experimenten geconfigureerd in GrowthBook.
        • Nadat het WMF-personeel GrowthBook had laten gebruiken voor het analyseren van experimentresultaten, hield het team Experiment Platform een ontwerpsprint om de opties voor experimentconfiguratie te beoordelen. De beslissing was om GrowthBook als bron van waarheid te gebruiken voor experimentconfiguratie, maar Test Kitchen UI (TKUI) als bron van waarheid voor instrumentconfiguratie te behouden. Door GrowthBook de bron van waarheid te maken voor experimentconfiguratie, streven we ernaar om:
          • Vermindering van de coördinatie bij het uitvoeren van een experiment
          • Meer frequente en herhaalbare experimenten mogelijk maken
          • De afbakening maken tussen instrumenten en experimenten
          • Naar een mentaal model gaan dat zich richt op metingen in plaats van instrumenten
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk 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.
      • Belangrijk resultaat PES1.7: Aan het einde van Kwartaal 4, krijgt 85% van de wensen binnen 10 werkdagen een reactie en er wordt maandelijks een update geplaatst over het werk dat we hebben toegezegd te implementeren.
        • Na de vernieuwde triage van de Wenslijst in de eerste helft van het jaar willen we consequent laten zien dat vrijwilligers reacties krijgen op hun wensen plus een maandelijkse update met wat er komt, wat in behandeling is of geblokkeerd is, en wat wordt gescoped. We beoordelen de maatstaf door de responstijd te meten op een rollend gemiddelde over een maand, en streven ernaar die minstens een maand vol te houden.

Hypothesen

Kwartaal 1

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

Wiki Experiences (WE) Hypothesen

[ WE Belangrijke 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 boekjaar 25/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 Belangrijke 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 Belangrijke 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 Belangrijke 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 Belangrijke 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.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. phab:T406921
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 Belangrijke 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 Belangrijke 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 Belangrijke 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 Belangrijke 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 Belangrijke 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 Belangrijke 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 Belangrijke 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.

Kwartaal 4

Het vierde kwartaal van het WMF-jaarplan beslaat april-juni 2026.

Wiki Experiences (WE) Hypothesen

[ WE Belangrijke Resultaten ]

Overleg

Hypothese korte naam Kwartaal 4 tekst Details en discussie
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.5.1a Als we nieuwe metingen toevoegen aan het dashboard Bijdragers met DBT, kunnen we productteams die bijdragen meer inzicht krijgen in de bewerkingstrends.
WE1.5.5 Als we updates van DBT-modellen met Airflow op een vast schema automatiseren, zullen we Movement Insights toestaan analyses en rapporten over die modellen te maken met behulp van actuele informatie.
WE1.5.6 Als we workflows documenteren en standaard outputlocaties en toegangscontroles per team voor dbt-modellen vaststellen, zullen we het gebruik van dbt in Movement Insights en andere teams op schaal kunnen laten doen.
WE1.5.7 Als we het MAM-dashboard uitbreiden zoals gespecificeerd, hebben we een completer beeld van de gezondheid van de moderatorpijplijn die beslissingen in de Contributor-strategie kan informeren.
WE1.6.1 Als we aangepaste volglijstlabels introduceren, verwachten we dat 5% van de gebruikers deze labels gebruikt heeft met meer dan 100 pagina's op hun volglijst in de eerste maand.
WE1.7.2 Door een ontwerpprototype van de in-app webview bewerkingsflow te testen met nieuwkomers op mobiele apps, zullen we de meest risicovolle wrijvingspunten identificeren die kunnen leiden tot opgeven vóór publicatie – specifiek rond contextverschuiving, redacteursbegrip en bewerkingsattributie – zodat we kunnen prioriteren wat opgelost moet worden voordat deze aanpak nieuwe redacteuren op grote schaal succesvol kan inwerken.
WE1.7.4 Als we 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.7.5 Als we de ongestructureerde taak Copyedit vervangen door de gestructureerde taak Revise Tone in een gecontroleerd experiment, zal de taakvoltooiingsgraad van bewerkingen door junior editors hoger zijn dan de voltooiingsgraad voor bewerkingen die via de eerdere taak zijn gemaakt.
WE1.7.6 Als we twee gestructureerde workflows testen via ontwerpprototypes die bijdragemogelijkheden afstemmen op wat lezers gemotiveerd vinden om te leren, en bijdragen presenteren als manieren om nieuwsgierigheid te volgen of kennis te delen die ze al bezitten, dan helpt concepttesten ons om benaderingen te identificeren die lezers inspireren zichzelf als bijdragers voor te stellen.
WE1.7.7 Als we een exit-enquête presenteren aan gebruikers met ≤100 cumulatieve bewerkingen die mobiele bewerkingssessies opgeven na ≥2 seconden in de mobiele visuele of broneditor, zullen we patronen ontdekken in de redenen achter dit gedrag en kunnen we beslissen welke interventies we prioriteit geven om het voltooiingspercentage van mobiele webbewerkingen te verhogen.
WE1.7.8 Als we junior bijdragers die de mobiele VisualEditor gebruiken direct uitvoerbare bewerkingssuggesties geven, zal het aandeel bewerkingssessies dat resulteert in het publiceren van een constructieve bewerking met ≥10% toenemen.
WE1.7.9 Als we een voorstel op de wiki publiceren om VisualEditor standaard in te schakelen voor nieuwkomers op mobiel web op en.wiki, zullen we de stappen definiëren die nodig zijn om dit te realiseren.
WE1.8.2 Als we de uitgelogde bewerkingswaarschuwing verbeteren, zal het aanmaakpercentage van accounts onder nieuwkomers op mobiel die de waarschuwing krijgen met minstens 2% stijgen ten opzichte van de controlegroep.
WE1.8.3 Als we het accountaanmaakformulier verbeteren, zal het registratiepercentage onder mobiele gebruikers die op het formulier terechtkomen met minstens 2% stijgen ten opzichte van de controlegroep.
WE1.8.4 Als we een gebruikersaccountknop toevoegen aan de kop op mobiel web, zal het aantal nieuwe accounts dat op mobiel wordt aangemaakt met minstens 2% toenemen ten opzichte van de controlegroep.
WE1.8.5 Als we leeslijsten tonen aan uitgelogde lezers op mobiel web, zal het registratiepercentage met minstens 2% toenemen ten opzichte van de controlegroep.
WE1.9.2 Als we kernvragen over factoren die de motivatie van redacteuren [i] beïnvloeden in de 2026 enquête Community Insights introduceren, kunnen we aan het einde van Kwartaal 4 ≥5 onderzoeksinzichten bieden die onze Contributors-strategie kunnen informeren, met focus op de progressie en erkenning van redacteuren.

[i] Gedefinieerd door de bril van competentie (vermogen om hulpmiddelen en middelen te gebruiken), autonomie (vermogen om het platform te navigeren en weloverwogen beslissingen te nemen) en verbondenheid (vermogen om deel uit te maken van de gemeenschap, zich gesteund en gewaardeerd te voelen).

WE1.9.3 Als we samen met ten minste twee affiliaties richtlijnen voor mobiel-eerst onboarding ontwerpen, kunnen we eind juni identificeren welke hiaten door organisatoren als het meest nadelig worden gezien voor het behoud van mobiel-eerst nieuwkomers.
WE1.10.3 Als we met een paar geselecteerde gemeenschappen werken om de Workflow van de artikelgids aan te passen voor hun wiki's, krijgen redacteuren leiding die is afgestemd op de inhoud en beleid van elke gemeenschap.
WE1.10.5 Als we alle pad-naar-productie-vereisten voor de artikelrichtlijnen A/B-test voltooien (inclusief beveiligingsbeoordeling, juridisch advies, instrumentatie, community outline review en vertaling, en experimentconfiguratie), zullen we het experiment starten zodat het voor het einde van Kwartaal 4 kan worden afgerond en beginnen we statistisch betekenisvolle gegevens te genereren over de impact van artikelrichtlijnen op de 30-dagen overlevingskans van artikelen die door junior redacteuren zijn gemaakt.
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.3.7 Als we kleine maar frequente wrijvingspunten in bijdrageworkflows identificeren en aanpakken, samen met vroege bijdragers, kunnen we de betrokken kerngemeenschap ondersteunen en onderhouden die de fundamentele bouwstenen voor Abstract Wikipedia bouwt.
WE2.3.8 Als we de mogelijkheden implementeren voor artikel-niveau opt-in integratie van abstracte Wikipedia-inhoud in lokale Wikipedia's, kunnen we laten zien hoe het model in de praktijk werkt en klaar zijn om in Kwartaal 1 pilotgemeenschappen erbij te betrekken.
WE2.3.9 Als we basisinstrumentatie implementeren voor Abstract Wikipedia (naast de bestaande MediaWiki-instrumentatie), zullen we beter begrijpen hoe gebruikers omgaan met Abstract Wikipedia en verbeterpunten identificeren.
WE2.3.10 Als we het weergeven van afbeeldingen uit Commons in abstract artikelen via Wikifunctions ondersteunen, stellen we gemeenschappen in staat visuele elementen te verwerken die vaak in Wikipedia-artikelen worden gebruikt.
WE2.3.13 Als we een analytische capaciteit bouwen om contentbeschikbaarheid, productie en consumptie te koppelen aan een flexibele thema-taxonomie, zullen we meer zichtbaarheid hebben op contenttrends waaruit we inzichten kunnen halen.
WE2.3.16 Als de Rust-evaluator op feature-pariteit met de Node-evaluator wordt gebracht en de Node-evaluator wordt uitgefaseerd, elimineren we een enorme onderhoudslast en maken we technische middelen vrij.
WE2.5.4 Als we in één document een migratieplan opstellen, kunnen we alle aspecten van de migratie afstemmen en uitvoeren.
WE2.5.6 Als we de mogelijkheid ontwikkelen om uitvoervergelijking tussen WDQS v1 en v2 voor geselecteerde sets queries te automatiseren, kunnen we het vertrouwen in de juistheid van de nieuwe service vergroten.
WE2.5.7 Als we een plan samenstellen voor de communicatie over onze migratie, zullen we een soepelere overgang naar de nieuwe eindpunten ervaren door af te stemmen met de Wikidata-gemeenschap over wanneer we veranderingen kunnen verwachten en hoe we ons daarop kunnen voorbereiden.
WE2.5.8 Als we beginnen met het bouwen van de ontkoppelde architectuur die in ons ontwerpdocument wordt beschreven, zouden we in staat moeten zijn om incrementeel waarde te leveren gedurende het kwartaal en te blijven staan bij een dienst die de pilotcohort kan ondersteunen tegen Boekjaar 2027 Kwartaal 1.
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.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.3 Als we op toestemming gebaseerde opslag van donorsegmenten implementeren in MediaWiki en een betrouwbare CiviCRM → MW-synchronisatie opzetten, zullen Product en Fundraising tegen het einde van het kwartaal donorsegmenten op het platform succesvol kunnen identificeren en onderscheiden via web en apps.
WE3.5.5 Als we uitgelogde donateurs op het mobiele web standaard een persistent Bedankbadge aanbieden die een korte, aangename interactie bij het tikken (C) activeert, dan zien we een verbetering van 1% in het cumulatieve behoud van 21 dagen vergeleken met een badge met een simpel popover-bericht (B), en gebruikers die helemaal geen badge krijgen na de donatie (A). We zullen ook bijhouden of een groter percentage donateurs in groep (C) in ten minste één toekomstige terugkeersessie opnieuw op de badge tikt dan in (B), om te bepalen of speelse interacties een grotere betrokkenheid creëren.
WE3.6.9 Als we coördineren tussen geïdentificeerde belanghebbenden, verzamelen we de benodigde informatie over ontwikkelingsbehoeften, afhankelijkheden en tijdlijn om een beslissingsbriefing te maken over het consumentenstrategie-meetplan dat door alle relevante belanghebbenden wordt goedgekeurd.
WE3.6.10 Als we een A/A-test uitvoeren van het retentiepercentage van ingelogde lezers, zullen we een basislijn vaststellen voor het retentiepercentage dat we kunnen gebruiken voor toekomstige kwartalen.
WE3.6.11 Als we bestaande data analyseren om te zien welke gebruikersfactoren of acties correleren met retentie, kunnen we ons begrip documenteren van welke productinterventies/hefbomen de retentie kunnen verhogen.
WE3.6.12 Als we experimenteren met het meten of het verhogen van de hoeveelheid vertaalde Wikipedia-inhoud leidt tot een directe toename van paginaweergaven, kunnen we een aanbeveling doen over toekomstige strategische investeringen in vertalingen.
WE3.7.2 Als we het ontwerp met de nieuwe "hart"-donatieknop uitrollen naar alle projecten met een header-donatielink op desktop, zal het totale aantal donaties vanaf dat instappunt niet afnemen op basis van de positieve resultaten van het vorige doorklik-experiment.
WE3.8.2 Als we leeslijsten op het web aanbieden als een opt-in bètafunctie, evenals alle nieuwe gebruikersaccounts, zal minstens 50% van de gebruikers de functie als nuttig beoordelen wanneer ze worden onderzocht.
WE3.8.3 Als we een tijdelijke widget voor de 25e verjaardags-leesuitdaging toevoegen aan de apps die gebruikers motiveert om een leesdoel te halen, zien we een 5% hogere conversieratio van casual (2-weken retour) naar actief (2-daags retour) voor gebruikers die in de eerste 14 dagen aan de challenge deelnamen, vergeleken met onze basislijn van 16,8%.
WE3.9.3 Als we de afbeeldingscarrousel en detailweergave breed uitrollen op mobiel web, zullen we de CTR > 5% op de carrousel behouden.
WE3.9.4 Als we de toevoeging van het dagelijkse quizspel "Wat kwam als eerste" aan de iOS-app testen, zullen we zien dat 15% van de betrokken uitlogde lezers op meerdere dagen terugkeert om het spel te spelen.
WE3.10.3 Als we de lezers verschillende concepten laten zien om het kennisnetwerk op de wiki's te doorzoeken, krijgen we een geprioriteerde lijst van concepten voor verdere ontwikkeling.
WE3.10.5 Als we lezers een verbeterde deeloptie geven, dan zal [33%] van de lezers die de dialoog zien de verbeterde deelactie voltooien zonder het uitgelogde lezersbehoud te schaden.
WE3.10.6 Als we de mobiele apps Explore Feed opnieuw ontwerpen, zullen we een praktisch significante toename van 10% zien in de betrokkenheid van Explore Feed over meerdere dagen per unieke uitgelogde lezer binnen 14 dagen na release.
WE3.10.7 Als we de meest frequente en belangrijke onvervulde behoeften voor gewone gebruikers identificeren (zoals door hen beoordeeld) en welke conceptideeën in een vroeg stadium het meest wenselijk en nuttig zijn, kunnen we prioriteit geven aan welke concepten we in A/B-testen in boekjaar 26-27 moeten gebruiken om de beste kans te geven om de retentie te vergroten.
WE3.10.8 Als we het toevoegen van Page Previews op Minerva testen, zullen we praktisch een aanzienlijke verbetering zien in het behoud van de lezers.
WE4.6.13 Als we gebruikers met een onbevestigd e-mailadres aanmoedigen hun e-mailadres te bevestigen, zal 10% van de actieve gebruikers die deze melding ontvangen proberen hun e-mailadres te bevestigen.
WE4.6.16 Als we steun opbouwen voor het handhaven van groepslidmaatschapsbeperkingen voor globale groepen, kunnen we dit gebruiken om een 2FA-vereiste voor globale groepen af te dwingen.
WE4.6.17 Als we 2FA-vereisten aankondigen en handhaven voor een extra groep groepen, zal het aantal gebruikers met gevoelige rechten maar geen gebruik van 2FA dalen naar 0.
WE4.6.18 Als we ondersteuning bouwen voor het handhaven van 2FA op privé wiki's, kunnen we dit gebruiken om gebruikersaccounts te beveiligen die toegang hebben tot privé-informatie.
WE4.6.19 Als we opnieuw authenticatie vereisen voor gevoelige acties en andere dergelijke maatregelen implementeren, zijn we minder kwetsbaar voor aanvallers die gebruikersscripts misbruiken.
WE4.6.20 Als we proactief gebruikersscripts scannen op kwaadaardige code, zijn we minder kwetsbaar voor aanvallers die gebruikersscripts misbruiken.
WE4.6.21 Als we het aantal personeelsaccounts met geavanceerde rechten en de duur van de rechten verminderen, is de kans kleiner dat aanvallen op personeelsaccounts schade veroorzaken.
WE4.8.1 Als we een mechanisme introduceren dat gerelateerde tijdelijke accounts detecteert en aan het licht brengt, inclusief een paneel voor verbonden accounts op Special:Contributions, zullen patrouilleurs misbruikende tijdelijke activiteiten van accounts sneller en nauwkeuriger identificeren.
WE4.8.3 Als we recente klachten onderzoeken over het langer duren van patrouilles dan voorheen, kunnen we vaststellen of deze samenhangen met de introductie van Tijdelijke Accounts.
WE4.10.1 Als we hCaptcha in fasen uitrollen naar meer wiki's (Special:CreateAccount, wikitext-editor op desktop), zullen we de dekking van botdetectie in alle projecten vergroten.
WE4.10.2 Als we de hCaptcha-botdetectie inzetten in de visuele bewerkings-, discussiehulpmiddelen, de gids voor het uploaden van bestanden en mobiele bewerkingspaden op pilotwiki's, zullen we een stijging van 35% zien in het percentage acties op Wikimedia Foundation-wiki's dat door hCaptcha is geverifieerd.
WE4.10.3 Als we een hCaptcha risicoscoreverzameling inzetten voor geblokkeerde bewerkingsmeldingen, zullen we de gevolgen van de nevenschade van IP-bereikblokken beter begrijpen.
WE4.11.1 Als we het Incident Reporting System (IRS) op enwiki uitrollen via een gefaseerde implementatie, klein beginnend en opschalend naar minstens 50% van de ingelogde gebruikers, dan hebben we genoeg data uit onze nieuw geïnstrumenteerde statistieken om te bepalen of IRS op enwiki moet worden toegepast.
WE4.12.1 Als we de prestaties van ten minste twee contentbeleidmodellen optimaliseren en vergelijken met een door de community gescreende dataset van gecontroleerde (WP:Oversight) content van de Engelstalige Wikipedia, kunnen we een model of combinatie van modellen aanbevelen voor automatische controle of het markeren van inhoud die zeer waarschijnlijk gecontroleerd zou moeten zijn.
WE4.12.2 Als we de gpt-oss-safeguard-20b, CoPE-A-9B en CoPE-b-12b modellen op LiftWing hosten en de prestaties van elk model optimaliseren om aan de aanvankelijke evaluatievereisten van het team PSI te voldoen, dan zal PSI in staat zijn om de drie modellen te testen en hun gedrag te vergelijken.
WE5.1.3e Als we een dataproduct maken voor de analyse van API-verzoeken, zullen we de analyse en segmentatie van API-verzoeken vereenvoudigen en Product Analytics in staat stellen het API Analytics Dashboard te prototypen door deze nieuwe data verder te segmenteren en te aggregeren.
WE5.1.3f Als we de API-snelheidslimieten voor verzoeken die alleen een User-Agent aanbieden verlagen, zullen we het aantal geauthenticeerde en bekende clients verhogen, door gebruikers die alleen UA gebruiken aan te moedigen over te stappen op een verantwoordelijker pad.
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.5b Als we de linter-architectuur en een kernpakket linting-regels afmaken, kunnen we de kwaliteit van OpenAPI-beschrijvingen verbeteren en programma's waarborgen voor de naleving ervan invoeren in de CI-werkstromen in API-ontwikkelingsprocessen.
WE5.2.8b Als we minstens 3 extra API-modules onboarden die verschillende use-cases demonstreren (minstens 1 standalone service-API, 1 featureteam-extensie-API, 1 interne module), kunnen we de bruikbaarheid verfijnen en de basis leggen voor de toekomst van het API-platform.
WE5.2.11b Als we de migratie van de API Portal-documentatie voltooien, kunnen we het API Portal-systeem volledig afschaffen, wat het vinden van API-documentatie zal vereenvoudigen, de consistentie van documentatie zal vergroten en het aantal API-ondersteuningssystemen zal verminderen.
WE5.2.12 Als we het ontwerp- en ontdekkingswerk dat nodig is voor het bouwen van de gezamenlijke voordeur voor ontwikkelaars vroegtijdig in opeenvolgende stappen steeds doorvoeren, kunnen we het engineeringwerk in boekjaar 26-27 effectief versnellen.
WE5.2.13 Als we beginnen met het handhaven van bestaande user-agent-beleid op de dumps-website, kunnen we dumps-gebruikers en use-cases beter begrijpen, terwijl we zorgen voor consistentere toegangsverwachtingen over de paden voor ontwikkelaars.
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.3.3 Als we hergebruikers van inhoud canonieke, wrijvingsarme ophaalpaden bieden, zullen we de inspanning verlagen die nodig is om vertrouwenssignalen uit het Wikimedia's Attribution Framework over te nemen, de standaardisatie van suboptimale ophaalpaden vermijden en onze mogelijkheid ontsluiten om attributie-adoptie betrouwbaar te meten.
WE5.3.3b Als we een datapijplijn bouwen om unieke bijdragerstellingen te berekenen en een methode ontwikkelen om deze aan MediaWiki te leveren, kunnen we deze aantallen als signaal aan Attribution API-gebruikers naar voren brengen.
WE5.3.3c Als we een API en event-stream ontwerpen en implementeren die een naïeve, op paginaweergaven gebaseerde "relatieve trending" metriek voor pagina's bieden, zullen we de Attribution API toestaan deze te gebruiken als een Trust & Engagement-metriek en prototyping voor mobiele apps mogelijk maken.
WE5.3.4 Als we "gekwalificeerd verkeer" definiëren (specifieke uitkomsten van belang) en verwijzingen onderscheiden op basis van platform en oppervlak, zullen we systematische verschillen zien in downstream-betrokkenheid en bijdrage-uitkomsten die relevant zijn voor product- en partnerschapsbeslissingen.
WE5.3.4b Als we een consistente set verkeersgezondheidsindicatoren opstellen, kunnen we betrouwbaar betekenisvolle verschuivingen in het binnenkomende verkeer van Wikimedia in de loop van de tijd en per verwijzing detecteren en verklaren, buiten het ruwe aantal paginaweergaven.
WE5.3.4c Als we zichtbaarheidsschokken in de echte wereld analyseren als natuurlijke experimenten, zullen we meetbare veranderingen zien in de kwaliteit van inhoud en de onderhoudsresultaten, wat de relatie tussen zichtbaarheid en gezondheid van de inhoud ondersteunt.
WE5.4.2c Als we de officiële Wikimedia-mobiele apps op iOS en Android in het CDN kunnen identificeren met behulp van hun applicatie-laag vingerafdrukken, kunnen we ze als bekende-client toevoegen in requestctl, waardoor we uitzonderingen en aangepaste snelheidslimieten kunnen instellen om een soepele gebruikerservaring te garanderen.
WE5.4.8b Als we verzoeken voor multimediabestanden beperken op basis van een telling van de responsgroottes, zullen we de eerlijkheid in de toewijzing van de beschikbare bandbreedte aan gebruikers vergroten.
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.12 Als we signalen creëren om mediaverkeer op locatie te onderscheiden van extern hergebruik, kan SRE het verkeer op locatie onder belasting prioriteren door dure mediaverzoeken van externe bronnen te beperken.
WE5.4.12b Als we de herkomstinformatie van de afbeelding van MediaWiki kunnen krijgen, kunnen we die gebruiken samen met andere identificaties zoals verwijzingen de toegewezen X-Is-Browser-score om de snelheidslimieten voor gebruikers op de wiki te versoepelen of te variëren.
WE5.4.13 Als we regelmatige verwerking en rapportage van WE5 objectieve indicatormetrics (verzoeksnelheid, bandbreedte en User-Agent compliance) opzetten, helpt dat ons de voortgang over de belangrijkste resultaten te volgen en de effectiviteit te beoordelen van het blokkeren van groot volume scraping en het handhaven van het User-Agent-beleid.
WE5.4.14 Als we onze WAF-software minder gekoppeld maken aan onze CDN-infrastructuur, kan deze meer use-cases bedienen, intern of niet.
WE5.4.15 Als we bekende grootschalige NAT's met wiki-gebruikers kunnen identificeren en categoriseren, kunnen we deze informatie gebruiken om snelheidslimieten en andere verdedigingen strenger af te stemmen op IP-niveau om zo een deel van de impact van scraping te verminderen.
WE5.4.16 Als we een bedreigingsmodel creëren voor geselecteerde operators van geautomatiseerd verkeer, inclusief hun intenties, investeringsniveau en toegepaste technieken, kunnen we het vermogen van de SRE-teams om scrapers en andere actoren te identificeren verbeteren.
WE5.4.17 Als we bijna realtime analyse kunnen doen van webrequestverkeer om één soort persistent scrapingcampagne te detecteren, kunnen we regels exporteren uit het data lake die we automatisch naar de rand kunnen pushen om die scraping te blokkeren/remmen.
WE6.3.3 Als we kritieke verbeteringen aan taalvariantondersteuning 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.5.1 Als we de prestatieproblemen onderzoeken en auditeren en de kwetsbaarheid van content-caching voor ingelogde gebruikers catalogiseren, geïnformeerd door de lezersstrategie voor lezersbehoud, kunnen we ST6.4 met vertrouwen plannen met het juiste prioriteringskader door te observeren welke gecatalogiseerde zorgen de meeste waarde opleveren.
WE6.5.2 Als we experimenteren met een platform voor cross-wiki code-samenwerking, waarbij we testen op minstens 4 Indiase gemeenschappen, leren we hoe we community-ontwikkelaars kunnen versterken om modules te hergebruiken in wiki's, en krijgen we positieve feedback op deze bevindingen tijdens de Hackathon in de eerste week van mei. Dit zal uitsluitend gericht zijn op Lua Modules en geïntegreerd met WMF's GitLab-infrastructuur.
WE6.6.1 Als we de runtime van de Browser Test-jobs terugbrengen tot minder dan 10 minuten, verwijderen we deze als bottleneck en verkorten we de feedbacktijd van de MediaWiki Core Main testbuild.
WE6.6.2 Als we de runtime van de Unit Test-jobs terugbrengen tot minder dan 10 minuten, verwijderen we deze als bottleneck en verkorten we de feedbacktijd van de MediaWiki Core Main testbuild.
Signals & Data Services (SDS) Hypothesen

[ SDS Belangrijke Resultaten ]

Overleg

Hypothese korte naam Kwartaal 4 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.
SDS1.5.4 Als we onze heuristieken naar een privé-repository verplaatsen, beschermen we de exacte logica en databronnen die we gebruiken tegen gemotiveerde aanvallers.
SDS1.5.5 Als we een numerieke score toevoegen aan onze meting van paginaweergave op basis van 2 van de signalen die we hebben geëvalueerd, geven we een completer en genuanceerder beeld van ons verkeer.
SDS1.5.6 Als we hCaptcha-scores gebruiken die als gebeurtenissen bij accountaanmaak worden verzameld en bewerkingen als vertrouwde labels, kunnen we ze correleren met signalen en onze huidige botdetectieheuristieken om beide te evalueren.
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.2.8 Als we end-to-end gebruikersacceptatietests (UAT) uitvoeren met analyse van de aankomende A/B/C-test van Reader Growth exclusief in GrowthBook, zullen we leren welke aspecten van de ervaring voldoen aan de productie-gereedheidsnormen en welke verbetering en ondersteunende inhoud nodig hebben voordat er een bredere uitrol plaatsvindt.
SDS2.3.1 Als we de API van GrowthBook valideren en aanpassen aan onze eigen API, kunnen we GrowthBook gebruiken als het canonieke controlevlak voor experimenten, en als we regelmatig de API van GrowthBook pollen, kunnen we experimenten die in GrowthBook zijn geconfigureerd snel en eenvoudig leveren.
SDS2.3.2 Als we aangepaste validatie in GrowthBook implementeren, weten we dat mensen experimenten niet per ongeluk verkeerd kunnen configureren op manieren die de beperkingen van het platform schenden.
SDS2.3.3 Als we de rolgebaseerde behoeften van GrowthBook-gebruikers bevestigen (mensen, automatiseringsscripts van WMF, affiliaties met gevestigde trusts en mogelijk gescreende NDA-eindgebruikers), zorgen voor automatische niet meer ondersteunen van verouderde gebruikers met regelmatige rapportage aan DPE, en documentatie bijwerken om de rolgebaseerde aanpak en gebruikersverwachtingen met betrekking tot permissies en systeeminteractie te beschrijven, zal de onboarding van gebruikers voorspelbaarder zijn, En we zullen extra bewakers hebben om te voorkomen dat we onze betaalde gelicentieerde zitplaatsen overschrijden.
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.
SDS2.4.3 Als we ondersteuning introduceren voor niet-cache splitsende experimenten, kunnen teams JS-only functies testen buiten de huidige verkeerslimieten (10% alle wiki's, 0,1% enwiki), waarmee een van de belangrijkste barrières wegneemt die teams verhinderen Test Kitchen te adopteren.
Product- en technische ondersteuning (PES) Hypothesen

[ PES Belangrijke Resultaten ]

Overleg

Hypothese korte naam Kwartaal 4 tekst Details en discussie
PES1.4.2 Als we Codex PHP makkelijker te gebruiken en stabiel genoeg maken voor een 1.0-release, zullen teams Codex PHP adopteren voor server-generated UIs. Dit zal het gebruik van Codex PHP verhogen van 3 naar 5 projecten.
PES1.5.3 Als we SLO-gebaseerde waarschuwingen mogelijk maken en het mogelijk maken om kwartaal- en automatisch rapporten te genereren, zullen service-eigenaren kunnen reageren op servicebetrouwbaarheidsgegevens zonder (altijd) SRE te hoeven starten.
PES1.5.4 Als we verwachtingen stellen met SRE-ambassadeurs over rollen en verantwoordelijkheden voor SLO's en productiegereedheid in het boekjaar 2026-27, TPgM's en doeleigenaren aan boord nemen aan die verwachtingen, en definiëren hoe de SLO-werkgroep zal opereren, bereiken we draagvlak en schaalbaarheid voor "business as usual" SLO- en productiegereedheidswerk vanaf Q1.
PES1.6.2 Als we directors aan boord nemen voor de Service Catalog, zullen ze deze vullen met "voor de hand liggende" kandidaten, en zullen we eigenaren identificeren en vinden voor minstens twee extra kritieke niet-eigendom diensten.
Future Audience (FA) Hypothesen

[ FA Belangrijke Resultaten ]

Overleg

Hypothese korte naam Kwartaal 4 tekst Details en discussie
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 een nieuwe generatie app-gebruikers en die behouden
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 Wikipedia Creator Partnerships Program 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.

Samen plannen

Januari 2025 update.

Portrait of Selena

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?

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/nl&oldid=30720474"