Jump to content

Jaarplan van de Wikimedia Foundation/2025-2026/Doelstellingen en belangrijkste 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 "Belangrijkste resultaten (KR)" vormen een meetbare manier om het succes van hun doelstellingen te volgen.
  • De onderliggende "Hypothesen" voor elk belangrijkste resultaat vertegenwoordigen het daadwerkelijke werk dat we doen om dat resultaat te behalen. Ze worden bijgewerkt in dit document en op de wikipagina's van het relevante project of team naarmate er gedurende het jaar inzichten worden verkregen.
  • 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 Belangrijkste resultaat WE1.1: Verhoog de snelheid waarmee bewerkers met ≤100 cumulatieve bewerkingen constructieve bewerkingen publiceren op mobiel internet [i] met 4% [ii], zoals gemeten door gecontroleerde experimenten (aan het einde van Kwartaal 2).
        • i. "Constructieve bewerkingen" = bewerkingen op pagina's in de namespace Main die niet binnen 48 uur na publicatie worden teruggedraaid.
        • ii. T389403#10960480
        • Nieuwe vrijwilligers worstelen om succesvol te beginnen met het bewerken. Vooral mensen die mobiele apparaten gebruiken, waar de ruimte op het scherm beperkt is en de aandacht vaak gefragmenteerd is.
        • Sommigen worden moe van de context, geduld en beproevingen en fouten die nodig zijn om opbouwende wijze bij te dragen. Anderen hebben nog geen dwingende gelegenheid gehad om het te proberen.
        • WE 1.1 zal deze problemen aanpakken door:
          • Suggesties voor het bewerken beoordelen
          • Het aanbieden van bruikbare begeleiding tijdens het bewerken
          • Het maken van meer taakspecifieke bewerkingswerkstromen
        • De kern van deze inspanningen is de noodzaak van schaalbare manieren om te ontdekken hoe in progressie zijnde bewerkingen en bestaande inhoud kunnen worden verbeterd. Om deze capaciteit te laten groeien, zullen we blijven experimenteren met machine-learning om te leren hoe het editors het beste van dienst kan zijn, in alle rollen en ervaringsniveaus.
        • Voorgestelde KR-scoremethodologie: Per platform berekenen we het aandeel interventies dat we hebben ingezet en geëvalueerd door middel van gecontroleerde experimenten die het constructieve bewerkingsdoel hebben bereikt en/of overtroffen dat we aan het begin van dit jaar hadden gesteld. Zie phab:T379285#10782051 voor de opzet.
          • NB: op 30 juni 2025 heeft WE 1.1 twee gecontroleerde experimenten gepland.
  • item wensenlijst Belangrijkste resultaat WE1.2: Toename van het aantal samenwerkingen op de wiki's met 55% op jaarbasis tegen het einde van Kwartaal 4.
    • De bijdragers hebben vaak moeite om te vinden hoe ze met elkaar kunnen samenwerken, vooral rond de onderwerpen en taken waar ze om geven. Dit kan voor nieuwkomers leiden tot een gevoel van alleen zijn op de wiki's, en het kan leiden tot uitputting voor ervaren redacteurs. Bovendien is de impact van samenwerkingsactiviteiten vaak onduidelijk, wat kan leiden tot minder mensen die zich willen aansluiten, organiseren of de samenwerking op de wiki's willen ondersteunen.
    • We willen de waarde van samenwerking duidelijker maken door het volgende te doen:
      1. Nieuwe manieren maken om de impact van samenwerkingsactiviteiten op de wiki's te delen
      2. Begin met het verzamelen van gegevens over de impact van samenwerkingsactiviteiten op het gebied van de movement
      3. De basisinfrastructuur opzetten voor het volgen van de bijdragen van samenwerking, zodat we innovatieve nieuwe manieren kunnen bieden om bijdragen in de toekomst te erkennen en te belonen
    • Samenwerking wordt gemeten door nieuwe activiteiten die worden gecreëerd via Event Registration in de extensie CampaignEvents. Het doel is dat we tegen het einde van dit KR meer gebruikers van de extensie hulpmiddelen en nieuwe manieren hebben om de impact van samenwerking te laten zien. Dit zal ons in een goede positie brengen om onze bestaande infrastructuur te verbinden met andere manieren om werk op de wiki's te erkennen en te belonen (zoals de impactmodule, bedankjes, enz.).
    • Aandachtsgebied van de wensenlijst: Bijdragers verbinden
  • item wensenlijst Belangrijkste resultaat WE1.3: Aan het einde van Kwartaal 3 bezocht 10% van de bijdragers die een homepage kregen die gericht was op nieuwe moderators, deze twee weken op rij.
    • Wij geloven dat we het beter kunnen doen om bijdragemogelijkheden voor vrijwilligers onder de aandacht te brengen. Op de lange termijn geloven we dat een homepage nuttig kan zijn voor elke bewerker om zijn werk te organiseren, nieuwe kansen te vinden en de impact ervan te begrijpen. Ons doel in boekjaar 2025/2026 is om nieuwe mogelijkheden te bieden aan ervaren bewerkers om moderatietaken op zich te nemen waar ze anders niet per se aan zouden zijn blootgesteld.
      • We zullen deze theorie eerst testen door te begrijpen hoeveel ervaren bewerkers zich zouden bezighouden met een startpagina, vergelijkbaar met waar nieuwkomers toegang toe hebben.
      • We zullen dan specifieke moderatieactiviteiten (details moeten nog worden bepaald) onder de aandacht brengen van bijdragers die nieuw zijn in dat soort moderatieacties, met als doel de last voor ervaren bewerkers te verminderen door achterstanden te verminderen (onder een nieuwe KR).
      • Als het concept van de homepage succesvol is, zijn we van plan deze pagina modulair te maken om tegemoet te komen aan de behoeften van gemeenschappen. Deze modules kunnen zaken bevatten als het gemakkelijker maken voor bewerkers om hun impact te begrijpen.
    • Opmerkingen over de methodologie:
      • We zullen een hypothese hebben om ons publiek te definiëren, die deel zal uitmaken van WE1.3.1.
      • "Moderators" zullen de definitie volgen die is gestart in Research:Develop a working definition for moderation activity and moderators, hoewel er vervolgwerk nodig zou zijn om de kwantitatieve definitie te verfijnen.
      • De tweede week wordt bepaald op basis van de timing van het eerste bezoek van elke gebruiker. In dit geval beoordelen we alle nieuwe moderators die de homepage gedurende een bepaalde periode hebben bezocht en vervolgens ten minste nog één keer (7 tot 14 dagen) opnieuw hebben bezocht.
    • Aandachtsgebied van de wensenlijst: Taakprioritering
  • item wensenlijst Belangrijkste resultaat WE1.4: Verbeter het % unieke bezoekers op de volglijst en/of recente wijzigingen die klikken om een bewerking te bekijken.
    • Ons doel is om bewerkers met meer dan 100 bewerkingen te helpen om efficiënter bewerkingen te vinden en te openen die betrekking hebben op hun interesses. We zullen het aandachtsgebied Taakprioritering, wensen laten leveren op dit gebied en om aanvullende feedback van vrijwilligers vragen over hoe deze delen kunnen worden verbeterd. We kunnen succes meten door de doeltreffendheid van elke pagina bij het "vinden van werk" te verbeteren, gedefinieerd door de indicatormetriek van de verhouding van het doorklikken.
  • Belangrijkste resultaat WE1.5: Definieer en operationaliseer zeven statistieken met hoge prioriteit die nodig zijn voor het volgen van de voortgang bij het bereiken van de doelen die zijn uiteengezet in de bijdrager-strategie tegen het einde van Kwartaal 4, door een dashboard te creëren en maandelijkse actieve moderator-statistieken te operationaliseren.
    [1] Behouden bewerkers, constructieve activering, constructieve bewerkingen, accountregistraties behouden nieuwkomers, actieve bewerkers per ambtstermijn, actieve bewerkers per ervaringsniveau.
    • De strategie voor de bijdrage-ervaring voorziet in een inspanning van 3-5 jaar om "vrijwilligersgroei te stimuleren" en "het behoud en de activatie van nieuwe en bestaande bijdragers te verhogen" door middel van drie hoofdgebieden van activiteiten:
    1. Stroomlijnen van hoe vrijwilligers aanbevelingen kunnen ontvangen, hun taken en interesses kunnen beheren, zien wat er op de wiki's gebeurt en hun impact kunnen begrijpen
    2. Aanbieden van gepast gestructureerde taken om meer duidelijkheid te creëren en vrijwilligers te helpen hun potentieel te bereiken door de werkstromen te optimaliseren waartoe we hen sturen, met inbegrip van een voortdurende investering in het leveren van gestructureerd begeleiding en het automatiseren van herhaalde taken, met een speciale focus op de mobiele webervaring
    3. Een betekenisvolle bijdrage leveren door vrijwilligers hun impact te laten zien en door te investeren in manieren voor menselijke verbinding en een milieu op basis van positieve feedback
    • Een meetstrategie schetste vervolgens een uitgebreid netwerk van statistieken voor deze veranderingstheorie. Het concludeerde dat de primaire maatregel van succes ("kernmeting") een aantal behouden redacteuren zou moeten zijn, aangevuld met een smaller indicator meting zoals de constructieve activatie en de bedoeling van de bijdragen om terug te keren en bredere "downstream" meting zoals actieve redacteuren en kwaliteitsinhoud. We moeten ervoor zorgen dat deze statistieken in een dashboard worden geopereerd en zichtbaar zijn, zodat we onze vorderingen kunnen volgen om de strategie te implementeren.

Essentiële kennis (WE2)

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

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 Belangrijkste resultaat WE3.1: Tegen het einde van Kwartaal 2 een praktisch significante toename aantonen in het vasthouden van uitgelogde lezers, zoals gemeten door middel van A/B-testen van één functie per platform
        • Deze KR zal zich richten op het blijven investeren in ervaringen die optimaliseren voor nieuwe manieren van bladeren en leren van inhoud, vaak door het gebruik van nieuwe technologieën en formaten - het presenteren van bestaande inhoud op nieuwe en boeiende manieren. In dit boekjaar willen we verder experimenteren met nieuwe functies en tegelijkertijd ons richten op het uitbreiden van succesvolle experimenten op wiki's en platforms. Het werk in de KR zal zich uitstrekken over de mobiele en desktopwebsite, evenals de iOS- en Android-apps en zich richten op het ontdekken van inhoud (browsing entry points en aanbevelingen) en aanpasbare leerformaten (machine-geassisteerde samenvattingen, content remixing).
        • Wensenlijst aandachtsgebied: Ervaringen nieuwe klanten
      • Belangrijkste resultaat WE3.2: Verhoging van het aantal donaties via niet-banner- of e-mailmethoden met 5% op jaarbasis per platform door productinterventies die diepere verbindingen bevorderen en de wrijving voor donoren verminderen tegen het einde van Kwartaal 2
        • In deze KR willen we de nieuwe toegangspunten verkennen voor donatie en andere mogelijkheden om lezers om te zetten in donateurs en ze te behouden door hun connecties met de wiki's te verdiepen, met meer gepersonaliseerde inhoud. De KR zal zich richten op het introduceren van nieuwe toegangspunten en het itereren van bestaande toegangspunten op apps en web, in samenwerking met het team fundraising.
      • Belangrijkste resultaat WE3.3: Tegen het einde van Kwartaal 2 een praktisch significante toename van het aantal ingelogde lezers aantonen, zoals gemeten door middel van A/B-testen van één functie per platform
        • In deze KR richten we ons op het verbeteren van de lezervaring en het leren van bestaande en ervaren lezers, met als doel het huidige publiek te behouden en hun verbinding met de site te verdiepen zodat ze meer kunnen leren, evenals klaar en open zijn om paden te nemen naar donatie en bewerking. Het werk hier zal zich richten op het verbeteren van de leerervaring op het web en apps (verbetering van de leesbaarheid, betere navigatie en ontdekking), evenals het uitbouwen en itereren van onze curatie- en personalisatie aanbiedingen (leeslijsten, gepersonaliseerde suggesties, gebruikers- en artikelgeschiedenis, enz.)
      • Belangrijkste resultaat WE3.4: Tegen het einde van Kwartaal 4, verwijder alle geïdentificeerde blokkers voor kleinschalige geïmplementeerde cachesites (PoPs) die voldoen aan onze huidige kwaliteits- en beveiligingsnormen, conform onze huidige cachesite-implementaties
        • Deze KR zal zich richten op het bewijzen van het concept dat we de prestaties van de website kunnen verbeteren en latentie voor onze lezers kunnen verminderen door onze caching-infrastructuur te vereenvoudigen en de processen voor de implementatie van een caching-site te verbeteren door de baseline-implementatietijd te verminderen van ongeveer een jaar gemiddeld tot maximaal een kwart. De focus zal hier zijn om de vereenvoudiging af te ronden, een PoC te implementeren, een beveiligingsonderzoek uit te voeren en een besluitbrief te voltooien over het gaan met het implementeren van onze edge caches in openbare clouds. Verminderde latentie kan leiden tot een bewezen toename van paginabeelden en een geografisch meer diverse lezerbasis.
      • Belangrijkste resultaat WE3.5: Verbeter de identificatie van donoren. Zorg ervoor dat alle ingelogde lezers die toestemming hebben gegeven, kunnen worden geïdentificeerd op basis van hun donorstatus, voor een gepersonaliseerde ervaring.
        • We zullen strategieën voor donoridentificatie implementeren om ervoor te zorgen dat alle ingelogde lezers die toestemming hebben gegeven, kunnen worden geïdentificeerd op basis van hun donorstatus. Dit zorgt voor een meer gepersonaliseerde en aantrekkelijke ervaring. Donoridentificatie zal tot en met het vierde kwartaal prioriteit krijgen om in de toekomst effectievere personalisatie- en activeringsinitiatieven te ondersteunen.
      • Belangrijkste resultaat WE3.6: Tegen het einde van Kwartaal 4 een strategie voor de Wikipedia-lezers- en consumentenervaring op verschillende platforms afronden, publiceren en communiceren, met gedefinieerde doelen en basisstatistieken, ontwikkeld in samenwerking met belanghebbenden en de gemeenschap, om ons werk tot 2030 te begeleiden.
        • Het werk aan de consumentenstrategie zal worden voortgezet, met de nadruk op het opbouwen en communiceren van de strategie, zowel intern als met de gemeenschap, en het definiëren en vaststellen van kernstatistieken voor consumenten en hun respectieve basiswaarden.

Safety and Security (WE4)

  • Doel: Onze systemen beschermen standaard de accounts en privégegevens van onze bewerkers beter, terwijl ze meer mogelijkheden bieden voor bewerkers en gebruikers met uitgebreide rechten om misbruik te voorkomen en erop te reageren. Discussie
  • Belangrijkste resultaat WE4.1: Implementeer een levensvatbaar en werkend incidentrapportagesysteem op al onze wiki's, dat wordt gebruikt en geaccepteerd door hun gemeenschappen, tegen het einde van Kwartaal 2.
    • Het verzekeren van de veiligheid en het welzijn van de gebruikers is een fundamentele verantwoordelijkheid van ons platform. Veel jurisdicties hebben regelgeving die vereist dat online platforms zoals het onze om toezicht te houden en actie te ondernemen tegen intimidatie, cyberpesten en andere schadelijke inhoud op hun platform. Als deze niet worden aangepakt, kunnen platforms worden blootgesteld aan wettelijke aansprakelijkheid en wettelijke sancties.
    • We willen onze gebruikers in staat stellen om onmiddellijke dreigingen van schade te melden via een gemakkelijk te ontdekken en intuïtief meldingsmechanisme om ervoor te zorgen dat we in staat zijn om te leren over dergelijke incidenten en om snel actie te ondernemen indien nodig. Dit is een stap om onze gebruikers veilig te laten voelen bij het bijdragen aan ons platform. We doen dit door een incidentenrapportering systeem op onze wiki's te implementeren.
  • Belangrijkste resultaat WE4.2: Verbeter de nauwkeurigheid en effectiviteit van anti-misbruikhulpmiddelen door 2 verbeteringen eind Kwartaal 2.
    • Wij en onze gemeenschap moeten niet-authentieke en kwaadaardige activiteiten op de wiki's beter detecteren en voorkomen. We zullen dit doen door het aantal en de kwaliteit van de signalen die beschikbaar zijn voor het platform te vergroten, deze signalen te combineren met hulpmiddelen die we beschikbaar stellen aan gebruikers met uitgebreide rechten, en te identificeren waar we veilig geautomatiseerde beperkingen kunnen opleggen aan verdachte activiteiten.
    • We zien ook mogelijkheden om tegelijkertijd de toegankelijkheid van Wikipedia en onze andere projecten te verbeteren. Een van de projecten is bijvoorbeeld het vervangen van de zeer conventionele zelfbeheerde CAPTCHA van de wiki's, die de gebruiker ervan weerhoudt in te loggen totdat hij een puzzel heeft opgelost, door een risicoscoreservice die de gebruiker zelden uitdaagt. In plaats daarvan zou het accounts stilletjes taggen met een niveau van achterdocht dat we kunnen gebruiken om functionaliteit uit te schakelen, en deze status zichtbaar maken voor moderators met hoge privileges om te helpen bij hun werk.
    • Meer in het algemeen zijn Wikimedia-projecten sterk afhankelijk van het blokkeren van IP-adressen om misbruik door kwaadwillenden te beperken. Dit is steeds minder effectief in het stoppen van misbruik en heeft een negatieve invloed op gebruikers te goeder trouw die worden beïnvloed door IP- en IP-bereikblokkades. In deze KR streven we ernaar om bestaande mogelijkheden te verbeteren en nieuwe tools te leveren die het mogelijk maken om kwaadwillenden nauwkeuriger en effectiever te blokkeren en de nevenschade veroorzaakt door IP- en IP-bereikblokken te verminderen.
    • Om onze effectiviteit te meten, zullen we kijken naar kwalitatieve feedback van vrijwilligers die zich bezighouden met anti-misbruikwerk, en kwantitatieve indicatoren zoals de snelheid van IP-blokkades die worden ingezet, de acceptatie van IP-reputatie en op browsersignalen gebaseerde mitigaties, de snelheid van waarschijnlijk-menselijke interacties wanneer een gebruiker wordt geblokkeerd, en de acceptatie van nieuwe signalen van hulpmiddelen voor anti-misbruik.
    • Het werk in deze KR omvat verbeterde detectie en beperking van sockpuppet- en banontwijking, het naar boven halen van informatie over het potentieel voor nevenschade, het versterken van bot-detectie, het naar boven halen van signalen aan anti-misbruik vrijwilligers, verbeterde efficiëntie de interfaces van hulpmiddelen voor anti-misbruik, het verbeteren van statistieken met betrekking tot misbruik en het verstrekken van suggesties voor verdachte accountactiviteit voor onderzoek aan CheckUsers.
  • Belangrijkste resultaat WE4.3: Verminder, tegen het eind van Kwartaal 4, het aantal grootschalige aanvallen waarvoor menselijke tussenkomst in SRE vereist is met 50% (vergeleken met boekjaar 2019)
    • De evolutie van het internetlandschap, met inbegrip van de opkomst van botnetten op grote schaal en frequente aanvallen, heeft onze traditionele methoden om grote schaalmisbruik te beperken, verouderd gemaakt. Dergelijke aanvallen kunnen onze sites niet beschikbaar maken door onze infrastructuur te overspoelen met verzoeken, of het vermogen van onze gemeenschap om grootschalige vandalisme te bestrijden, overweldigen. Dit brengt onze geprivilegieerde redacteurs en onze technische gemeenschap ook onder onredelijke druk.
    • We moeten dringend ons vermogen verbeteren om dergelijke aanvallen automatisch te detecteren, te weerstaan en te beperken of te stoppen.
    • Dit jaar zullen we ons vooral richten op het automatiseren van het detecteren van IP-adressen en netwerken die regelmatig aanvallen tegen ons doen, en het verminderen van de hoeveelheid belasting die de aanhoudend schadelijke entiteiten op onze systemen mogen plaatsen.
  • Belangrijkste resultaat WE4.4: Vanaf Kwartaal 2 zijn tijdelijke accounts bij 100% van onze projecten geïmplementeerd, waardoor de persoonlijke, identificeerbare informatie van onze niet-geregistreerde redacteuren beschikbaar is voor minder dan 0,1% van de gebruikers.
    • Tijdelijke accounts zijn bedoeld om de privacy en daarmee de veiligheid van onze niet-geregistreerde redacteuren te verbeteren door hun persoonlijk identificeerbare informatie (IP-adres) te beschermen tegen het publiek en de toegang te beperken tot alleen degenen die deze nodig hebben voor patrouilledoeleinden. Naast een grote verbetering van de veiligheid van de gebruikers is dit project ook belangrijk om aan verschillende wettelijke voorschriften te voldoen.
  • Belangrijkste resultaat WE4.5: Evalueer de impact van generatieve AI op vertrouwen en veiligheid, en bepaal productinterventies om kansen te benutten en bedreigingen voor Wikimedia-projecten te voorkomen, tegen het einde van Kwartaal 3.
    • Het gebruik van AI, en in het bijzonder generatieve AI, neemt snel toe op het internet. Er zijn kansen voor vertrouwen en veiligheid, maar ook bedreigingen die ontstaan nu AI alomtegenwoordig wordt. Content is bijvoorbeeld gemakkelijker en goedkoper te genereren, maar moderatie vereist meer inspanning. Ook kan onderzoek met veel minder moeite worden uitgevoerd, maar AI-hallucinaties zijn moeilijk te identificeren.
    • Dit project is gericht op de 'Human Rights Impact Assessment' van ML/AI, door de impact van AI op vertrouwen en veiligheid van het ecosysteem van Wikimedia te beoordelen. Dit omvat:
      • Overleg met gebruikers met uitgebreide rechten.
      • Voorbeelden identificeren van generatief AI-ondersteund misbruik en mogelijke verminderingen.
      • Het identificeren van ML-mogelijkheden om de werklast voor gebruikers met uitgebreide rechten te verminderen.
      • Experimenten uitvoeren om te begrijpen waar we ons op moeten concentreren om de meeste impact te maken.
  • Belangrijkste resultaat WE4.6: Technisch afdwingen dat 100% van de privileges die gebruikers in staat stellen om beveiligings- of privacygevoelige acties uit te voeren, alleen kunnen worden uitgevoerd door accounts die tweefactorauthenticatie hebben ingeschakeld, tegen het einde van Kwartaal 4.
    • We moeten de beveiliging van de gebruikersaccounts op onze wiki's versterken, vooral voor gebruikers met gevoelige rechten. Een belangrijk aandachtspunt is de eis dat gevoelige acties alleen kunnen worden ondernomen door gebruikers die tweefactorauthenticatie (2FA) hebben ingeschakeld. We zullen een uitgebreider systeem bouwen voor het afdwingen van bevoegdheden dat de noodzaak van audits en handmatige handhaving van 2FA omzeilt, en uitbreiden welke rechten vereisen dat 2FA op het platform wordt ingeschakeld.
    • Als onderdeel hiervan zullen we onze authenticatie- en herstelsystemen verbeteren, zodat wij (WMF) en onze gebruikers gemakkelijker een strengere houding ten opzichte van 2FA kunnen ondersteunen. We zullen de algemene beschikbaarheid van 2FA op het hele platform uitbreiden, zodat elke gebruiker het naar wens kan inschakelen en ervoor kan zorgen dat het wordt ingeschakeld voordat gevoelige rechten worden verleend. We zullen ook onze aandacht richten op het verminderen van de operationele belasting die wordt gedragen door onze accountherstel- en ondersteuningssystemen, om onze reset- en herstelprocessen rond het inloggen op accounts te stroomlijnen. We zijn verder van plan om de bruikbaarheid van onze 2FA-implementatie te verbeteren door gebruikers meer opties te bieden om hun accounts te beveiligen en onbedoelde vergrendeling te voorkomen.

Verantwoord gebruik van infrastructuur (WE5)

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

Het pad versnellen naar productresultaten (WE6)

  • Doel: Wikimedia-ontwikkelaars kunnen hun producten snel en met vertrouwen aan eindgebruikers aanbieden. Discussie
    • Objectieve context: Om effectief te zijn in het realiseren van de vier strategische pijlers, moeten Wikimedia-ontwikkelaars hun tijd en moeite besteden aan activiteiten met een hoog rendement die resulteren in het zo snel mogelijk opleveren van kwaliteitsproducten. Te ingewikkelde workflows, een gebrek aan standaardhulpmiddelen en onhoudbare systeemcomponenten staan ​​deze resultaten in de weg.
    • Dit werk bouwt voort op het momentum dat we hebben opgebouwd tijdens de afgelopen twee jaarplannen, waarbij MediaWiki als platform en de software die de ontwikkeling en implementatie ervan ondersteunt, verder zijn ontwikkeld. De werkzaamheden voor dit jaar zullen zich richten op het bieden van betrouwbaardere ontwikkelomgevingen, het vereenvoudigen van pre-productieworkflows en het verminderen van platform- en infrastructuurrisico's.
      • Belangrijkste resultaat WE6.1: Tegen het einde van Kwartaal 4 is het aantal bugs die de testwiki's passeren, met 10% verminderd
        • In 2024 moesten ontwikkelaars 144 keer hun werk herzien omdat er een noodsituatie was die de implementatie van MediaWiki verhinderde. In veel van die gevallen werden de bugs ontdekt nadat ze waren geïmplementeerd op testwiki's, wat betekent dat het probleem een ​​potentieel publiek van miljarden gebruikers bereikte. We hebben geen controle over het feit dat er bugs zullen zijn, maar als we ze eerder zouden ontdekken, is er minder heldenwerk nodig. Het zou ontwikkelaars ook het vertrouwen geven dat er geen grote problemen zullen zijn als iets daadwerkelijk in productie gaat.
        • We zullen deze bugs eerder opsporen door omgevingen te creëren die ontwikkelaars nodig hebben om hun code met vertrouwen te leveren en te testen gedurende de hele ontwikkel- en implementatiecyclus. We moeten er ook voor zorgen dat deze verbeteringen niet ten koste gaan van de snelheid van ontwikkelaars.
      • Belangrijkste resultaat WE6.2: Tegen het einde van Kwartaal 4 kunnen 4 stappen uit de checklist voor de productiegereedheid worden uitgevoerd zonder SRE-interventie
        • Het implementeren van een nieuwe service of feature in productie is nu afhankelijk van een lijst met 24 stappen, waarbij elke stap doorgaans ondersteuning van SRE's vereist. We hebben het SRE-ambassadeursprogramma opgezet om eerder in de ontwikkelcyclus in te grijpen en capaciteit binnen de ontwikkelteams zelf op te bouwen, maar veel van de taken zouden volledig zelf te beheren moeten zijn. Momenteel komt dit neer op handmatig, repetitief en te automatiseren werk dat lineair schaalt met het aantal ontwikkelteams. Dit is op de lange termijn niet houdbaar voor het SRE-team.
        • In het verleden werd een groot deel van dit werk aan ontwikkelteams overgelaten door een set gedeelde, gemeenschappelijke bibliotheken en beste aanpakken te onderhouden voor de interactie met ons platform. Deze zijn verdwenen toen we overstapten naar onze nieuwe Kubernetes-infrastructuur en er is geen directe vervanging. Door vergelijkbare bibliotheken, documentatie en training te bieden die van toepassing zijn op de manier waarop we vandaag de dag bouwen en implementeren, geloven we dat we de benodigde betrokkenheid van SRE kunnen verminderen voordat een nieuwe service of functie in productie wordt genomen.
      • Belangrijkste resultaat WE6.3: Tegen het einde van Kwartaal 4 worden 100% van de Wikipedia-paginaweergaven via Parsoid verzorgd
        • Parsoid biedt verbeterde mogelijkheden voor wikitext-ontwikkeling en toekomstbestendigheid van het platform. Het gelijktijdig onderhouden van twee parsers is op de lange termijn niet houdbaar, omdat dit de technische schuld en complexiteit vergroot. Bovendien hangt het succes van sommige nieuwe projecten zoals Wikifunctions af van de brede beschikbaarheid van Parsoid.
        • We hebben de uitrol op kleinere projecten uitgebreid en dit jaar zullen we klaar zijn voor de Wikipedia's. Het bedienen van alle pagina-voorzieningen van Wikipedia door Parsoid is de belangrijkste volgende mijlpaal. Naast de uitrol zelf omvat dit werk ook het oplossen van prestatieproblemen en het effectief communiceren over de impact aan lezers en redacteuren.
      • Belangrijkste resultaat WE6.4: Tegen het einde van Kwartaal 2 zijn ten minste twee geïdentificeerde risico's die onze mogelijkheid om de wiki's te blijven implementeren of opschalen bedreigen, verminderd of teruggebracht tot een acceptabel niveau
        • Door middel van een aantal gerichte initiatieven zullen we diverse risico's op het gebied van schaalbaarheid, betrouwbaarheid en beveiliging verminderen of beperken die wij hebben geïdentificeerd als een waarschijnlijke potentiële bedreiging voor de groei en duurzaamheid van ons platform en onze openbare projecten.
        • Zo zullen we bijvoorbeeld de structuur van de kerndatabases van Commons refactoren om ervoor te zorgen dat de groei ervan de komende jaren niet wordt beperkt door de capaciteit van de beschikbare serverhardware. Ook zullen we PHP, de programmeertaal die MediaWiki en gerelateerde diensten aanstuurt, upgraden naar een modernere versie. Andere geïdentificeerde risico's zullen waarschijnlijk aanvullende beveiligingsmaatregelen vereisen om onze infrastructuur te beschermen en te versterken.

Signalen en datadiensten (SDS)

Metingen (SDS1)

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

Experimenteerplatform (SDS2)

  • Doel: Productmanagers kunnen snel, eenvoudig en met zekerheid de impact van wijzigingen in productfuncties op Wikipedia evalueren. Discussie
    • Objectieve context: Om data-gedreven besluitvorming over de ontwikkeling van productfuncties mogelijk te maken en te versnellen, hebben productmanagers een experimentenplatform nodig waarmee ze functies kunnen definiëren, doelgroepen voor gebruikers kunnen selecteren en de impact kunnen meten. Het verkorten van de tijd tussen lancering en analyse is cruciaal, aangezien het verkorten van de leertijd experimenten en uiteindelijk innovatie zal versnellen. Handmatige taken en op maat gemaakte meetmethoden worden gezien als belemmeringen voor snelheid. Het ideale scenario is dat productmanagers van de lancering van een experiment tot de ontdekking kunnen komen met weinig tot geen handmatige tussenkomst van engineers en analisten.
    • We richten ons het komende boekjaar op Wikipedia, omdat Core Experiences daar graag mee wil experimenteren (de organisatiestrategie vereist dat we ons volledig op Wikipedia richten), en omdat het ons in staat stelt om te focussen en duidelijker aan te geven met welke teams en projecten we bezig zijn. Andere teams hebben de componenten van het experimentele platform gebruikt en zullen dat mogelijk blijven doen, maar dat gebruik zal niet de focus van deze doelstelling zijn.
      • Belangrijkste resultaat SDS2.1: Tegen het einde van Kwartaal 2, maak de voltooiing van ten minste 2 volledige experimentcycli mogelijk met behulp van het experimenteerplatform.
        • Aangezien de organisatie steeds meer nadruk legt op gegevensgebaseerde productbeslissingen, moeten we experimenteren toegankelijk maken voor alle productteams, niet alleen voor degenen met gespecialiseerde vaardigheden. Productteams hebben gedeelde normen, hulpmiddelen en infrastructuur nodig die hen in staat stelt:
          • Snel ideeën testen met onze wereldwijde gebruikers
          • Meten van de impact van productwijzigingen met gestandaardiseerde metingen
          • De resultaten transparant delen met onze belanghebbenden van de movement
        • Waarom wij ons van het aantal geactiveerde teams naar het aantal voltooide experimenten gaan richten:
        1. Strategische afstemming: het is de belangrijkste succesmeting van het platform
        2. Data-geïnformeerde aanpak: Ons gebruikersonderzoek (in progressie) suggereert variabele teambereidheid in de organisatie, terwijl we weten dat het webteam interesse heeft bevestigd in twee specifieke experimenten.
        3. Resource optimalisatie: Onze MVP-platform zal een high-touch onboarding vereisen, waardoor het op korte termijn efficiënter is om te focussen op experimentele mogelijkheden in plaats van een breed netwerk te maken over meerdere teams. Wij zijn van plan om naar een algemene vrijstelling te gaan en willen niet opnieuw in trainingsteams investeren, als we dat kunnen voorkomen.
        4. Toekomstgericht: Feedback van de volledige experimentele cycli zal onze platformverbeteringen effectiever informeren dan de leer van de gedeeltelijke of onvolledige adoptie. Als we verder gaan naar algemene release, focussen op het voltooien van het experiment vermijdt het investeren in tijdelijke benaderingen die opnieuw moeten worden ontwikkeld.
        • We zijn bezig met gebruikersonderzoek om de behoeften en eisen van het team te bepalen: enquêtes en interviews zijn gepland om de behoeften van het productteam in de tweede helft van mei 2025 duidelijk te maken. Zodra het onderzoek is afgerond, maken we een experimentatie kalender die kan worden gebruikt om onze volgende KR-doelstellingen en prioriteiten te bepalen.

Toekomstige gebruikers (Future Audiences, FA)

Toekomstige gebruikers (FA1)

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

Sociale video (FA2)

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

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

Product- en technische ondersteuning (PES1)

  • Doel: WMF Product- en Engineering-teams zijn effectiever dankzij verbeterde processen, wat een positieve verschuiving in onze cultuur bevordert. Discussie
    • Doel context: Deze doelstelling gaat over het sneller, slimmer en beter maken van de manieren van werken van de Wikimedia Foundation. Het gaat erom hoe we werken. Dit betekent minder frictie en obstakels (inefficiënties en fouten) in processen en sneller impact. Deze doelstelling gaat ook over het aanleren van werkwijzen die in de hele afdeling en organisatie kunnen worden toegepast.
      • Belangrijkste resultaat PES1.1: Tegen het einde van Kwartaal 2 SLO's definiëren voor 6 productiediensten op basis van een prioriteringsrubriek die tot doel heeft ons leren te maximaliseren over het definiëren en gebruiken van SLO's om weloverwogen beslissingen te nemen over het prioriteren van betrouwbaarheidsgerelateerd werk door teams van belanghebbenden.
        • Een Service Level Objective (SLO) is een overeenkomst tussen teams van belanghebbenden over een doelserviceniveau (betrouwbaarheid/prestaties) waaraan teams samenwerken (en die niet veel worden overschreden). Het helpt bijvoorbeeld te bepalen wanneer betrouwbaarheids- of prestatiewerk prioriteit moet krijgen of deprioritair moet worden gegeven door een ontwikkelingsteam, of wat een probleem is. Teams moeten zich zorgen maken over het identificeren van wat onmiddellijk is (waarschuwing/incidentrespons/kritieke bugs) en wat niet. Het doel is om wrijving tussen functies te verminderen door te onderhandelen over doelen en te informeren over gedeelde en duidelijke prioritering.
      • Belangrijkste resultaat PES1.2: Tegen het einde van Kwartaal 2 hebben community-signalen (inclusief de wensenlijst) WMF beïnvloed om prioriteit te geven aan ten minste 5 productwerkstromen voor de Kwartalen 3 en 4.
        • Ons doel is om te identificeren en te vieren wanneer teams prioriteit geven aan werk op basis van evidence-based community-verzoeken.
        • Twee geplande hypothesen zijn uitsluitend gericht op de wensenlijst. Ze zijn ontworpen om het vertrouwen te verbeteren, processen te stroomlijnen en de participatie van personeel en vrijwilligers te vergroten. Een andere hypothese is een experiment dat is ontworpen om te zien of er voldoende waardevolle signalen zijn van de kroeg, enz., en of AI onze signaalverzameling kan ondersteunen.
      • Belangrijkste resultaat PES1.3: Twee afdelingsoverschrijdende experimenten in een vroeg stadium, gevalideerd door onze externe consumenten-, donor- en bijdragersdoelgroepen, worden door de Foundation opgenomen in het jaarplan.
        • Dit werk gaat over het creëren van experimenten en experimenteerprocessen die in onze hele organisatie kunnen worden toegepast.
        • De Foundation versterkt een cultuur van afdelingsoverschrijdende experimenten door twee gevalideerde experimenten in een vroeg stadium in haar jaarlijkse planning op te nemen. Dit initiatief bevordert de samenwerking buiten de functieteams van de afdeling Product & Technology, waardoor meer innovatie met andere afdelingen in de organisatie (zoals Communicatie en Vooruitgang) wordt aangemoedigd. Door niet-geteste nieuwere ideeën te zaaien en processen voor experimenten te stroomlijnen, verbeteren teams de productiviteit en schaalimpact. Succes wordt gemeten door twee afdelingsoverschrijdende experimenten per jaar te voltooien, deze te integreren in toekomstig OKR-werk en de acceptatie van experimenteerpraktijken te vergroten. Voorbeelden van resultaten zijn nieuwe prototypes om de groei en productiviteit van nieuwe bewerkers te vergroten, tot experimentele functies die de band tussen lezer en donateur met Wikipedia verdiepen. Een specifieke mogelijkheid die is geïdentificeerd, is het verbinden van kleine functieverkenningen om de 25e verjaardag van Wikipedia te vieren.

Hypothesen

Kwartaal 1

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

Wiki Experiences (WE) Hypothesen

[ WE Belangrijkste Resultaten ]

Overleg

Hypothese korte naam Kwartaal 1 tekst Details en discussie
WE1.1.1 Als we nieuwe(re) vrijwilligers die tekst van een externe site plakken vragen om te bevestigen of ze de inhoud hebben geschreven die ze proberen toe te voegen, dan zullen we een afname van ≥10% zien in het percentage nieuwe inhoudsbewerkingen die nieuwe(re) vrijwilligers publiceren die worden teruggedraaid op grond van WP:COPYVIO (en gerelateerd beleid).
WE1.1.2 Als we een eerste bètaversie van de voorgestelde bewerking "Verbeteren tonen" leveren, kunnen we leren of dit nieuwe formaat van voorgestelde bewerkingen een zinvolle manier is om het aantal constructieve bewerkingen voor nieuwe bijdragers te vergroten zonder de moderatielast voor patrollers/beoordelaars te vergroten.
WE1.1.3 Als we een nieuwe suggestiemodus gericht op Senior Bijdragers implementeren in de visuele editor (mobiel + desktop) als een bètafunctie met minstens 3 nieuwe bewerkingssuggesties erin, zullen we ontdekken welke - indien van toepassing - aanpassingen moeten worden gemaakt voordat we de ervaring met nieuwe(re) vrijwilligers evalueren door middel van een gecontroleerd experiment.
WE1.1.4 Als we Reference Check op en.wiki inzetten via een gecontroleerd experiment, zullen we een toename van ≥10% zien in het aantal constructieve bewerkingen dat nieuwe(re) vrijwilligers publiceren en leren of er voldoende steun is onder patrollers en moderators om de functie op grotere schaal in te schakelen.
WE1.1.5 Als we een voortgangssysteem testen via ontwerpprototypes met nieuwkomers, dan kunnen we identificeren welke soorten mijlpalen, begeleiding en erkenning als het meest motiverend worden ervaren, en deze inzichten gebruiken om een ontwerp af te ronden voor toekomstige pilot-wiki-experimenten.
WE1.1.6 Als we de belangrijkste technische, sociale en gedragsbarrières en -factoren voor mobiele webbewerking onderzoeken door middel van gebruikersonderzoek en gegevensanalyse, zullen we ten minste 3 bruikbare inzichten genereren die belangrijke kennislacunes dichten en ons vermogen versterken om met vertrouwen productinvesteringen te prioriteren voor de tweede helft van FY25/26 en daarna.
WE1.2.1 Als we een proof of concept creëren voor het weergeven van gegevens over gezamenlijke bijdragen op de wiki's, kunnen we feedback verzamelen van ten minste 30 bijdragers, waarbij 70% van de respondenten deelt dat de functie nuttig is en kan helpen bij het stimuleren van gezamenlijke groei.
WE1.3.1 Als we gebruik maken van de behoeften die zijn geïdentificeerd uit eerder onderzoek en ontwerp en vroege prototypes (mockups) van de top X meest impactvolle moderatormodules delen, kunnen we de startpagina aanpassen voor moderatieacties met hen.
WE1.3.2 Als we de startpagina voor nieuwkomers aanpassen om moderatormodules voorwaardelijk weer te geven, kunnen we de haalbaarheid van het gebruik van de startpagina voor moderators bewijzen.
WE1.4.1 Als we een aantal verbeteringen aanbrengen die worden genoemd in T396489 zullen we de trage query's voor recente wijzigingen op grote wiki's met X procent verminderen. Dan zullen moderator-hulpmiddelen in staat zijn om homepage-modules op die wiki's te implementeren zonder speciale zorgen over de prestaties van de database. T400696
WE2.1.1 Als we moedertaalsprekers van kleine wiki's uitnodigen via een CentralNotice-banner op een drukbezochte Wikipedia in hun regio om bij te dragen aan voorgestelde bewerkingen (SuggestedEdits) en andere groeifuncties, kunnen we beoordelen of deze aanpak nieuwe moedertaalsprekers aantrekt en of ze deze bewerkingshulpmiddelen gebruiken om essentiële inhoud te verbeteren.
WE2.1.2 Als we vertaalsuggesties zouden ontwikkelen en vrijgeven die zijn afgestemd op nieuwe bewerkers, zouden we kunnen testen of deze aanpak betere vertaalresultaten oplevert in vergelijking met onze huidige aanpak.

Dit pakt de bekende uitdagingen aan waarmee nieuwe bewerkers worden geconfronteerd, die een grotere kans hebben om artikelen te verwijderen. Door hen te wijzen op het vertalen van beter beheersbare inhoud, is het doel om een minder overweldigende en meer toegankelijke inleiding tot het vertaalproces te bieden. Goede artikel- en sectiekandidaten kunnen eruitzien als een beperkte complexiteit in termen van opmaak en totale lengte.

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

[ SDS Belangrijkste Resultaten ]

Overleg

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

[ FA Belangrijkste Resultaten ]

Overleg

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

[ PES Belangrijkste Resultaten ]

Overleg

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

Kwartaal 2

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

Wiki Experiences (WE) Hypothesen

[ WE Belangrijkste Resultaten ]

Overleg

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

[ SDS Belangrijkste Resultaten ]

Overleg

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

[ FA Belangrijkste Resultaten ]

Overleg

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

[ PES Belangrijkste Resultaten ]

Overleg

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

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=29615388"