Piano annuale di Wikimedia Foundation/2025-2026/Product & Technology OKRs

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

Outdated translations are marked like this.

Il prossimo anno

Anche se il mondo cambia, la Wikimedia Foundation rimane convinta che la nostra missione - rendere e mantenere le informazioni utili dei progetti disponibili su internet gratuitamente - sia uno sforzo multigenerazionale: vogliamo che la conoscenza libera continui a essere disponibile per molte generazioni a venire.

Internet sta cambiando velocemente. Le nuove generazioni si informano attraverso video sui social e tecnologie di intelligenza artificiale, e, rispetto alle generazioni precedenti, un numero minore di loro è a conoscenza di Wikipedia. Stiamo assistendo a un calo del numero di persone che visitano i nostri siti e del numero di persone che li modificano. Nel frattempo, le piattaforme di Internet dipendono dai contenuti di Wikimedia per sostenere le loro offerte di ricerca e intelligenza artificiale. Queste dinamiche rappresentano sfide importanti, ma chiariscono perché la conoscenza libera e affidabile che creiamo insieme è così importante. Il mondo ha bisogno più che mai di una fonte di conoscenza affidabile e verificata dall'uomo, e i progetti Wikimedia continuano a dimostrare di poterla fornire.

Per affrontare queste sfide nel prossimo anno, creeremo percorsi per sfruttare i contenuti di Wikimedia in modo sostenibile, e porteremo i contenuti di Wikimedia in spazi social online dove le nuove generazioni trascorrono il loro tempo. Miglioreremo i nostri siti in modo che i lettori vogliano tornare, impegnarsi a fondo e contribuire in modi che siano significativi per loro. E investiremo nella nostra capacità di sperimentare rapidamente nuove tecnologie, in modo che il nostro ritmo di sviluppo possa corrispondere al ritmo con cui il mondo cambia.

L'obiettivo dell'infrastruttura è il modo in cui la piattaforma e l'esperienza dell'utente supporteranno la risoluzione di queste sfide e il raggiungimento della maggior parte dei partecipanti al movimento. Non si tratta di un elenco di progetti, ma di una serie di indicazioni per alimentare la crescita dei volontari, consentire loro di costruire contenuti enciclopedici affidabili, finanziare la nostra missione e far evolvere la nostra offerta per dare forma a Internet che cambia. Per saperne di più su questi quattro pilastri strategici.

Alimentare la crescita dei volontari

La comunità dei volontari è il motore unico del successo dei progetti Wikimedia e abbiamo bisogno che sia sana e in crescita. Ma nell'ultimo anno abbiamo assistito a un continuo calo del numero di redattori nuovi e di ritorno ai progetti. Per comprendere meglio e rispondere in modo più efficace alle esigenze dei nostri attuali volontari, la Foundation ha rinnovato la Community Wishlist, trasformandola da un sondaggio annuale in un processo di assunzione sempre aperto in cui le esigenze degli utenti e le idee di progetto possono alimentare il lavoro di diversi team della Foundation. Abbiamo raggruppato i desideri in "Aree di interesse" e abbiamo integrato tre di queste Aree di interesse tra i risultati chiave del piano annuale. Abbiamo anche avviato un Consiglio consultivo per i prodotti e la tecnologia pilota per integrare le numerose conversazioni che i team della Fondazione hanno con i membri della comunità dentro e fuori wiki durante l'anno. Inoltre, abbiamo individuato opportunità per coinvolgere nuove generazioni nei nostri progetti, come il fatto che i più giovani partecipano volentieri ad altri spazi sociali online dove hanno a disposizione modi semplici e mobili per connettersi su argomenti di interesse comune.

Nel prossimo anno, alimenteremo la crescita dei volontari rendendo il contributo più facile e attraente per le nuove generazioni attraverso l'espansione del mobile-first, nuovi modi di modificare (“compiti strutturati”) e l'aggiunta di flussi di lavoro intelligenti che rendono facile la modifica costruttiva da mobile per i nuovi collaboratori (“controlli di modifica”). Per coinvolgere e fidelizzare maggiormente i volontari esistenti, offriremo azioni e compiti raccomandati e li metteremo in evidenza in un hub centrale che renderà facile organizzare l'attività su wiki. Useremo l'intelligenza artificiale per rafforzare i volontari nel loro lavoro, mantenendo sempre gli esseri umani informati e dando priorità alla trasparenza. Per i volontari, sia nuovi che esperti, creeremo delle vie per connettersi e lavorare insieme sui nostri siti - ispirandoci a campagne di successo e WikiProjects - permettendo loro di trovare redattori che condividono le loro idee e di migliorare i contenuti relativi ai loro interessi (in linea con l'area di interesse della Wishlist).

Fornire un contenuto enciclopedico affidabile

Con il moltiplicarsi del materiale generato dall'intelligenza artificiale su Internet, il mondo ha più che mai bisogno di contenuti enciclopedici affidabili. Vogliamo aumentare le capacità dei volontari di creare nuovi contenuti, garantire che quelli esistenti rimangano affidabili e fornire contenuti affidabili a una nuova generazione di lettori con nuove esigenze e preferenze.

Per aiutare i volontari a creare nuovi contenuti, ci baseremo su strumenti e flussi di lavoro guidati già esistenti (come il Content Translation Tool), in modo che le comunità più grandi e quelle più piccole possano coprire contenuti vitali. Per garantire che i contenuti esistenti rimangano affidabili, aiuteremo i volontari esperti a gestire meglio il loro crescente carico di lavoro estendendo gli strumenti che usano per trovare i compiti che richiedono la loro attenzione, rendendo più facile per loro aggiornare gli articoli e ripristinare le modifiche non utili (in linea con l'area di interesse della Wishlist).

Aiuteremo anche i funzionari a difendere i nostri contenuti facendo emergere nuovi segnali (oltre gli indirizzi IP) che identificano i malintenzionati, consentendo di bloccare gli utenti in modo da ridurre al minimo il blocco erroneo degli editor in buona fede.

Per offrire contenuti enciclopedici a una nuova generazione, creeremo funzioni che aiutino nuovi tipi di lettori a capire facilmente gli articoli, li aiutino a trovare le informazioni a cui sono interessati, e permettano loro di participare attivamente mentre leggono. Questi cambiamenti hanno lo scopo di incoraggiare i nuovi lettori di Wikipedia a diventare lettori di Wikipedia dedicati, e alcuni di loro a diventare donatori (in linea con l'area di interesse della Wishlist).

Fornire contenuti affidabili significa anche supportare un modello di "conoscenza come servizio", in cui tutto l'internet attinge ai contenuti di Wikimedia. In questo modello, la nostra infrastruttura non è solo una risorsa preziosa per gli esseri umani che visitano il nostro sito web, ma anche per le aziende di ricerca e di IA, che accedono automaticamente ai nostri contenuti come input e output fondamentale dei loro prodotti. Questo tipo di aziende rappresentano solo uno dei tanti utilizzi che sempre più spesso impongono un carico insostenibile alla nostra infrastruttura. Nell'ultimo anno, un aumento significativo del volume di richieste provenienti da strumenti di scraper e bot ha reso più urgente la necessità di correggere questa tendenza. Dobbiamo stabilire percorsi sostenibili per gli sviluppatori e i riutilizzatori per accedere ai contenuti della conoscenza, in modo che gli esseri umani abbiano la priorità sui bot.

Finanziare il futuro del 'libero'

Il dipartimento Product e Technology svolge un ruolo importante nel garantire che il nostro movimento sia sostenibile. Nel prossimo anno, collaboreremo strettamente con il team di Fundraising in modo che i nostri donatori abbiano un'esperienza sempre più chiara e gratificante. Sui nostri siti e sulle nostre applicazioni mobili, creeremo opportunità per i lettori di esprimere il loro apprezzamento per Wikipedia attraverso le donazioni, e creeremo nuovi modi per i donatori di sentirsi apprezzati in modo che continuino a fare le loro donazioni anno dopo anno.

Dare forma a un Internet che cambia

Per portare la conoscenza libera a tutti nel mondo, dobbiamo andargli incontro dove sono, con esperienze che li aiutano a imparare. Le persone di età compresa tra i 18 e i 24 anni conoscono e utilizzano Wikipedia in misura minore rispetto alle generazioni che le hanno precedute. In particolare, imparano e interagiscono con piattaforme di video shortform, personalità online fidate, esperienze di social gaming e, sempre più spesso, applicazioni di IA. Quest'anno renderemo Wikipedia disponibile per questo pubblico nei luoghi in cui trascorrono il tempo online, in modo che conoscano Wikipedia come fonte di conoscenza affidabile e creata dall'uomo. Faremo crescere la nostra presenza nelle piattaforme video più popolari, diffondendo i contenuti di Wikipedia e generando una comunità in quegli spazi. Ed esploreremo idee per portare la conoscenza di Wikipedia nelle piattaforme di gioco e sociali.

All'interno dell'Infrastruttura, questo è suddiviso in tre portfolio di lavoro (chiamati “secchi”): Esperienze Wiki, Servizi di segnali e dati e Pubblico futuro. Questi secchi sono gli stessi dell'anno scorso e dell'anno precedente.

Nel complesso, riteniamo che questo piano risponda a un momento cruciale della storia dell'internet, consentendoci di garantire che i contenuti della conoscenza libera continuino a essere accessibili e modellati da tutte le generazioni. I nostri obiettivi e risultati chiave mostrano la struttura e i contenuti di questo piano in modo più dettagliato, e siamo desiderosi di ascoltare le domande e le idee di tutta la comunità.

Costruire, migliorare e sostenere l'infrastruttura per i progetti e i volontari Wikimedia, radicata nei nostri valori

"La Foundation metterà e manterrà a disposizione gratuitamente su Internet le informazioni utili dei suoi progetti, in perpetuo."

I team Product e Technology dedicano una priorità permanente, per tutto l'anno, alla costruzione, al miglioramento e alla manutenzione dell'infrastruttura che serve i progetti Wikimedia. Investiamo nell'hosting dei progetti Wikimedia, nello sviluppo di software open-source e di sistemi di progettazione, nella manutenzione e nel miglioramento dell'infrastruttura per i prodotti di dati e i modelli di IA.

Parte del nostro lavoro essenziale si concentra sui fondamenti dello sviluppo e dell'hosting di un grande sito web popolare. Ospitiamo i nostri progetti Wikimedia in centri dati, su server e hardware che acquistiamo, installiamo e manteniamo, collegati tra loro e al resto di Internet attraverso una rete ad alta velocità. Monitoriamo e aggiungiamo capacità laddove necessario e aggiorniamo le apparecchiature quando diventano troppo vecchie. Per esempio, quest'anno prevediamo di espandere la nostra capacità e di rinnovare l'hardware dei nostri data center di Ashburn, in Virginia, e di Carrollton, in Texas.

Progettiamo e sviluppiamo software open source (in particolare MediaWiki). Utilizziamo e distribuiamo anche molte applicazioni, librerie e framework open-source di terze parti. I bug più importanti del nostro software vengono classificati come prioritari e risolti. Il mantenimento del software open source richiede un lavoro altamente qualificato da parte di persone con competenze specifiche nello sviluppo di software open source, nell'ingegneria dell'affidabilità dei siti (SRE), nella gestione dei prodotti, nella gestione dei programmi, nel design e altro ancora. Il nostro personale lavora per garantire che il nostro software e i nostri sistemi siano aggiornati e si adattino a un ambiente in continua evoluzione. Questo include la modernizzazione del nostro codice per continuare a beneficiare delle correzioni di sicurezza e per lavorare bene con nuovi software di terze parti. Ad esempio, MediaWiki è scritto in PHP e l'anno scorso siamo passati da PHP 7.4 a 8.1, il che ha richiesto modifiche sia al codice che all'infrastruttura che ospita i nostri siti e servizi. Quest'anno ci baseremo su questo sforzo e migreremo alla versione 8.3, utilizzando le lezioni apprese e gli strumenti sviluppati con l'aggiornamento alla versione 8.1. L'aggiornamento renderà i nostri sistemi più veloci per i lettori, più facili da usare per il personale e i volontari e più sicuri per tutti. Inoltre, consentirà di risparmiare tempo per lo sviluppo futuro grazie ai miglioramenti in termini di sicurezza, prestazioni e supporto che si ottengono con gli aggiornamenti linguistici.

Per garantire che i nostri progetti e contenuti rimangano disponibili su Internet, sia oggi che in futuro, i nostri team dedicano una quantità significativa di sforzi per assicurare un'elevata disponibilità dei nostri siti e servizi. Un aspetto di questo lavoro si concentra sul ripristino in caso di eventi catastrofici o dolosi. Ad esempio, ci assicuriamo di avere backup di dati importanti e di essere in grado di recuperarli. Allo stesso modo, due volte all'anno verifichiamo la nostra capacità di passare da un sito all'altro dei nostri centri dati in modo automatizzato e risolviamo qualsiasi problema riscontrato. Un altro aspetto di questo lavoro si concentra sull'identificazione e sull'adattamento alle tendenze in evoluzione dei tipi e dei volumi di traffico che riceviamo. Ad esempio, con una crescita senza precedenti degli scrapers automatizzati, stiamo dando priorità al lavoro per garantire che i nostri siti e servizi rimangano accessibili agli utenti umani, adottando un approccio sistematico per stabilire norme sull'uso responsabile della nostra infrastruttura.

Non tutto il lavoro è pianificato con largo anticipo. Rispondiamo anche a eventi e incidenti emergenti inaspettati, come interruzioni del sito, segnalazioni o incidenti di sicurezza o attacchi vandalici su larga scala ai nostri progetti. Monitoriamo le nostre prestazioni e gli ostacoli alla raggiungibilità in tutto il mondo (compresi i problemi di connettività a Internet o i blocchi della censura) e indaghiamo su qualsiasi anomalia riscontrata. Alcuni di questi eventi inaspettati o il ripetersi di problemi fanno sì che il personale dia priorità a progetti di follow-up a breve termine che mirano a mitigare o a prevenire completamente ulteriori impatti negativi. Ad esempio, questo tipo di sforzi è stato fondamentale per consentire ai nostri progetti Wikimedia di resistere ai picchi di traffico globali dovuti a grandi eventi di cronaca (ad esempio, la morte di celebrità di alto profilo), grazie a una combinazione di ottimizzazione delle prestazioni, riprogettazione architettonica delle aree con colli di bottiglia e aumento della capacità. Allo stesso modo, i recenti miglioramenti apportati all'utilizzo dei nostri strumenti e sistemi di gestione del traffico ci hanno permesso di reagire in modo più rapido ed efficace ai cambiamenti delle condizioni. Questo tipo di lavoro di adattamento è parte integrante della nostra capacità di rispondere agli eventi emergenti, spesso in tempi brevi, e di garantire la disponibilità dei nostri progetti e contenuti.

Obiettivi di Product and Technology

Gli Obiettivi qui presentati sono in forma di bozza e sono aperti a commenti e discussioni.

Gli Obiettivi rappresentano una direzione di alto livello.
I " Risultati chiave" (Krs) rappresentano un metodo misurabile per monitorare l'andamento dei loro corrispettivi obiettivi.
Le "Ipotesi" sottostanti per ogni KR rappresentano il lavoro effettivo che stiamo svolgendo per cercare di raggiungere i risultati chiave associati. Saranno aggiornate in questo documento e nelle pagine wiki del progetto o del team in questione, man mano che si acquisiranno informazioni nel corso dell'anno.
$L'icona è per il lavoro a cui la Foundation sta dando priorità nell'ambito della Community Wishlist.

Esperienze Wiki (WE)

Esperienze dei contributori (WE1)

Obiettivo: I contributori aumentano perché ai volontari vengono offerte opportunità interessanti e comprendono il loro impatto. Discussione
- Contesto: questo obiettivo sarà la base per realizzare la nuova strategia per i contributori con i suoi 3 pilastri: 1) offrire ai volontari un modo centralizzato per organizzare la loro attività on-wiki, 2) fornire compiti più piccoli e discreti per creare maggiore chiarezza e aiutare i volontari a raggiungere il loro potenziale, e 3) rendere il contributo più significativo. Nell'anno fiscale 25/26 abbiamo in programma di fornire l'infrastruttura di base per aiutare i volontari a organizzare la loro attività on-wiki in modo centralizzato, iniziando con interventi specificatamente incentrati su editor e moderator esperti. Negli anni successivi aggiungeremo interventi per tutti i ruoli dei contributori e includeremo altri spazi problematici. In aggiunta, continueremo a investire in Edit Check e Structured Tasks, costruendo le basi per l'uso dell'IA in maniera modulare, sia come guida durante il processo di editing, sia come modo per indirizzare i volontari verso opportunità stimolanti. Infine, investiremo per rendere più visibile l'impatto dei volontari e creare un'esperienza più significativa per loro.
  - Risultato chiave WE1.1: Aumento del 4% [ii] della percentuale dei contributori con ≤100 modifiche cumulative che pubblicano modifiche costruttive sul web per dispositivi mobili [i], misurata tramite esperimenti controllati (entro la fine del secondo trimestre).
    - i. "Modifiche costruttive" = modifiche alle pagine in qualsiasi namespace principale di Wikipedia che non vengono ripristinate entro 48 ore dalla pubblicazione.
    - ii. T389403#10960480
    - I nuovi volontari faticano a iniziare a editare con successo. In particolare, le persone che utilizzano dispositivi mobili, dove lo spazio sullo schermo è limitato e l'attenzione è spesso frammentata.
    - Alcuni si stancano del contesto, della pazienza, e delle prove e degli errori necessari per contribuire in modo costruttivo. Altri non hanno ancora trovato un'opportunità convincente per provarci.
    - Il WE 1.1 affronterà questi problemi:
      - Segnalando i suggerimenti di modifica
      - Offrendo una guida operativa in fase di editing
      - Creando flussi di lavoro di editing più specifici per le attività
    - Al centro di questi sforzi c'è la necessità di trovare metodi graduali per individuare come migliorare le modifiche in corso e i contenuti esistenti. Per sviluppare questa capacità, continueremo a sperimentare l'apprendimento automatico per capire come possa essere di maggiore utilità ai contributori, indipendentemente dal loro ruolo e livello di esperienza.
    - Metodologia di valutazione KR proposta: per ciascuna piattaforma, calcoleremo la percentuale di interventi che abbiamo implementato e valutato attraverso esperimenti controllati che hanno raggiunto e/o superato l'obiettivo di modifica costruttiva che ci eravamo prefissati all'inizio di quest'anno. Vedi phab:T379285#10782051 per il ragionamento.
      - Nota: al 30 giugno 2025, WE 1.1 ha in programma due esperimenti controllati.
  - Risultato chiave WE1.2: aumento del numero di collaborazioni sui wiki del 55% su base annua entro la fine del quarto trimestre.
    - I contributori spesso faticano a trovare opportunità collaborare tra loro, soprattutto per quanto riguarda gli argomenti e i compiti che stanno loro a cuore. Questo può portare alla sensazione di essere soli sui wiki per i nuovi arrivati e può portare al burnout per gli editor più esperti. Inoltre, l'impatto delle attività di collaborazione è spesso poco chiaro, il che può portare a un minor numero di persone che desiderano unirsi, organizzare o sostenere la collaborazione sui wiki.
    - Vogliamo rendere più chiaro il valore della collaborazione facendo quanto segue:
    1. Creare nuovi modi per condividere l'impatto delle attività di collaborazione sui wiki
    2. Iniziare a raccogliere dati a livello di movimento sull'impatto delle attività di collaborazione
    3. Creare l'infrastruttura di base per tracciare i contributi collaborativi, in modo da poter fornire nuovi modi innovativi per riconoscere e premiare i contributi in futuro
    - Le collaborazioni saranno misurate in base alle nuove attività create tramite Event Registration nell'estensione CampaignEvents. L'obiettivo è che, entro la fine di questo KR, avremo un maggior numero di utilizzatori degli strumenti dell'estensione e nuovi modi di evidenziare l'impatto della collaborazione. Questo ci metterà in una buona condizione per collegare la nostra infrastruttura esistente ad altri modi di riconoscere e premiare il lavoro sui wiki (come il modulo di impatto, i ringraziamenti, ecc).
    - Area di interesse della wishlist: Community Wishlist/Aree di interesse/Unire i contributori
  - Risultato chiave WE1.3: entro la fine del terzo trimestre, il 10% dei contributori a cui è stata presentata una homepage dedicata ai nuovi moderatori l'ha visitata per due settimane consecutive.
    - Riteniamo di poter migliorare nel presentare opportunità di contributo ai volontari. A lungo termine, crediamo che una homepage possa essere utile a qualsiasi editore per organizzare il proprio lavoro, trovare nuove opportunità e comprenderne l'impatto. Il nostro obiettivo per l'anno fiscale 2025/2026 è quello di presentare nuove opportunità agli editori esperti affinché possano assumere compiti di moderazione a cui altrimenti non sarebbero stati necessariamente esposti.
    - Verificheremo questa teoria innanzitutto cercando di capire quanto gli editori esperti interagirebbero con una homepage simile a quella a cui hanno accesso i nuovi utenti.
    - Successivamente, presenteremo attività di moderazione specifiche (i dettagli sono ancora da definire) ai contributori che non hanno familiarità con questo tipo di azioni di moderazione, con l'obiettivo di aiutare a ridurre il carico di lavoro dei contributori esperti attraverso la riduzione degli arretrati (nell'ambito di un nuovo KR).
    - Se il concetto della homepage avrà successo, abbiamo in programma di rendere questa pagina modulare per soddisfare le esigenze delle comunità. Questi moduli potrebbero includere elementi come la possibilità per i contributori di comprendere più facilmente il loro impatto.
    - Note sulla metodologia:
    - Avremo un'ipotesi per definire il nostro target, che farà parte di WE1.3.1.
    - I “moderatori” seguiranno la definizione iniziata in Research:Develop a working definition for moderation activity and moderators, anche se sarà necessario un lavoro di follow-up per restringere la definizione quantitativa.
    - La seconda settimana sarà definita in base alla data della prima visita di ciascun utente. In questo caso, esamineremo tutti i nuovi moderatori che hanno visitato la homepage durante un determinato periodo di tempo e che poi hanno effettuato almeno un'altra visita (tra 7 a 14 giorni) in un secondo momento.
    - Area di interesse della Wishlist: Community Wishlist/Area di interesse/Priorità dei compiti
  - Risultato chiave WE1.4: migliorare la percentuale di visitatori unici che consultano gli osservati speciali e/o le modifiche recenti e che cliccano per visualizzare una modifica.
    - Il nostro obiettivo è di aiutare i contributori con oltre cento modifiche a trovare e aprire in modo più efficiente le modifiche relative ai loro interessi. Esploreremo l'area di focus per la prioritizzazione delle attività, realizzeremo i desideri in questo ambito e solleciteremo ulteriori feedback dai volontari su come migliorare queste interfacce. Possiamo misurare il successo migliorando l'efficacia di ciascuna pagina nel "trovare lavoro", definita dall'indicatore metrico dei tassi di clic.
  - Risultato chiave WE1.5: definire e rendere operative sette metriche ad alta priorità [1] necessarie per monitorare i progressi verso il raggiungimento degli obiettivi delineati nella strategia dei contributori entro la fine del quarto trimestre, creando un dashboard e rendendo operative le metriche mensili relative ai moderatori attivi.
    [1] Contributori fidelizzati, attivazione costruttiva, modifiche costruttive, registrazioni di account di nuovi utenti fidelizzati, contributori attivi per anzianità, contributori attivi per livello di esperienza.
    - La strategia relativa all'esperienza dei contributori prevede un impegno di 3-5 anni volto a “stimolare la crescita del volontariato” e ad “aumentare la fidelizzazione e l'attivazione” dei contributori nuovi ed esistenti attraverso tre principali aree di attività:
    1. Semplificare il modo in cui i volontari possono ricevere raccomandazioni, gestire i propri compiti e interessi, vedere cosa succede sui wiki e comprendere il proprio impatto
    2. Offrire compiti strutturati in modo adeguato per creare maggiore chiarezza e aiutare i volontari a realizzare il loro potenziale ottimizzando i flussi di lavoro che assegniamo loro, compreso un investimento continuo nella fornitura di una guida strutturata e nell'automazione delle attività ripetitive, con un'attenzione particolare all'esperienza web mobile
    3. Rendere significativo il contributo mostrando ai volontari il loro impatto e investendo in opportunità di connessione umana e in un ambiente basato sul feedback positivo
    - Un progetto di strategia di misurazione ha quindi delineato una vasta rete di metriche per monitorare questa teoria del cambiamento. Ha concluso che la misura primaria del successo (“metrica di base”) dovrebbe essere il numero di contributori fidelizzati, integrato da metriche più specifiche come l'attivazione costruttiva e l'intenzione dei contributori di tornare, e da metriche “a valle” più ampie come i contributori attivi e la qualità dei contenuti. Dobbiamo assicurarci che queste metriche siano operative e visibili in un dashboard, in modo da poter monitorare i nostri progressi verso la realizzazione della strategia.
  - Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
    - Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
  - Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
    [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
    Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
    - 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
    - WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
  - Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
    - Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
    - This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
    - We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
  - Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
    - Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
    - Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
    - Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
  - Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
    - The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

Conoscenze essenziali (WE2)

Obiettivo: rendere disponibile e ben illustrate più conoscenze essenziali nelle diverse lingue e argomenti. Discussione
- Contesto dell'obiettivo: questo obiettivo promuoverà una crescita dei contenuti che risponda sia agli interessi dei contributori in particolare per argomenti e lingue, sia alla domanda dei lettori di conoscenze essenziali ben illustrate. La conoscenza essenziale è un insieme di articoli che offre l'ampiezza e la profondità degli argomenti necessari per un progetto linguistico di Wikipedia utilizzabile. È definita dalle comunità con riferimento alla notorietà, alla rilevanza, alle previsioni di lettura e alle connessioni tra gli articoli.
- Adotteremo un approccio socio-tecnico, migliorando l'efficacia delle funzioni, degli strumenti, e dei processi sociali. Ci baseremo su funzionalità di prodotto ad alto impatto come i compiti suggeriti, la ricerca dei media e la traduzione dei contenuti, ma faciliteremo anche l'inserimento e lo sviluppo di piccole Wikipedie linguistiche. Supporteremo gli organizzatori Wikimedia che reclutano, formano e supportano i contributori a lavorare su obiettivi di contenuto condivisi attraverso configurazioni collaborative come WikiProjects e campagne. (Stimiamo che siano attivi almeno 300 organizzatori.) Svilupperemo anche relazioni con gli editor più importanti per rimuovere le barriere ai materiali di partenza. (Attualmente abbiamo partnership con più di 100 dei principali database con abbonamento al mondo.)
- Per assicurarci che i nostri interventi abbiamo un impatto positive sulla conoscenza essenziale, misureremo sia l'aumento dei contenuti prioritari per la comunità sia la qualità di tali contenuti, esaminando fattori come i tassi di reversione e il numero di citazioni e immagini.
  - Risultato chiave WE2.1: Entro la fine del secondo trimestre, sperimentare e valutare tre interventi che aiutino i contributori a migliorare lo stato dei contenuti essenziali sulle loro Wikipedie.
    - Questo KR metterà in evidenza le lacune di contenuto all'interno dei meccanismi di editing, come la scoperta di immagini su Wikipedia, la traduzione di contenuti, e la creazione guidata di nuovi articoli. Verrà inoltre implementato e testato un intervento socio-tecnico per supportare l'attività di creazione dei contenuti per le piccole comunità linguistiche. L'andamento verrà misurato nell'ambito di ciascuna ipotesi.
  - Risultato chiave WE2.2: entro la fine del quarto trimestre, sviluppare le funzionalità delle piattaforme necessarie per verificare che siamo in grado di supportare la visione di Abstract Wikipedia su larga scala. Sapremo di aver raggiunto il nostro obiettivo se il sistema sarà in grado di fornire contenuti enciclopedici ricchi e multilingue utilizzando Wikidata e la generazione di un linguaggio naturale, se sarà controllato dalla comunità Wikimedia e se manterrà le sue prestazioni anche in caso di implementazioni su larga scala.
    - Ora che possiamo utilizzare Wikidata per produrre contenuti di base in formato testo semplice su Wikipedia, il passo successivo è continuare a sviluppare le funzionalità della piattaforma in grado di supportare Abstract Wikipedia su larga scala. La piattaforma dovrà supportare contenuti ricchi e multilingue che possano essere controllati dalla comunità e mantenere le prestazioni su larga scala. Si tratta di un traguardo fondamentale, poiché stiamo passando da 0 a 1.
  - Risultato chiave WE2.3: entro la fine del quarto trimestre, implementare una versione iniziale del nuovo wiki per la creazione iniziale di articoli Abstract da parte della comunità.
    - Questo risultato chiave ci prepara a testare le capacità della piattaforma di un wiki Abstract il prossimo anno. Il nuovo wiki autonomo ospiterà la libreria di articoli astratti costruita su Wikifunctions e fornirà le capacità della piattaforma necessarie per integrare in futuro gli articoli astratti in Wikipedia.
  - Risultato chiave WE2.4: Allineare WMF e WMDE sulla definizione di successo per i miglioramenti all'infrastruttura tecnica a supporto di un caso d'uso critico di Wikidata entro la fine del secondo trimestre, comprese le metriche e gli obiettivi per l'anno fiscale 2025-2026.
    - Il team della piattaforma Wikidata (WDP) della WMF è stato costituito e dotato di personale - un responsabile di prodotto e un responsabile tecnico - nell'agosto 2025. Come nuova aggiunta a un programma sviluppato nel corso di anni dai responsabili tecnici e di prodotto rispettivamente di WMF e WMDE, questo obiettivo riflette la nostra intenzione di trasferire la proprietà attraverso l'allineamento dei casi d'uso, delle dipendenze e dei criteri chiave di successo. Questo KR getterà le basi per una comprensione reciproca del problema, su cui lavoreremo per il resto dell'anno fiscale (maggio 2026).
  - Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
    - Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

Esperienze del consumatore (WE3)

Obiettivo: I lettori di più generazioni si impegnano, e rimangono coinvolti, con Wikipedia, con un conseguente aumento misurabile della fidelizzazione e delle attività di donazione. Discussione
- Contesto dell'obiettivo: questo obiettivo si concentrerà sulla fidelizzazione dei nuovi lettori attraverso formati di contenuto innovativi, invece, del pubblico di base attraverso il rafforzamento delle esperienze di lettura familiari e sulla garanzia di sostenibilità a lungo termine attraverso l'approfondimento dei legami con i lettori e la diversificazione delle donazioni. Comprenderà la continuazione del nostro lavoro per rendere i contenuti più facili da scoprire attraverso nuove e più sperimentali funzioni, come i riassunti dell'IA o i rabbit hole personalizzati. Includerà anche il lavoro per mantenere e migliorare la qualità dell'esperienza di lettura più in profondità nell'imbuto di lettura e l'esplorazione della cura della lettura attraverso liste di lettura e altre partecipazioni non editoriali. Per i donatori, questo lavoro continuerà a concentrarsi sulla diversificazione delle fonti di reddito all'interno della piattaforma.
  - Risultato chiave WE3.1: Entro la fine del secondo trimestre, dimostrare un aumento praticamente significativo della fidelizzazione dei lettori disconnessi, misurato attraverso test A/B di una funzione per piattaforma
    - Questo RK si concentrerà sul continuare a investire in esperienze che ottimizzano i nuovi modi di navigare e apprendere i contenuti, spesso attraverso l'uso di nuove tecnologie e formati, presentando i contenuti esistenti in modi nuovi e coinvolgenti. In questo anno fiscale, vorremmo continuare a sperimentare con nuove funzionalità, concentrandoci allo stesso tempo sulla scalabilità degli esperimenti di successo tra i wiki e le piattaforme. Il lavoro nel KR si estenderà al sito web per dispositivi mobili e desktop, nonché alle app per iOS e Android e si concentrerà sulla scoperta dei contenuti (punti di ingresso e raccomandazioni per la navigazione) e sui formati di apprendimento adattabili (riassunti assistiti dalla macchina, remix dei contenuti).
    - Area di interesse della wishlist: Nuove esperienze del consumatore
  - Risultato chiave WE3.2: Aumentare il numero di donazioni attraverso metodi diversi da banner o e-mail del 5% per piattaforma su base annua attraverso interventi sui prodotti che favoriscono connessioni più profonde e riducono l'attrito per i donatori entro la fine del secondo trimestre
    - Questo KR ci vedrà continuare a esplorare nuovi punti di ingresso per le donazioni e altre opportunità per convertire i lettori in donatori e fidelizzarli approfondendo i loro legami con i wiki, compresi contenuti più personalizzati. Il KR si concentrerà sull'introduzione di nuovi punti di accesso e sull'iterazione di quelli esistenti su app e web, in collaborazione con il team di raccolta fondi
  - Risultato chiave WE3.3: Entro la fine del secondo trimestre, dimostrare un aumento praticamente significativo della fidelizzazione dei lettori connessi, misurato attraverso test A/B di una funzionalità per piattaforma
    - Questo KR si concentrerà sul migliorare l'esperienza di lettura e apprendimento per i lettori esistenti ed esperti, con l'obiettivo di fidelizzare il nostro pubblico attuale e approfondire il loro legame con il sito in modo che possano imparare di più, oltre ad essere pronti e aperti a intraprendere percorsi verso la donazione e l'editing. Il lavoro si concentrerà sul miglioramento dell'esperienza di lettura sul web e sulle app (miglioramenti della leggibilità, migliore navigazione e scoperta), nonché sulla creazione e l'iterazione delle nostre offerte di cura e personalizzazione (elenchi di lettura, suggerimenti personalizzati, cronologia degli utenti e degli articoli, ecc)
  - Risultato chiave WE3.4: entro la fine del quarto trimestre, rimuovere tutti gli ostacoli identificati per le implementazioni di siti cache su piccola scala (PoP) che soddisfano i nostri attuali standard di qualità del servizio e di sicurezza, in linea con le nostre attuali implementazioni di siti cache.
    - Questo KR si concentrerà sulla dimostrazione del concetto che possiamo migliorare le prestazioni dei siti web e ridurre la latenza per i nostri lettori semplificando la nostra infrastruttura di caching e migliorando i processi per l'implementazione di un sito di caching, riducendo il tempo di implementazione di base da circa un anno in media a un trimestre al massimo. L'obiettivo sarà quello di completare la semplificazione, implementare un PoC, condurre una revisione della sicurezza e completare un documento decisionale sull'opportunità di procedere con l'implementazione delle nostre cache edge nei cloud pubblici. La riduzione della latenza può portare a un aumento comprovato delle pagine visitate e a una base di lettori più diversificata dal punto di vista geografico.
  - Risultato chiave WE3.5: Migliorare l'identificazione dei donatori - garantendo che tutti i lettori consenzienti che hanno effettuato il login possano essere identificati in base allo stato di donatore per un'esperienza personalizzata - entro la fine del quarto trimestre.
    - Implementeremo strategie di identificazione dei donatori per garantire che tutti i lettori che hanno effettuato il login possano essere identificati in base allo stato di donatore, consentendo un'esperienza più personalizzata e coinvolgente. Gli sforzi per l'identificazione dei donatori saranno prioritari durante il quarto semestre per sostenere iniziative di personalizzazione e attivazione più efficaci in futuro.
  - Risultato chiave WE3.6: Finalizzare, pubblicare e comunicare una strategia per l'esperienza dei lettori e dei consumatori di Wikipedia su tutte le piattaforme entro la fine del quarto trimestre, con obiettivi definiti e metriche di riferimento, sviluppate in collaborazione con gli stakeholder e la comunità, per guidare il nostro lavoro fino al 2030.
    - Il lavoro sulla strategia per i consumatori proseguirà, concentrandosi sulla costruzione e sulla comunicazione della strategia all'interno dell'azienda e con la comunità e definendo e stabilendo le metriche fondamentali per i consumatori e i rispettivi parametri di riferimento.
  - Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
    - This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
  - Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
    - This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
  - Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
    - In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
  - Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
    - We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

Sicurezza e Protezione (WE4)

Obiettivo: i nostri sistemi proteggono meglio gli account e le informazioni private dei nostri redattori per impostazione predefinita, offrendo al contempo maggiori possibilità ai contributori e agli utenti con diritti estesi di prevenire e rispondere alle attività abusive. Discussione
Risultato chiave WE4.1: Implementare un sistema di segnalazione degli incidenti valido e funzionante in tutti i nostri wiki, che sia utilizzato e accettato dalle loro comunità, entro la fine del secondo trimestre.
- Garantire la sicurezza e il benessere degli utenti è una responsabilità fondamentale della nostra piattaforma. In molte giurisdizioni esistono normative che impongono alle piattaforme online come la nostra di monitorare e prendere provvedimenti contro le molestie, il cyberbullismo e altri contenuti dannosi presenti sulla loro piattaforma. Il mancato intervento può esporre le piattaforme a responsabilità legali e sanzioni normative.
- Vogliamo dare ai nostri utenti la possibilità di segnalare minacce immediate per la sicurezza attraverso un meccanismo di segnalazione facilmente individuabile e intuitivo, per assicurarci di essere in grado di venire a conoscenza di tali incidenti e di intervenire tempestivamente, se necessario. Si tratta di un passo avanti per far sentire i nostri utenti al sicuro quando contribuiscono alla nostra piattaforma. Lo stiamo facendo implementando un Incident Reporting System sui nostri wiki.
Risultato chiave WE4.2: rafforzare la precisione e l'efficacia degli strumenti anti-abuso, implementando 2 miglioramenti entro la fine del secondo trimestre.
- Noi e la nostra comunità dobbiamo individuare e prevenire meglio le attività non autentiche e dannose sui wiki. Lo faremo aumentando il numero e la qualità dei segnali disponibili per la piattaforma, combinando questi segnali in strumenti che mettiamo a disposizione degli utenti con diritti estesi e identificando i casi in cui possiamo applicare restrizioni automatiche alle attività sospette.
- Vediamo anche l'opportunità di migliorare l'accessibilità di Wikipedia e dei nostri altri progetti allo stesso tempo. Ad esempio, un progetto prevede di sostituire il convenzionale CAPTCHA autogestito di Wikipedia, che impedisce all'utente di accedere fino a quando non risolve un rompicapo, con un servizio di valutazione del rischio che raramente mette in discussione l'utente. Al contrario, il servizio etichetterebbe silenziosamente gli account con un livello di sospetto che possiamo usare per disabilitare le funzionalità, e renderebbe visibile questo stato ai moderatori altamente privilegiati per aiutarli nel loro lavoro.
- Più in generale, i progetti Wikimedia fanno molto affidamento sul blocco degli indirizzi IP per mitigare gli abusi da parte di malintenzionati. Questo metodo è sempre più inefficace nel bloccare gli abusi e ha un impatto negativo sugli utenti in buona fede che sono colpiti dai blocchi degli IP e degli intervalli di IP. In questo KR, ci proponiamo di migliorare le capacità esistenti e di fornire nuovi strumenti che consentano di bloccare in modo più preciso ed efficace i malintenzionati e di ridurre i danni collaterali causati dai blocchi degli IP e degli intervalli di IP.
- Per misurare la nostra efficacia, esamineremo il feedback qualitativo dei volontari impegnati nel lavoro antiabuso e indicatori quantitativi come il tasso di blocchi IP distribuiti, l'adozione della reputazione IP e delle mitigazioni basate sui segnali del browser, il tasso di interazioni probabilmente umane quando un utente viene bloccato e l'adozione di nuovi segnali negli strumenti antiabuso.
- Il lavoro in questo KR comprende il miglioramento del rilevamento e della mitigazione dell'evasione dei sockpuppet e dei ban, l'emersione di informazioni sul potenziale di danni collaterali, il rafforzamento del rilevamento dei bot, l'emersione di segnali per i volontari antiabuso, il miglioramento dell'efficienza delle interfacce degli strumenti antiabuso, il miglioramento delle metriche relative all'abuso e la fornitura di suggerimenti di attività di account sospette da indagare ai CheckUser.
Risultato chiave WE4.3: Ridurre il numero di attacchi a larga scala che richiedono l'intervento umano SRE del 50% (confronto anno fiscale su anno fiscale), entro la fine del quarto semestre
- L'evoluzione del mondo di Internet, compresa l'ascesa di botnet su larga scala e di attacchi sempre più frequenti, ha reso obsoleti i nostri metodi tradizionali per limitare gli abusi su larga scala. Tali attacchi possono rendere i nostri siti non disponibili, inondando la nostra infrastruttura di richieste, o sovraccaricare la capacità della nostra comunità di combattere il vandalismo su larga scala. Ciò mette a dura prova anche i nostri editor di alto livello e la nostra comunità tecnica.
- Abbiamo bisogno urgentemente di migliorare la nostra capacità di rilevare automaticamente, resistere e mitigare o fermare tali attacchi.
- Quest'anno ci concentreremo soprattutto sull'automatizzazione del rilevamento degli indirizzi IP e delle reti che si impegnano regolarmente in attacchi contro di noi e sulla riduzione del carico che queste entità persistentemente dannose possono esercitare sui nostri sistemi.
Risultato chiave WE4.4: Distribuire account temporanei al 100% dei nostri progetti, in modo che l'esposizione delle informazioni di identificazione personale dei nostri redattori non registrati sia disponibile per meno dello 0,1% degli utenti, entro la fine del secondo trimestre.
- Gli account temporanei mirano a migliorare la privacy e quindi la sicurezza dei nostri editor non registrati, proteggendo le loro informazioni di identificazione personale (indirizzo IP) dalla vista pubblica e limitando l'accesso solo a coloro che ne hanno bisogno per scopi di patrolling. Oltre a rappresentare un importante miglioramento per la sicurezza degli utenti, questo progetto è anche importante per soddisfare vari requisiti normativi.
Risultato chiave WE4.5: Valutare l'impatto dell'IA generativa sulla fiducia e sulla sicurezza e determinare interventi sui prodotti per sfruttare le opportunità e prevenire le minacce per i progetti Wikimedia, entro la fine del terzo trimestre.
- L'utilizzo dell'IA, e in particolare dell'IA generativa, è in rapido aumento su Internet. Con la diffusione dell'IA, emergono opportunità di fiducia e sicurezza, ma anche minacce. Ad esempio, generare contenuti è più facile ed economico, ma la moderazione è più faticosa. Allo stesso modo, la ricerca può essere condotta con molto meno sforzo, ma le allucinazioni dell'IA sono più difficili da identificare.
- Questo progetto mira a sviluppare la Valutazione dell'Impatto sui Diritti Umani di ML/AI, valutando l'impatto dell'IA sugli aspetti di fiducia e sicurezza dell'ecosistema di Wikimedia. Questo include:
  - Consultare gli utenti con diritti estesi.
  - Identificare esempi di abuso generativo assistito dall'IA e potenziali mitigazioni.
  - Identificare le opportunità di ML per ridurre il peso sugli utenti con diritti estesi.
  - Esecuzione di esperimenti per capire su cosa concentrarsi per ottenere il massimo impatto.
Risultato chiave WE4.6: Imporre tecnicamente che il 100% dei privilegi che consentono agli utenti di intraprendere azioni sensibili alla sicurezza o alla privacy possano essere eseguiti solo da account che hanno abilitato l'autenticazione a due fattori, entro la fine del quarto trimestre.
- Dobbiamo rafforzare la sicurezza degli account utente sulle nostre wiki, in particolare per gli utenti con autorizzazioni sensibili. Un punto chiave è la richiesta che qualsiasi azione sensibile possa essere eseguita solo da utenti che hanno attivato l'autenticazione a due fattori (2FA). Costruiremo un sistema più estensibile per l'applicazione dei privilegi che eviterà la necessità di verifiche e l'applicazione manuale della 2FA e amplierà i privilegi che richiedono l'abilitazione della 2FA sulla piattaforma.
- A tal fine, miglioreremo i nostri sistemi di autenticazione e recupero in modo che noi (WMF) e i nostri utenti possiamo supportare più facilmente una posizione più rigorosa nei confronti della 2FA. Espanderemo la disponibilità generale dell'autenticazione a due fattori in tutta la piattaforma, in modo che ogni utente possa abilitarla come desidera e per garantire che sia abilitata prima che vengano concessi privilegi sensibili. Ci concentreremo inoltre sulla riduzione del carico operativo sostenuto dai nostri sistemi di recupero e assistenza degli account, contribuendo a snellire i processi di ripristino e recupero relativi all'accesso agli account. Intendiamo inoltre migliorare l'usabilità della nostra implementazione 2FA, offrendo agli utenti più opzioni per proteggere i loro account ed evitare il blocco accidentale.
Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
- This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
- The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
  We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
- For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
- In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
- We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
- This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
- During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
- We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
- In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
- We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

Uso Responsabile delle Infrastrutture (WE5)

Obiettivo: Sviluppatori e riutilizzatori accedono ai contenuti della conoscenza in percorsi curati, garantendo la sostenibilità della nostra infrastruttura e il riutilizzo responsabile dei contenuti. Discussione
- Contesto dell'obiettivo: questo obiettivo si concentrerà sulla creazione di percorsi per il riutilizzo responsabile dei contenuti.
- Wikimedia ospita la più grande raccolta di conoscenze curate dall'uomo sul web. Questo ha reso la nostra infrastruttura di conoscenza una destinazione preziosa non solo per gli esseri umani, ma anche per i consumatori automatici di dati. I nostri contenuti alimentano i motori di ricerca, le piattaforme di social media, l'e-commerce e, da quando è nata l' IA, vengono utilizzati per addestrare grandi modelli di apprendimento automatico. I consumatori si procurano i dati tramite scraping delle pagine, utilizzando le API e scaricando i contenuti, in genere senza attribuzione. Nel mondo del traffico non autenticato non possiamo distinguere in modo affidabile un utente dall'altro, il che limita notevolmente la nostra capacità di consentire e imporre un uso responsabile della nostra infrastruttura: Come possiamo continuare a rendere possibile la nostra comunità, ponendo al contempo dei limiti al consumo automatico di contenuti? Come possiamo indirizzare gli utenti verso i canali preferiti e supportati? Di quali indicazioni abbiamo bisogno per incentivare il riutilizzo responsabile dei contenuti? Come possiamo favorire un'esperienza coesa per gli sviluppatori e costruire prodotti che soddisfino le esigenze degli sviluppatori volontari, del personale e dei riutilizzatori? Sebbene queste domande non siano del tutto nuove, l'urgenza di affrontarle è cresciuta in modo esponenziale: Dal 2024 stiamo osservando un aumento vertiginoso del volume delle richieste, la maggior parte delle quali proviene da bot di scraping che raccolgono dati di formazione per flussi di lavoro e prodotti basati sull'IA. Il carico sulle nostre infrastrutture non è sostenibile e mette a rischio l'accesso umano alla conoscenza: Dobbiamo agire subito per ristabilire un sano equilibrio, in modo da poter sostenere efficacemente i progetti Wikimedia e consentire il successo duraturo della nostra missione.
  - Risultato chiave WE5.1: Entro la fine del quarto trimestre, il 50% delle richieste ai canali di accesso programmatico potrà essere attribuito a uno sviluppatore o a un'applicazione noti.
    - Attualmente abbiamo pochi modi per identificare i responsabili del traffico automatizzato e, a differenza di quanto avviene su Wiki, pochi modi per contattare gli utenti o regolare il loro accesso. Abbiamo assistito a un aumento significativo del volume del traffico automatizzato esterno, che per noi non è sostenibile e mette a rischio l'accesso umano alla conoscenza. Il nostro obiettivo è aumentare la percentuale di traffico automatizzato attribuito a un account noto, richiedendo l'autenticazione e l'autorizzazione in base a livelli di accesso graduali per lo scraping e l'uso delle API ad alto volume. Questo ci aiuterà a identificare chi sta riutilizzando i contenuti su scala, permettendoci di proteggere la nostra infrastruttura e di migliorare la governance sull'uso corretto, soddisfacendo al contempo in modo più efficace le loro esigenze. Inoltre, valuteremo come supportare meglio la comunità tecnica con un'esperienza più coesa per gli sviluppatori, che protegga l'accesso preferenziale per i membri della comunità e consenta nuove funzionalità per gli sviluppatori.
  - Risultato chiave WE5.2: Entro la fine del quarto trimestre, il 70% degli endpoint delle API web di Wikimedia sarà supportato da un'infrastruttura comune.
    - Il nostro obiettivo è migliorare l'esperienza e la sostenibilità dei nostri percorsi per gli sviluppatori, offrendo API web più coerenti, stabili e scopribili per tutti gli sviluppatori di Wikimedia. Semplificheremo la nostra offerta di API introducendo un'infrastruttura più centralizzata per le funzionalità API di base, consentendoci di avere percorsi e governance coerenti per: le specifiche e la documentazione OpenAPI, l'identificazione degli sviluppatori e i controlli di accesso, l'applicazione delle politiche API, il routing, il versioning e la gestione degli errori. Semplificando le nostre offerte di API, renderemo più veloce, più facile e più piacevole la creazione di strumenti, bot, progetti di ricerca e funzionalità che servano la missione di Wikimedia. Questo approccio sostiene il futuro multigenerazionale della missione riducendo i costi di manutenzione dell'infrastruttura API, aumentando la visibilità e il controllo degli accessi per combattere i malintenzionati e promuovendo una comunità di sviluppatori più forte.
  - Risultato chiave WE5.3: Entro la fine del quarto trimestre, verrà pubblicato un nuovo quadro di attribuzione per il web, le app, gli assistenti vocali e gli LLM, che sarà collegato a tutti i siti Wikimedia, con due demo di riutilizzo che stimolano un coinvolgimento misurabile e un partner di riutilizzo esterno che adotta le migliori pratiche di attribuzione.
    - Per aumentare la corretta attribuzione dei contenuti Wikimedia, forniremo chiare linee guida sulle migliori pratiche che promuovono un riutilizzo responsabile. Ciò include la creazione di un quadro di riferimento per l'attribuzione per le piattaforme chiave (web, app, voce, multimedia) e la presentazione di almeno due esempi pratici che evidenziano applicazioni esemplari dei contenuti Wikimedia. Esempi di risultati includono l'incoraggiamento alle organizzazioni mediatiche a citare le immagini di Wikimedia Commons, ai motori di ricerca a rendere più efficaci i dati Wikimedia rilevanti, o agli assistenti IA a integrare le conoscenze di Wikipedia in modo trasparente e responsabile, aumentando la fiducia nella loro affidabilità. Il rafforzamento delle pratiche di attribuzione non solo aumenta la consapevolezza del pubblico e stimola il coinvolgimento nei progetti Wikimedia, ma contribuisce anche a stabilire modi responsabili e innovativi di rielaborare le conoscenze e a scoraggiare gli abusi.
  - Risultato chiave WE5.4: Ridurre la quantità di traffico generato dagli scraper del 20% se misurato in termini di tasso di richiesta e del 30% in termini di larghezza di banda
    - Lo scraping c'è sempre stato: i motori di ricerca si sono affidati a Wikipedia per fornire informazioni ai loro utenti per decenni; tuttavia, ultimamente c'è un'altra grande motivazione per lo scraping dei nostri dati: è il più grande insieme di contenuti di conoscenza curati e multilingue che si possa trovare su Internet ed è uno strumento fondamentale per addestrare modelli linguistici di grandi dimensioni. Questo vale sia per i nostri contenuti enciclopedici sia per il nostro archivio multimediale, Wikimedia Commons, che è prezioso per i modelli di apprendimento automatico che generano immagini.
    - Di conseguenza, nell'ultimo anno abbiamo assistito a un aumento significativo del traffico di scraper e dei relativi incidenti di stabilità del sito: Gli ingegneri dell'affidabilità del sito hanno dovuto imporre caso per caso la limitazione o il divieto dei crawler per proteggere la nostra infrastruttura. Lo scraping è diventato così importante che la nostra larghezza di banda in uscita è aumentata del 50% nel 2024. Inoltre, una recente analisi ha dimostrato che almeno il 65% delle nostre richieste più costose (quelle che non possiamo servire dai nostri server di caching e che vengono invece servite dai database principali) sono eseguite da bot.
    - Le nostre risorse informatiche sono estremamente limitate rispetto alla quantità di traffico che generiamo, quindi dobbiamo stabilire una priorità per chi serviamo con quelle risorse, e vogliamo privilegiare il consumo umano e dare la priorità al sostegno dei progetti e dei collaboratori di Wikimedia con le nostre scarse risorse.

Accelerare il Percorso verso i Risultati dei Prodotti (WE6)

Obiettivo: gli sviluppatori di Wikimedia portano rapidamente e con fiducia i loro prodotti agli utenti finali. Discussione
- Contesto dell'obiettivo: per essere efficaci nel raggiungimento dei 4 pilastri strategici, gli sviluppatori di Wikimedia devono dedicare il loro tempo e il loro impegno ad attività ad alta leva che portino alla consegna di prodotti di qualità il prima possibile. I flussi di lavoro troppo complicati, la mancanza di strumenti standard e i componenti di sistema non sostenibili ostacolano questi risultati.
- Questo lavoro si basa sullo slancio che abbiamo raccolto negli ultimi due piani annuali per far evolvere MediaWiki come piattaforma e il software che ne supporta lo sviluppo e la distribuzione. Il lavoro di quest'anno si concentrerà sulla fornitura di ambienti di sviluppo più affidabili, sulla semplificazione dei flussi di lavoro di pre-produzione e sulla riduzione dei rischi della piattaforma e dell'infrastruttura.
  - Risultato chiave WE6.1: Entro la fine del quarto trimestre, il numero di train-blocking bug che vanno oltre i wiki di prova si riduce del 10%
    - Nel 2024, ci sono stati 144 casi in cui gli sviluppatori hanno dovuto rivedere il lavoro perché c'era un'emergenza che impediva la distribuzione di MediaWiki. In molti di questi casi, i bug sono stati individuati dopo la distribuzione su testwiki, il che significa che il problema ha raggiunto un pubblico potenziale di miliardi di utenti. Non possiamo controllare il fatto che i bug esistano, ma individuarli prima significherebbe ridurre il lavoro degli esperti. Inoltre, gli sviluppatori si fiderebbero del fatto che, quando qualcosa verrà messo in produzione, non ci sarà un problema.
    - Potremo intercettare questi bug prima fornendo gli spazi necessari agli sviluppatori per consegnare e testare con sicurezza il loro codice durante tutto il ciclo di vita dello sviluppo e della distribuzione. Dobbiamo anche assicurarci che questi miglioramenti non vadano a discapito della velocità degli sviluppatori.
  - Risultato chiave WE6.2: Entro la fine del quarto trimestre, 4 fasi della lista di controllo della preparazione alla produzione possono essere eseguite senza l'intervento di SRE
    - L'implementazione di un nuovo servizio o di una nuova funzionalità in produzione dipende attualmente da un elenco di 24 fasi, ognuna delle quali richiede in genere il supporto degli SRE. Abbiamo istituito il programma SRE ambassador per intervenire nelle prime fasi del ciclo di sviluppo e creare capacità all'interno dei team di sviluppo stessi, ma molti dei compiti dovrebbero essere completamente autosostenibili. Attualmente, si tratta di un lavoro manuale, ripetitivo, automatizzabile e che scala linearmente con il numero di team di sviluppo. Questo non è sostenibile per il team SRE nel lungo periodo.
    - In passato, gran parte di questo lavoro era sottratto ai team di sviluppo grazie al mantenimento di una serie di librerie comuni e di best practice condivise per interagire con la nostra piattaforma. Queste sono state abbandonate quando siamo passati alla nuova infrastruttura Kubernetes e non hanno un sostituto diretto. Fornendo librerie simili, documentazione e formazione che si applicano al modo in cui costruiamo e distribuiamo le cose oggi, crediamo di poter ridurre la quantità di coinvolgimento necessario da parte di SRE prima di distribuire un nuovo servizio o una nuova funzionalità in produzione.
  - Risultato chiave WE6.3: Entro la fine del quarto trimestre, il 100% il 100% delle pagine viste di Wikipedia sono servite attraverso Parsoid
    - Parsoid offre funzionalità avanzate per l'evoluzione del wikitext e per la sicurezza futura della piattaforma. Mantenere due parser contemporaneamente non è sostenibile a lungo termine, perché aumenta il debito tecnico e la complessità. Inoltre, il successo di alcuni nuovi progetti come Wikifunctions dipende dalla disponibilità di Parsoid.
    - Abbiamo iniziato a scalare il rollout su progetti più piccoli e quest'anno saremo pronti per le Wikipedie. Il servizio di lettura di tutte le pagine di Wikipedia attraverso Parsoid è la prossima pietra miliare più importante. Oltre al lancio in sé, questo lavoro include anche la risoluzione di problemi di prestazioni e una comunicazione efficace dell'impatto sui lettori e sugli editor.
  - Risultato chiave WE6.4: Entro la fine del secondo trimestre, almeno due rischi identificati che minacciano la nostra capacità di continuare a distribuire o scalare i wiki sono stati mitigati o ridotti a un livello accettabile
    - Attraverso alcune iniziative mirate, ridurremo o attenueremo diversi rischi di scalabilità, affidabilità o sicurezza che abbiamo identificato come una probabile minaccia potenziale alla crescita e alla sostenibilità della nostra piattaforma e dei nostri progetti pubblici.
    - Per esempio, rifattorizzeremo la struttura dei database principali di Commons per garantire che la sua crescita non sia limitata dalla capacità dell'hardware dei server disponibili nei prossimi anni. Inoltre, aggiorneremo PHP, il linguaggio di programmazione che alimenta MediaWiki e i servizi correlati, a una versione più moderna. Altri rischi identificati richiederanno probabilmente l'implementazione di ulteriori misure di sicurezza per proteggere e rendere più solida la nostra infrastruttura.
  - Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
    - One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
    - Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
    - With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
    - Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
  - Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
    - Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
    - To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
    - By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
  - Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
    - Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

Servizi di segnali e dati (SDS)

Metriche (SDS1)

Obiettivo: I decisori utilizzano metriche più affidabili e tempestive per informare le decisioni strategiche e di prodotto. Discussione
- Contesto oggettivo: Usiamo le metriche per informare le decisioni della Foundation su dove concentrare i nostri sforzi per servire al meglio il Movimento. Tuttavia, alcune delle nostre pipeline di dati sono inclini a rompersi, causando ritardi nella consegna. Quando emergono problemi con i dati, i tempi di identificazione e di risoluzione sono troppo elevati. Inoltre, molti dei nostri set di dati non sono ottimizzati per una facile esplorazione delle tendenze e mancano di dimensioni che sono emerse come importanti per l'interpretazione dei dati. Questi problemi rallentano e limitano la nostra capacità di valutare le metriche.
- Nell'anno fiscale 25-26, ci concentreremo su casi d'uso specifici del piano annuale per risolvere le lacune nella qualità dei dati delle nostre attuali pipeline, istituire infrastrutture e processi per il monitoraggio e la risoluzione dei problemi di qualità dei dati e fornire strumenti che consentano ai decisori di comprendere le tendenze.
- Un caso d'uso riguarda il modo in cui misuriamo il traffico umano e quello dei bot. L'aumento del traffico automatizzato negli ultimi due anni ha reso più difficile capire in che misura gli esseri umani interagiscono e contribuiscono ai progetti Wikimedia. Il nostro obiettivo è migliorare la nostra capacità di valutare i modelli di traffico umano e bot, che sono elementi critici per la pianificazione e le decisioni sui prodotti.
  - Risultato chiave SDS1.1: Entro la fine del primo trimestre, gli analisti che utilizzano le metriche relative alle visualizzazioni di pagina avranno accesso a misure di riferimento relative alla qualità dei dati e a misure delle prestazioni degli euristici di rilevamento automatico del traffico.
    - Attraverso le ipotesi esplorate in questo KR, ci proponiamo di identificare le lacune delle nostre attuali euristiche di rilevamento automatico del traffico e di capire dove non riescono a classificare correttamente il traffico di pageview. Queste conoscenze permetteranno di migliorare le pipelines che generano e classificano le metriche di pageview. Inoltre, definiremo metriche di qualità dei dati per monitorare e misurare i miglioramenti nell'accuratezza dei dati.
    - Questo KR getterà le basi per un KR successivo incentrato sull'implementazione dei miglioramenti necessari della pipeline qui identificati. Le metriche di qualità dei dati stabilite in questa fase serviranno come parametri di riferimento per valutare l'efficacia di questi futuri miglioramenti.
  - Risultato chiave SDS1.2: Entro la fine del primo trimestre, il contenuto del set di dati della cronologia dei contenuti di MediaWiki sarà disponibile tramite un'esportazione di file con garanzie di consegna settimanali (SLO). I dati del file esportato avranno la stessa parità rispetto alla pipeline di esportazione XML Dumps 1 legacy.
    - L'obiettivo del FY24/25 KR 1.4 è stato quello di rimuovere la dipendenza dai set di dati mediawiki_wikitext_history e mediawiki_wikitext_history_current aggiornati mensilmente per le 3 pipeline downstream più rilevanti e di fornire un set di dati alternativo con SLO settimanali garantiti.
    - Sebbene l'anno fiscale 24/25 KR 1.4 abbia contribuito a mitigare i problemi di affidabilità per le pipeline dipendenti più importanti, rimangono ancora pipeline con la fonte di input legacy inaffidabile. Anche queste dovrebbero essere migrate, così come la fonte di input basata su file nell'insieme di dati storici wikitext.
  - Risultato chiave SDS1.3: entro la fine del secondo trimestre, il rilevamento dei bot incorporerà 1 segnale addizionale e genererà avvisi automatici in caso di anomalie.
    - In tutta la Foundation, i team stanno prendendo decisioni relative ai prodotti e ai finanziamenti basandosi sulla capacità di determinare la differenza tra lettori umani e traffico automatizzato. La piattaforma dati è l'archivio centrale per i segnali di rilevamento dei bot e l'analisi batch. Attraverso le ipotesi che abbiamo elaborato nel primo e secondo trimestre, intendiamo introdurre nuovi segnali di rilevamento dei bot per affinare la nostra analisi del traffico automatizzato e rendere il processo di introduzione dei nuovi segnali efficiente e ripetibile.
  - Risultato chiave SDS1.4:Entro la fine del secondo trimestre, i responsabili delle decisioni avranno una chiara comprensione dello stato attuale delle informazioni fornite dai nostri parametri organizzativi. Sapremo di aver raggiunto il nostro obiettivo se forniremo una presentazione pronta per la riunione del consiglio di amministrazione che collochi l'analisi dei nostri parametri sia nell'ecosistema Wikimedia, sia nelle più ampie tendenze e sfide di Internet sul mercato.
    - Le informazioni ricavate dai nostri parametri organizzativi vengono utilizzate per prendere una miriade di decisioni all'interno della fondazione, comprese quelle relative alla realizzazione dei nostri prodotti, all'allocazione delle risorse infrastrutturali e alla raccolta fondi. Allo stesso tempo, il panorama di Internet è in continua evoluzione e il traffico automatizzato, in particolare, influisce sui nostri parametri. L'obiettivo è che la leadership della Foundation si presenti alla riunione del consiglio di amministrazione di dicembre con una visione chiara delle minacce e delle opportunità all'interno dell'ecosistema Wikimedia, supportata da un'analisi attendibile dei parametri interni e delle tendenze esterne. Possiamo raccontare questa storia raccogliendo informazioni, metriche e dati che ci forniscono indicazioni affidabili su:
      - Andamento delle nostre misurazioni interne del numero di lettori (visualizzazioni di pagina)
      - Andamento del nostro ecosistema di contributori
      - Andamento dei dati esterni e dei benchmark della concorrenza
      - Approfondimenti tratti da studi interni ed esterni e ricerche affidabili
  - Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
    - In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
      - Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
      - Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.

- - - In Q3/Q4, we will follow that with three main deliverables:

- - - - Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
      - Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
      - Operationalize a client-side signal, which remains the most promising internally developed detection method.
  - Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
    - A consistent delivery cadence
    - Most valuable content for our stakeholders
    - Areas for future automation
    - Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
      - What meaningfully changed in the past week/2 weeks?
      - Have we learned anything new about existing trends that we’re questioning?
      - Why does it matter now?
      - What requires attention or action?
    - The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

Piattaforma di sperimentazione (SDS2)

Obiettivo: I product manager possono valutare in modo rapido, semplice e sicuro l'impatto delle modifiche alle caratteristiche del prodotto in Wikipedia. Discussione
- Contesto dell'obiettivo: per consentire e accelerare il processo decisionale basato sui dati in merito allo sviluppo delle funzionalità di un prodotto, i responsabili di prodotto hanno bisogno di una piattaforma di sperimentazione che consenta loro di definire le funzionalità, selezionare il pubblico di utenti da trattare e vedere le misurazioni dell'impatto. Accelerare il tempo che intercorre tra il lancio e l'analisi è fondamentale, in quanto la riduzione dei tempi di apprendimento accelererà la sperimentazione e, in ultima analisi, l'innovazione. Le attività manuali e gli approcci personalizzati alla misurazione sono stati identificati come ostacoli alla velocità. Lo scenario ideale è che i product manager possano passare dal lancio dell'esperimento alla scoperta con un intervento manuale minimo o nullo da parte di ingegneri e analisti.
- Per il prossimo anno fiscale ci siamo concentrati su Wikipedia perché è lì che Core Experiences è interessata alla sperimentazione (la strategia organizzativa ci vede raddoppiare su Wikipedia) e perché ci permette di concentrarci e segnalare più chiaramente con quali team e progetti ci stiamo impegnando. Altri team hanno utilizzato i componenti della piattaforma di sperimentazione e potrebbero continuare a farlo, ma questo utilizzo non sarà al centro di questo obiettivo.
  - Risultato chiave SDS2.1: Entro la fine del secondo trimestre, consentire il completamento di almeno 2 cicli completi di sperimentazione utilizzando la piattaforma di sperimentazione.
    - Poiché l'organizzazione pone sempre più l'accento sulle decisioni di prodotto basate sui dati, dobbiamo rendere la sperimentazione accessibile a tutti i team di prodotto, non solo a quelli con competenze specialistiche. I team di prodotto hanno bisogno di standard, strumenti e infrastrutture condivisi che consentano loro di:
      - Testare rapidamente le idee in tutta la nostra base di utenti globale
      - Misurare l'impatto delle modifiche al prodotto con metriche standardizzate
      - Condividere i risultati in modo trasparente con i nostri stakeholder del Movimento
    - Perché stiamo passando dal concentrarci sul numero di “team abilitati” agli “esperimenti completati”:
    1. Allineamento strategico: È la principale metrica di successo della piattaforma
    2. Approccio basato sui dati: La nostra ricerca sugli utenti (in corso) suggerisce una disponibilità variabile del team all'interno dell'organizzazione, mentre sappiamo che il team Web ha confermato l'interesse per due esperimenti specifici.
    3. Ottimizzazione delle risorse: Il rollout della nostra piattaforma MVP richiederà un onboarding ad alto contatto, rendendo più efficiente nel breve termine concentrarsi sulle opportunità di sperimentazione piuttosto che gettare una rete ampia su più team. Abbiamo intenzione di avanzare verso un rilascio generale e non vogliamo reinvestire nuovamente nella formazione dei team, se possiamo evitarlo.
    4. Orientamento al futuro: Il feedback proveniente dai cicli completi di sperimentazione informerà i miglioramenti della nostra piattaforma in modo più efficace rispetto agli apprendimenti derivanti da un'adozione parziale o incompleta. Mentre ci avviciniamo al rilascio generale, concentrandoci sul completamento degli esperimenti evitiamo di investire in approcci temporanei che dovrebbero essere rielaborati.
    - Abbiamo in corso una ricerca sugli utenti per individuare le esigenze e i requisiti del team trasversale: sono in programma sondaggi e interviste per aggiungere chiarezza alle esigenze del team di prodotto nella seconda metà di maggio 2025. Una volta completata la ricerca, prepareremo un calendario delle sperimentazioni che potrà essere utilizzato per stabilire gli obiettivi e le priorità dei prossimi KR.
  - Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
    - After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
    - Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
    - The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
  - Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
    - After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
      In making GrowthBook the source of truth for experiment configuration, we aim to:
      - Reduce coordination when running an experiment
      - Enable more frequent and repeatable experimentation
      - Clearly delineate between instruments and experiments
      - Move toward a mental model centered on metrics rather than instruments
  - Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
    - The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
    - KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
    - This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

Future Audiences (FA)

Future Audiences (FA1)

Obiettivo: La Wikimedia Foundation è dotata di raccomandazioni sugli investimenti strategici da perseguire per aiutare il nostro movimento a servire un nuovo pubblico in un Internet che sta cambiando. Discussione
- Contesto dell'obiettivo: a causa dei continui cambiamenti nella tecnologia e nel comportamento degli utenti online (ad esempio, la crescente preferenza per l'ottenimento di informazioni tramite applicazioni social, la popolarità di brevi video edu-tainment, l'ascesa dell'IA generativa), il movimento Wikimedia si trova ad affrontare sfide per attrarre e mantenere lettori e collaboratori. Questi cambiamenti portano anche opportunità di soddisfare nuovi pubblici creando e fornendo informazioni in modi nuovi. Tuttavia, il movimento non dispone di un quadro chiaro, basato sui dati, dei benefici e dei compromessi delle diverse strategie potenziali che potremmo perseguire per superare le sfide o cogliere le nuove opportunità. Ad esempio, dovremmo...
  - Investire in nuove funzionalità come i chatbot?
  - Portare le conoscenze e i percorsi di Wikimedia per contribuire a piattaforme popolari di terzi?
  - Qualcos'altro?
- Per garantire che Wikimedia diventi un progetto multigenerazionale, testeremo delle ipotesi per comprendere meglio e raccomandare strategie promettenti - per la Wikimedia Foundation e il movimento Wikimedia - da perseguire per attrarre e mantenere il pubblico futuro.
  - Risultato chiave FA1.1: Come risultato delle intuizioni e delle raccomandazioni sperimentali di Future Audiences, entro la fine del terzo trimestre almeno un obiettivo o un risultato chiave di proprietà di un team non-Future Audiences è presente nella bozza del piano annuale dell'anno successivo.
    - Dal 2020, la Wikimedia Foundation segue le tendenze esterne che possono avere un impatto sulla nostra capacità di soddisfare le future generazioni di consumatori e contributori di conoscenza e di rimanere un fiorente movimento di conoscenza libera per le generazioni a venire. Future Audiences, un piccolo team di ricerca e sviluppo, si occuperà di:
      - Eseguire esperimenti rapidi e circoscritti nel tempo (con l'obiettivo di almeno 3 esperimenti per anno fiscale) per esplorare modi per affrontare queste tendenze
      - Sulla base delle conoscenze acquisite con gli esperimenti, fornirà raccomandazioni per nuovi investimenti non sperimentali che WMF dovrebbe perseguire - ossia nuovi prodotti o programmi che devono essere presi in carico da uno o più team completi - durante il nostro regolare periodo di pianificazione annuale.
    - Questo risultato chiave sarà raggiunto se almeno un obiettivo o un risultato chiave di proprietà di un team esterno a Future Audiences e guidato da una raccomandazione di Future Audiences apparirà nella bozza del piano annuale per l'anno fiscale successivo.

Video social (FA2)

Obiettivo: le persone giovani (<25 anni) amano, imparano da, si impegnano con e condividono i contenuti Wikipedia su piattaforme dove trascorrono spesso il loro tempo online. Discussione
- Contesto obiettivo: la sperimentazione di Future Audiences con i video più brevi in questo anno fiscale ha dimostrato che possiamo raggiungere un pubblico più giovane su queste piattaforme, ma i dati di Brand Health mostrano che i nostri investimenti attuali non sono sufficienti per contrastare il declino della consapevolezza e dell'affinità con Wikipedia tra il pubblico della Gen-Z.
- Per assicurarci di raggiungere e coinvolgere efficacemente questa generazione, crediamo che dovremo impegnarci in una varietà di tattiche, e aumentare significativamente il nostro impegno in aree quali il marketing a pagamento e l'influencer marketing, campagne creative, essere reattivi alle tendenze e aumentare il nostro livello di sperimentazione su questi canali.
- Prevediamo che le sfide che stiamo affrontando richiederanno un investimento più consistente per aiutarci a superarle, in particolare per quanto riguarda gli sforzi di comunicazione e marketing per creare coinvolgimento, nonché la collaborazione tra i vari dipartimenti per la creazione di nuovi prodotti ed esperienze mirate ad aumentare la presenza del marchio e dei contenuti di Wikipedia su queste piattaforme.
  - Risultato chiave FA2.1: Generare 9.500.000 di visualizzazioni da contenuti di video di breve durata su tutti i canali di proprietà entro la fine del primo semestre.
    - Quest'anno abbiamo raggiunto circa 1 milione di visualizzazioni in 3 mesi dal lancio di brevi video sui canali @Wikipedia su TikTok, Instagram e YouTube. Per l'inizio del prossimo anno fiscale, ci aspettiamo un maggior numero di follower sui nostri canali di proprietà e una maggiore conoscenza di contenuti efficaci e coinvolgenti da mettere in pratica per raggiungere un numero ancora maggiore di spettatori.
    - Fissando un obiettivo ambizioso nella prima metà dell'anno, ci auguriamo di raggiungere un impatto più significativo, di consentire la creazione di nuove strategie/processi per facilitare il lavoro e di essere in grado di richiedere ulteriori risorse per raggiungere questo obiettivo.
  - Risultato chiave FA2.2: aumentare il numero di follower off-platform su TikTok dalla fascia media (100.000-250.000 follower) alla fascia macro (250.000-1 milione di follower) entro la fine dell'anno fiscale 2025/2026 (giugno 2026).
    - Attualmente ci troviamo nella fascia media dei follower su TikTok (100.000-250.000 follower) e il nostro obiettivo è raggiungere la fascia macro (250.000-1 milione di follower) entro la fine dell'anno fiscale 2025/2026 (giugno 2026). Queste fasce (micro, media e macro) sono parametri di riferimento standard nel settore per quanto riguarda le dimensioni e la portata del pubblico. Per raggiungerlo, perfezioneremo la nostra strategia di contenuto per attirare maggiormente i follower della Generazione Z e aumentare la nostra visibilità complessiva attraverso la gestione della community. I risultati del primo semestre saranno alla base degli adeguamenti tattici del secondo semestre per accelerare la crescita e raggiungere questo traguardo.
  - Risultato chiave FA2.3: Lanciare un prodotto fuori piattaforma mirato ai nuovi metodi di apprendimento/consumo mediatico del pubblico futuro e immetterlo sul mercato attraverso una campagna di marketing e di branding del prodotto in collaborazione.
    - Future Audiences lavora tipicamente su esperimenti su piccola scala con un marketing minimo e organico. Quest'anno vorremmo riservare un po' di tempo a una campagna di marketing e di nuovi prodotti su scala più ampia, rivolta a un pubblico più giovane e fuori dalla piattaforma.

Supporto al prodotto e all'ingegneria (PES)

Supporto al prodotto e all'ingegneria (PES1)

Obiettivo: i team di Product e Engineering di WMF sono più efficaci grazie al miglioramento dei processi, favorendo un cambiamento positivo nella nostra cultura. Discussione
- Contesto dell'obiettivo: questo obiettivo consiste nel rendere le modalità di lavoro della Wikimedia Foundation più veloci, più intelligenti e migliori. Si tratta del modo in cui lavoriamo. Ciò significa ridurre l'attrito e gli ostacoli (inefficienze ed errori) nei processi e raggiungere più rapidamente l'impatto. Questo obiettivo riguarda anche l'apprendimento di modalità di lavoro che possono essere adottate in tutto il dipartimento e l'organizzazione.
  - Risultato chiave PES1.1: Entro la fine del secondo trimestre, definire gli SLO per 6 servizi di produzione sulla base di una griglia di priorità che mira a massimizzare l'apprendimento di come definire e utilizzare gli SLO per prendere decisioni informate sulla priorità del lavoro relativo all'affidabilità da parte dei team degli stakeholder.
    - Un obiettivo di livello di servizio (SLO) è un accordo tra i team delle parti interessate su un livello di servizio target (affidabilità/prestazioni) che i team collaborano per soddisfare (e non superare di molto). Ad esempio, aiuta a determinare quando il lavoro sull'affidabilità o sulle prestazioni deve essere prioritario o deprivato da un team di sviluppo, o cosa costituisce un problema. I team devono preoccuparsi di identificare ciò che è immediato (allarmi/risposta agli incidenti/ bug critici) rispetto a ciò che non lo è. L'obiettivo è ridurre l'attrito tra i team di sviluppo e le loro attività. L'obiettivo è quello di ridurre l'attrito tra le funzioni negoziando gli obiettivi e comunicando priorità condivise e chiare.
  - Risultato chiave PES1.2: Entro la fine del secondo trimestre, i segnali della comunità (compresa la Wishlist) hanno influenzato WMF a dare priorità ad almeno 5 workstream di prodotto per il terzo e quarto trimestre.
    - Il nostro obiettivo è identificare e celebrare i casi in cui i team danno priorità al lavoro sulla base di richieste comunitarie basate su dati concreti.
    - Due ipotesi pianificate si concentrano esclusivamente sulla Wishlist. Sono pensate per migliorare la fiducia, snellire i processi e aumentare la partecipazione del personale e dei volontari. Un'altra ipotesi è un esperimento volto a verificare se ci sono abbastanza segnali di valore dal bar di progetto, ecc. e se l'IA può supportare la nostra forza di raccolta dei segnali.
  - Risultato chiave PES1.3: Due esperimenti trasversali tra i dipartimenti in fase iniziale, convalidati dal nostro pubblico esterno di consumatori, donatori e contributori, sono incorporati dalla Foundation nel piano annuale.
    - Questo lavoro consiste nel creare esperimenti e processi di sperimentazione da adottare in tutta la nostra organizzazione.
    - La Foundation rafforza la cultura della sperimentazione interdipartimentale incorporando due esperimenti convalidati e in fase iniziale nella sua pianificazione annuale. Questa iniziativa promuove la collaborazione al di là dei team del dipartimento Product & Technology, incoraggiando una maggiore innovazione con altri dipartimenti dell'organizzazione (come Communications and Advancement). Grazie alla creazione di nuove idee non testate e alla semplificazione dei processi di sperimentazione, i team migliorano la produttività e scalano l'impatto. L'andamento si misura con il completamento di due esperimenti interdipartimentali all'anno, la loro integrazione nelle future attività OKR e l'aumento dell'adozione delle pratiche di sperimentazione. Gli esempi di risultati sono nuovi prototipi per aumentare la crescita e la produttività dei nuovi editor, e funzionalità sperimentali che approfondiscono il legame dei lettori e dei donatori con Wikipedia. Un'opportunità specifica identificata è quella di collegare piccole esplorazioni di funzionalità per celebrare il 25° compleanno di Wikipedia.
  - Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
    - As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
    - Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
    - We're anticipating that this will mean:
      - Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
      - Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
      - Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
    - The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
  - Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
    - Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
      - We have 19 SLOs currently.
      - We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
      - Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
    - Success looks like:
      - Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
      - We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
      - Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
      - Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
  - Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
    - Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
      - We estimate there are ~20 critical services without owners.
      - We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
      - We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
  - Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
    - Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

Ipotesi

Q1

Il primo trimestre (Q1) del piano annuale WMF copre il periodo luglio-settembre.

Ipotesi di Wiki Experiences (WE) [ Risultati chiave di WE ] Discussione
Nome abbreviato delle Ipotesi	Testo del Q1	Dettagli e Discussione
WE1.1.1	Se chiediamo ai nuovi volontari che incollano il testo da un sito esterno di confermare se sono stati loro a scrivere il contenuto che stanno cercando di aggiungere, vedremo una diminuzione del ≥10% della percentuale di modifiche di nuovi contenuti pubblicate dai nuovi volontari che vengono annullate a causa di WP:COPYVIO (e delle politiche correlate).
WE1.1.2	Se forniamo una versione beta iniziale della modifica suggerita “Improve Tone”, possiamo capire se questo nuovo formato di modifiche suggerite è un modo significativo per aumentare le modifiche costruttive per i nuovi contributori senza aumentare il carico di moderazione per i patroller/revisori.
WE1.1.3	Se distribuiamo una nuova Suggestion Mode rivolta ai contributori senior all'interno dell'editor visuale (mobile + desktop) come funzione beta con ≥ 3 nuovi suggerimenti di modifica al suo interno, scopriremo quali sono gli eventuali aggiustamenti da apportare prima di valutare l'esperienza con nuovi volontari attraverso un esperimento controllato.
WE1.1.4	Se implementiamo il Reference Check su it.wiki attraverso un esperimento controllato, vedremo un aumento del ≥10% delle modifiche costruttive pubblicate dai nuovi volontari e scopriremo se c'è un sostegno sufficiente tra i patrollers e i moderatori per abilitare la funzione in modo più ampio.
WE1.1.5	Se testiamo un sistema di progressione attraverso prototipi di design con i nuovi arrivati, possiamo identificare quali tipi di pietre miliari, guida e riconoscimento sono percepiti come più motivanti e utilizzare queste intuizioni per finalizzare un design per la futura sperimentazione pilota di wiki.
WE1.1.6	Se analizziamo le principali barriere tecniche, sociali e comportamentali e i fattori che favoriscono l'editing del web mobile attraverso la ricerca sugli utenti e l'analisi dei dati, genereremo almeno 3 informazioni utili che colmeranno le principali lacune di conoscenza e rafforzeranno la nostra capacità di stabilire con sicurezza le priorità degli investimenti nei prodotti per la seconda metà dell'anno fiscale 25/26 e oltre.
WE1.2.1	Se creiamo un proof of concept per la visualizzazione dei dati dei contributi collaborativi sui wiki, possiamo raccogliere il feedback di almeno 30 collaboratori e il 70% degli intervistati ritiene che la funzione sia utile e possa contribuire alla crescita della collaborazione.
WE1.3.1	Se utilizziamo le esigenze identificate dalla ricerca precedente e progettiamo e condividiamo i primi mockup dei primi X moduli di moderazione di maggiore impatto, possiamo modificare la homepage per le azioni di moderazione con loro.
WE1.3.2	Se modifichiamo la homepage dei nuovi arrivati per rendere condizionatamente i moduli dei moderatori, possiamo dimostrare la fattibilità dell'uso della homepage per i moderatori.
WE1.4.1	Se apportiamo una serie di miglioramenti indicati in T396489, ridurremo le lente query di recentchanges dell'X percento sulle wiki di grandi dimensioni. In questo modo gli strumenti dei moderatori saranno in grado di distribuire i moduli della homepage su queste wiki senza particolari problemi di prestazioni del db.	T400696
WE2.1.1	Se invitiamo i madrelingua di piccole wiki attraverso un banner CentralNotice su una Wikipedia ad alto traffico nella loro regione a contribuire ai SuggestedEdits e ad altre funzioni di crescita, possiamo valutare se questo approccio attrae nuovi madrelingua e se essi utilizzano questi strumenti di editing per migliorare i contenuti vitali.
WE2.1.2	Se sviluppiamo e rilasciamo suggerimenti di traduzione su misura per i nuovi contributori, saremmo in grado di verificare se questo approccio produce risultati di traduzione migliori rispetto al nostro approccio attuale. In questo modo si affrontano le sfide note dei nuovi contributori, che hanno una maggiore probabilità di cancellazione degli articoli. Indirizzandoli verso la traduzione di contenuti più gestibili, l'obiettivo è quello di fornire un'introduzione meno opprimente e più accessibile al processo di traduzione. I candidati a un buon articolo e a una buona sezione potrebbero avere una complessità limitata in termini di formattazione e lunghezza complessiva.
WE2.1.3	Se impariamo a conoscere l'esperienza del contributore durante la creazione di nuovi articoli e sezioni (comprese le motivazioni, i punti dolenti e la loro reazione alle nuove idee su come supportarli meglio), allora scopriremo le esigenze e i comportamenti degli utenti che forniranno intuizioni e strategie attuabili per informare il prodotto, il design e la progettazione sul miglioramento dell'esperienza di creazione degli articoli.
WE2.1.4	Se esploriamo, attraverso workshop partecipativi o interviste, il modo in cui tre Wikipedias di medie dimensioni affrontano le lacune e l'importanza della conoscenza, scopriremo definizioni di lavoro o concetti di inquadramento per la “conoscenza vitale” che sono rilevanti per ogni comunità.
WE2.2.1	Se seguiamo il percorso di Parsoid e integriamo le funzioni Wikifunctions nella maggior parte dei Wikizionari e in alcune Wikipedie a basso traffico, otterremo i test di cui abbiamo bisogno per poterlo estendere con sicurezza a wiki più grandi.
WE2.2.2	Se abilitiamo le Wikifunctions a produrre tabelle HTML, stili e collegamenti, dimostreremo, attraverso una funzione che visualizza una tabella di coniugazione, la sua capacità di generare nuova conoscenza sui Wikizionari al di là delle semplici conversioni.
WE2.2.3	Se aggiungiamo il supporto per le entità Wikidata nelle chiamate di funzione incorporate, potremo attivare oltre 200 nuove funzioni in grado di generare frasi complete utilizzando le entità Wikidata, rendendo le funzioni più facilmente utilizzabili nei progetti Wikimedia.
WE2.2.4	Se costruiamo un piano architettonico per dove risiederanno i contenuti astratti e come interagiranno con Wikipedia, saremo più pronti a implementare la piattaforma Abstract Wikipedia per aumentare la fornitura di contenuti enciclopedici di alta qualità.
WE2.2.5	Se definiamo e socializziamo tra i team di Product e Technology le esigenze del prodotto per le citazioni richieste per l'Abstract Content, saremo in grado di guidare il lavoro trasversale di Wikimedia per fornire informazioni sulla provenienza allegate all'Abstract Content, che è cruciale per il successo dell'adozione in tutte le wiki.
WE2.2.6	Se rendiamo il nostro formato di richiesta interno al backend più espressivo e conciso, possiamo aumentare la stabilità del sistema, supportando così un'implementazione più ampia.
WE2.2.7	Se forniamo frammenti di prototipi che utilizzano Wikidata e le chiamate a Wikifunctions per generare snippet in linguaggio naturale, dimostreremo di essere pronti per il progetto e di poterlo utilizzare per addestrare l'IA in modo che gli umani non debbano pensare troppo alle funzioni.
WE2.2.8	Se forniamo l'importazione di affermazioni di Wikidata con qualificatori, sarà possibile generare fatti sfaccettati (fatti che richiedono più di un soggetto/predicato/valore per essere espressi), che comprendono circa il 50% dei contenuti enciclopedici di Wikidata.
WE2.2.9	Se forniamo la cache delle entità Wikidata recuperate, ridurremo di almeno il 50% il tempo medio di esecuzione delle funzioni basate sui contenuti di Wikidata, riducendo i timeout e la frustrazione degli utenti.
WE2.2.10	Se forniamo un componente di senso del lessema di Wikidata nell'interfaccia utente di Wikifunctions, i collaboratori saranno in grado di identificare e selezionare i lessemi pertinenti senza lasciare la piattaforma/Wikifunctions, riducendo il cambio di contesto e consentendo una creazione più rapida e di successo di funzioni legate alla lingua.
WE2.2.11	Se affrontiamo i risultati di usabilità della comunità Dagbani sull'integrazione delle Wikifunctions in Wikipedia, osserveremo che i redattori incontrano meno o zero problemi di usabilità critici quando inseriscono una funzione in un articolo durante i test.
WE3.1.1	Se effettuiamo un test A/B su una versione migliorata della funzione di navigazione a schede, sull'app IOS, vedremo un aumento del 5% nell'utilizzo di più giorni tra gli utenti dei Tab.
WE3.1.3	Se forniamo agli utenti un nuovo modo per sfogliare i contenuti di immagini o video pertinenti all'interno delle pagine degli articoli, vedremo almeno un tasso di clic del 3% tra gli utenti a cui viene presentata questa funzione.
WE3.1.4	Se mostriamo ai lettori diversi concetti per attraversare la rete di conoscenza sui wiki, otterremo un elenco prioritario di concetti da sviluppare ulteriormente.
WE3.1.5	Se forniamo ai lettori del web la possibilità di visualizzare una versione tradotta automaticamente dei contenuti di Wikipedia non disponibili nella loro lingua, scopriremo se l'attività di lettura aumenta, misurata come un aumento del 3% delle interazioni tra le pagine, attirando i lettori verso il wiki in lingua locale con un potenziale aumento dell'attività di editing locale. Questo verrà effettuato in un contesto di test A/B controllato per non più di 6 mesi e in 13 Wikipedie con il consenso preventivo, utilizzando servizi di traduzione automatica aperti già disponibili per gli editori di Wikipedia.
WE3.2.1	Se collaboriamo con la raccolta fondi, svilupperemo slide per i donatori più coinvolgenti, integrate e personalizzate nell'Year in Review di iOS, come misurato attraverso i test degli utenti. Questo sarà seguito da un'ipotesi nel secondo trimestre per valutare se l'Year in Review migliorato ha visto il 5% di donazioni in più rispetto all'Year in Review del 2024.
WE3.2.2	Se chiediamo ai lettori di app per Android nei mercati non interessati dalla campagna di impostare un promemoria opzionale e personalizzabile (importo e frequenza) per le donazioni in base al loro utilizzo di Wikipedia, vedremo un aumento del 5% delle donazioni dal menu dell'app in quei mercati.
WE3.2.3	Se eseguiamo un test A/B sugli utenti disconnessi per visualizzare sottili varianti del punto di ingresso della donazione sia per mobile che per desktop, osserveremo un numero di donazioni del 2% superiore attraverso i percorsi di trattamento, rispetto al controllo.
WE3.3.1	Se nel Year in Review del 2025 aggiungiamo elementi personalizzati a basso o medio impegno richiesti dagli utenti iOS nel 2024, vedremo un aumento del 3% della soddisfazione rispetto all'anno scorso, misurata attraverso test di usabilità o beta test.
WE3.3.2	Se espandiamo la scheda Modifica esistente su Android in un hub di attività personalizzato che include approfondimenti sulla partecipazione alla lettura e alla non-modifica, vedremo un aumento del 5% nell'impegno di più giorni con la scheda rispetto alla versione originale.
WE3.3.3	Se introduciamo almeno un avatar sbloccabile nell'app Android per i titolari di account - guadagnato attraverso azioni significative dei lettori, come il salvataggio di un certo numero di articoli - aumenteremo del 10% l'impegno ripetuto con l'azione associata da parte degli utenti connessi nell'arco di più giorni.
WE3.3.4	Se diamo ai lettori loggati la possibilità di salvare gli articoli in un elenco di lettura privato, ci aspettiamo che l'impegno sul sito aumenti, come misurato da un aumento del 5% del traffico interno di riferimento per i lettori che utilizzano questa funzione, e un aumento statisticamente significativo per tutti gli utenti.
WE3.3.5	Se conduciamo uno studio sugli utenti che consente ai lettori web di raccogliere/curare contenuti da Wikipedia, almeno il 10% dei partecipanti salverà due o più tipi distinti di contenuti (ad esempio, articoli, estratti, media) in una raccolta.
WE3.4.1	Se lavoriamo per un'implementazione ibrida PoP/CDN, questo ci permetterà di creare sia PoP completi che mini PoP (fisici e cloud) a seconda delle necessità, gettando le basi per un prototipo di mini PoP in futuro.
WE3.6.1	Se eseguiamo un test A/A sul tasso di ritenzione degli utenti disconnessi, stabiliremo una linea di base per il tasso di ritenzione da utilizzare per i trimestri futuri.
WE3.6.2	Se creiamo e pubblichiamo una definizione di lettore connesso, saremo in grado di utilizzarla in tutti i team e in tutte le ipotesi relative al WE 3.3 KR.
WE3.6.3	Se coinvolgiamo le comunità in conversazioni sull'evoluzione delle esigenze dei lettori e sulla natura mutevole della conoscenza su Internet, possiamo costruire un'attenzione condivisa su come servire i lettori e lavorare insieme su come testare le nostre varie idee (comprese quelle relative a multimedialità, ricerca e scoperta e apprendimento automatico).
WE3.6.4	Se studiamo le motivazioni, i comportamenti e le esigenze che stanno alla base di quando, perché e come i lettori utilizzano Wikipedia e altre piattaforme di conoscenza, otterremo risultati che potremo utilizzare per informare ed evolvere la nostra strategia di consumo.
WE4.1.1	Se prototipiamo un flusso di non emergenza minimamente fattibile e manteniamo aperto un ciclo di feedback iterativo mentre lo sviluppiamo con gli utenti con diritti estesi, allora questi gruppi sosterranno una diffusione più ampia di questo flusso.	Project page
WE4.2.1	Se facciamo emergere il livello di rischio hCaptcha associato alla creazione di un account a funzionari fidati, diminuiremo il tempo necessario per identificare i malintenzionati e aumenteremo il numero di rilevamenti di account di malintenzionati creati sulla piattaforma. Possiamo misurare il successo dell'ipotesi osservando il tasso di blocchi applicati agli account, l'allineamento dei livelli di rischio hCaptcha e dei blocchi degli account in generale e il feedback qualitativo dei funzionari.
WE4.2.2	Se generiamo indagini suggerite che i CheckUser devono seguire, vedremo una diminuzione del tempo necessario per identificare gli account di malintenzionati e un aumento del numero di account di malintenzionati identificati. Sapremo di avere successo quando vedremo un uso regolare della funzione “Indagini suggerite”, un aumento delle mitigazioni applicate agli account identificati tramite le indagini suggerite e il feedback del sondaggio qualitativo.
WE4.2.3	Se analizziamo i dati della prova di creazione dell'account con hCaptcha, comprenderemo l'imbuto di creazione dell'account, l'efficacia del puzzle e dei punteggi di hCaptcha e disporremo dei dati necessari per informare l'ulteriore implementazione di hCaptcha sulla creazione dell'account.
WE4.2.4	Se distribuiamo la UserInfoCard su tutte le wiki, metteremo i funzionari e i moderatori in condizione di identificare e ridurre in modo più efficiente gli account dei malintenzionati.	Project page
WE4.2.5	Se conduciamo ricerche, ci consultiamo con le comunità e studiamo soluzioni tecniche, saremo in grado di definire un insieme di ragioni di blocco strutturate che possono essere utilizzate in tutte le wiki WMF.
WE4.2.6	Se sviluppiamo la capacità di distribuire cluster basati su OpenSearch sulla Data Platform, i team di ingegnerizzazione delle caratteristiche del prodotto saranno autorizzati a sviluppare sistemi che integrano questa capacità, con una grande autonomia, resilienza e isolamento da altri sistemi basati sulla ricerca. Il primo e principale tenant di questo sistema sarà il servizio IPoid.
WE4.2.7	Se implementiamo l'integrazione di hCaptcha Enterprise su diverse Wikipedie di produzione come prova pilota, saremo in grado di raccogliere dati sull'efficacia e sul valore di hCaptcha Enterprise in materia di antiabuso, rilevamento dei bot, usabilità e accessibilità.
WE4.3.1	Se integriamo il supporto per il nuovo cookie Edge Uniques in requestctl, il nostro motore di regole edge per SREs che combatte gli abusi, saremo in grado di difenderci meglio dai DDoS e dal riutilizzo dei contenuti.
WE4.4.1	Se riusciamo ad apportare miglioramenti sulla base del feedback piloti e a distribuire gli account temporanei a tutti i progetti, saremo in grado di proteggere l'esposizione delle informazioni di identificazione personale (indirizzi IP) degli utenti non registrati su tutti i nostri progetti in modo che siano disponibili a meno dello 0,1% di tutti gli utenti (registrati).	Project page
WE4.4.2	Se comunichiamo con gli stakeholder rilevanti del movimento (inclusi le comunità wiki e i funzionari globali) in modo chiaro e puntuale, saremo in grado di distribuire su tutte le wiki rimanenti, ridurre il carico di lavoro scoperto all'ultimo minuto ed evitare di annullare la distribuzione.
WE4.4.3	Se rendiamo più facile per i patroller filtrare le azioni e visualizzare l'attività degli account temporanei, in base ai loro indirizzi IP, allora potremo consentire agli account temporanei di essere estesi con successo a tutte le wiki.
WE4.4.4	Se permettiamo di revocare l'accesso agli account temporanei in linea con la politica di accesso agli account temporanei e facciamo emergere la funzione in un maggior numero di luoghi, allora potremo estendere con successo gli account temporanei a tutte le wiki.
WE4.5.1	Se conduciamo una ricerca qualitativa per identificare esempi di abuso da parte di malintenzionati assistiti dall'IA generativa (come spam, molestie, abusatori di lunga data, editing a pagamento non dichiarato o campagne di disinformazione), saremo in grado di valutare il rischio per i nostri modelli di comunità e generare idee per mitigare i diversi tipi di abuso assistito dall'IA generativa.
WE4.6.1	Se automatizziamo il processo di sincronizzazione dell'account all'interno di Zendesk per la reimpostazione della password, alleggeriremo l'onere per i T&S e consentiremo loro di gestire un maggior numero di richieste di reimpostazione 2FA in entrata.
WE4.6.2	Se supportiamo e incoraggiamo gli utenti a registrare più fattori di autenticazione, gli utenti con 2FA abilitato avranno meno probabilità di bloccarsi dal proprio account.
WE4.6.3	Se permettiamo a tutti gli utenti con un indirizzo e-mail confermato di attivare la 2FA per i loro account, ma non pubblicizziamo proattivamente questa modifica agli utenti, il carico del nostro desk di supporto al recupero rimarrà a un livello sostenibile.
WE5.1.1	Se utilizziamo backend di archiviazione diversi per le sessioni autenticate e anonime, saremo in grado di proteggere Sessionstore dagli attacchi DDoS e dagli scrapers ad alto volume, non sovraccaricandolo con le sessioni anonime create per fornire la prevenzione CSRF sulle pagine di autenticazione.	T398814
WE5.1.2	Se cambiamo i cookie di sessione di MediaWiki in un formato strutturato con una firma crittografica, saremo in grado di utilizzare la presenza di una sessione come fattore di protezione contro gli scrapers, consentendo una verifica affidabile delle sessioni ai margini in modo performante e altamente scalabile.	T398815
WE5.1.3	Se creiamo una soluzione di rate limiting per il gateway API utilizzando un ambiente di sviluppo locale basato su Kubernetes, saremo in grado di determinare l'opzione migliore da testare con il traffico di produzione, confrontando le prestazioni e la funzionalità di almeno tre diversi servizi di rate limiting.	T398913
WE5.2.1	Se riprogettiamo l'interfaccia utente dell'API Sandbox REST per soddisfare meglio le esigenze informative degli sviluppatori, miglioreremo la chiarezza della documentazione, come convalidato dai test di usabilità.
WE5.2.2	Se instradiamo tutte le API di valore inferiore a rest.php attraverso un gateway centrale, sbloccheremo i mezzi di gestione centralizzata delle API e potremo iniziare a misurare in modo coerente il traffico e i modelli di utilizzo delle API REST per ottenere informazioni che informeranno le decisioni e le azioni future.
WE5.2.3	Se implementiamo delle dashboard di monitoraggio e allarmi per l'API REST di MediaWiki, possiamo dimostrare un modo sostenibile, utile e replicabile per migliorare la visibilità del comportamento dei nostri sistemi e far emergere prima i problemi, soprattutto durante le modifiche critiche.
WE5.3.1	Se ampliamo e semplifichiamo le linee guida per l'attribuzione delle UX mentre aggiorniamo quelle esistenti, si creerà un nucleo di linee guida migliorate pronte per essere testate internamente e perfezionate iterativamente per essere preparate per un uso pubblico più ampio.
WE5.3.2	Se creiamo un'iniziativa che dimostra i vantaggi dell'attribuzione di Wikipedia ai riutilizzatori di contenuti di terze parti e ai loro utenti finali, possiamo sostenere WME4.1 e WME4.2 consentendo ad almeno un altro partner di riutilizzo di accettare di apparire in un caso di studio o in una demo sull'attribuzione entro la fine del primo trimestre.
WE5.4.1	Se ci assicuriamo che la maggior parte delle richieste web riceva un cookie edge uniques, sarà più facile identificare i bot e le richieste falsificate.
WE5.4.2	Se costruiamo un modo scalabile per identificare i clienti noti, possiamo consentire eccezioni ai limiti di velocità generali per i bot di origine verificata e passare all'applicazione sistematica delle nostre regole.
WE5.4.3	Se riorganizziamo il filtraggio delle richieste di testo presso il CDN in base a un approccio di tipo allowlist/denylist, possiamo imporre una limitazione generale del tasso più severa per i bot e semplificare il filtraggio del traffico.
WE5.4.4	Se sviluppiamo una strategia di misurazione unificata, potremo valutare la strategia pluriennale per un “uso responsabile delle infrastrutture” e definire una tabella di marcia per guidare lo sviluppo delle metriche e le capacità di reporting.
WE6.1.1	Se rimettiamo le build giornaliere delle immagini sul server di distribuzione e aggiungiamo aggiornamenti delle immagini attivati da azioni di distribuzione selezionate, scopriremo i vincoli e stabiliremo una linea di base per il tempo necessario a eseguire distribuzioni più continue.
WE6.1.3	Se aggiungiamo le wikifarm a un ambiente di test pre-merge, questo consentirà ai team di sviluppo che costruiscono per la produzione e che hanno bisogno di più wiki di testare le loro patch in modo isolato, dando loro una maggiore sicurezza prima della produzione e riducendo la fuga dei difetti.
WE6.2.1	Se rivediamo e pubblichiamo la nostra lista di controllo della prontezza di produzione, che definisce chiaramente i prerequisiti affinché un servizio sia considerato pronto per la produzione, insieme ai compiti autoservibili, allineeremo le aspettative tra i SRE e i team di sviluppo, migliorando l'efficienza operativa e la scalabilità complessive.
WE6.2.2	Se annunciamo la creazione di una libreria Golang e nodejs che astrae molti compiti faticosi per gli sviluppatori, questi risponderanno offrendo feedback e interesse.
WE6.2.3	Se creiamo una lista di controllo/foglio di lavoro, gli sviluppatori possono prepararsi completamente in anticipo per la revisione del progetto Data Persistence.
WE6.3.1	Se nel primo trimestre riusciamo a implementare almeno 70 wikipedie a basso traffico, escludendo quelle con supporto per le varianti linguistiche, aumenteremo la nostra fiducia per l'eventuale implementazione alle prime 10 wiki, che avranno un impatto maggiore sulle visualizzazioni di pagina servite tramite Parsoid.
WE6.4.1	Se distribuiamo la tabella dei link di Commons in un proprio cluster, aumenteremo le possibilità che la crescita del database di Commons rimanga sostenibile.	T398709
WE6.4.2	Se noi (SRE) forniamo assistenza ai team di ingegneri di MediaWiki - creando la documentazione, preparando l'infrastruttura necessaria (ad esempio, pacchetti PHP, immagini dei contenitori) e offrendo guida e revisione - essi saranno in grado di avviare con fiducia l'aggiornamento di PHP 8.3 in produzione entro l'inizio del secondo trimestre.	T360995
WE6.4.3	Se richiediamo un secondo fattore fisico (chiave di sicurezza hardware) per gli accessi SSH da parte di utenti con privilegi di sistema elevati, ridurremo il rischio che un laptop compromesso possa causare una grave violazione della sicurezza.
WE6.4.4	Se unifichiamo i nostri domini servendo tutte le visualizzazioni di pagina sui siti MediaWiki attraverso un dominio canonico, ridurremo la complessità della piattaforma e i rischi legati all'ottimizzazione per i motori di ricerca (SEO) eliminando il reindirizzamento del sottodominio mobile. Il completamento viene misurato dalla diminuzione dei reindirizzamenti per le visite mobili sui domini canonici dal 100% allo 0%.	T214998
WE6.4.5	If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2.	T360995

Ipotesi dei Signals e Data Services (SDS) [ Risultati chiave dei SDS ] Discussione
Nome abbreviato delle ipotesi	Testo del Q1	Dettagli e Discussione
SDS1.1.1	Se analizziamo l'efficacia dell'euristica di rilevamento automatico del traffico nei nostri dataset di pageviews, saremo in grado di sviluppare metriche di qualità dei dati per descrivere le loro prestazioni e determinare la necessità di ulteriori investimenti in questa euristica.
SDS1.2.2	Se migriamo il processo dei dump XML dall'attuale infrastruttura “Dumps 1” a una pipeline di dati che sfrutta le Content Pipeline di MediaWiki, saremo in grado di garantire gli SLO e di disattivare l'esportazione XML basata su “Dumps 1”.
SDS1.2.3	Se facciamo un walkthrough e rivediamo gli SLO per la Cronologia dei contenuti di MediaWiki e per la Piattaforma eventi / Porta eventi, possiamo convalidare i clienti, le metriche e gli stakeholder dipendenti e identificare i miglioramenti che potrebbero essere necessari per gli SLO, il che ci aiuterà a chiarire eventuali lacune nelle nostre garanzie di consegna settimanale.
SDS2.1.1	Se collaboriamo strettamente con i team che eseguono gli esperimenti, impareremo come rendere il sistema più self-service in futuro e quali sfide concettuali o tecniche potrebbero incontrare.
SDS2.1.2	Se riusciamo a implementare un debug migliore per l'eventlogging, i team di prodotto sapranno che il loro esperimento sta raccogliendo dati sugli eventi come previsto, aumentando la fiducia dei proprietari dell'esperimento.
SDS2.1.3	Se miglioriamo la registrazione e l'osservabilità del sistema di test A/B (xLab), componente della piattaforma di sperimentazione, e delle parti MediaWiki ad esso collegate, saremo in grado di stabilire delle linee di base per le prestazioni del sistema e di rispondere ai fallimenti legati agli esperimenti.
SDS2.1.4	Se condividiamo le storie e i risultati degli esperimenti in tutta l'organizzazione una volta al mese (attraverso le riunioni di Product Ops, le riunioni del team di progettazione e le presentazioni tra i vari team), allora creeremo un'adozione organica della piattaforma di sperimentazione.
SDS2.1.5	Se comunichiamo agli utenti che il loro strumento, se creato in xLab, contiene una serie di attributi che modificano la categoria di rischio, dissuaderemo gli utenti della strumentazione dall'eccessiva raccolta di dati e aumenteremo la chiarezza su quale combinazione di attributi richiede una revisione della privacy.

Ipotesi del Future Audience (FA) [ Risultati chiave del FA ] Discussione
Nome abbreviato delle ipotesi	Testo del Q1	Dettagli e Discussione
FA1.1.1	Se 1) offriamo ai collezionisti di media su altre piattaforme (come Letterboxd, Goodreads e RateMyMusic) la possibilità di arricchire le loro collezioni con conoscenze esclusive di Wikipedia, o 2) offriamo a questi collezionisti di media interessanti condivisibili sui social media, allora saremo in grado di aumentare la portata di Wikipedia fuori dalla piattaforma.
FA2.1.1	Se nel primo trimestre aumenteremo la nostra capacità interna di creare contenuti video brevi (aumentando le dimensioni del nostro team, verificando e identificando le opportunità per aumentare l'efficienza del nostro attuale processo di produzione), saremo in grado di sfruttare gli insegnamenti tratti dai contenuti creati nell'anno fiscale 2024-5 e di raggiungere una maggiore portata dei contenuti prodotti nel 2° trimestre dell'anno fiscale 2025-6.

Ipotesi del Product e Engineering Support (PES) [ Risultati chiave del PES ] Discussione
Nome abbreviato delle ipotesi	Testo del Q1	Dettagli e Discussione
PES1.1.1	Se supportiamo xLab, Charts e ToneCheck nella definizione di metriche per gli SLI (Service Level Indicators) in Prometheus e nell'integrazione degli Service Level Objectives (SLO) in Pyrra, impareremo a conoscere i limiti e i casi limite dei nostri strumenti in scenari multipli e complessi, oltre a chiarire quali iterazioni sono necessarie per il modello SLO, il che ci aiuterà a supportare meglio i 6 SLO previsti per il KR.
PES1.1.2	Se pilotiamo due serie di dashboard di allerta SLO, impareremo quanto sarebbe difficile implementare uno strumento adeguato in modo che i proprietari dei servizi comprendano chiaramente i loro impegni, e anche se dobbiamo migrare verso uno strumento diverso che offra solo una singola vista di uno specifico SLO. Una dashboard sarà destinata ai rapporti trimestrali (dove viene fissato l'effettivo Service Level Agreement per il budget degli errori) e una più piccola e dinamica (chiamata “rolling”) sarà destinata alle operazioni quotidiane e agli avvisi.
PES1.1.3	Se continuiamo a sostenere il gruppo Abstract Wikipedia nella stesura di uno SLO (Service Level Objectives) per il progetto Wikifunctions, impareremo a definire un elenco di obiettivi SLO (insieme alle relative metriche Service Level Indicator) per una funzione complessa attualmente in fase di aggiunta a un flusso di lavoro critico per gli utenti: il rendering degli articoli Wiki. Impareremo anche a visualizzare correttamente i relativi bilanci di errore e ad allarmarli utilizzando i cruscotti e i monitor forniti da SRE.
PES1.1.4	Se supportiamo il gruppo della Data Platform con la revisione e l'iterazione degli Service Level Objectives (SLO) per il progetto MediaWiki Content History, impareremo come sfruttare gli SLO per supportare la proprietà del servizio quando una combinazione di servizi di elaborazione batch e stream sono orchestrati insieme per aggiornare il set di dati, mantenendolo coerente e disponibile per gli utenti a valle.
PES1.2.1	Se creiamo 3 miglioramenti mirati alla Wishlist, incoraggeremo il 30% in più di partecipanti unici alla Wishlist.
PES1.2.2	Se gestiamo i desideri in arrivo e assegniamo un Manutentore (ad esempio i Product Manager) entro 72 ore (compresi i rifiuti, i chiarimenti, i servizi non mantenuti, ecc.), incrociando i nuovi desideri con la tabella dei Manutentori e assegnando una “categoria di Manutentori” al team di prodotto o alla persona più pertinente, i Manutentori (ad esempio i Product Manager) saranno in grado di valutare e rispondere ai desideri in 10 giorni o meno.
PES1.2.3	Se pilotiamo il lavoro per identificare i segnali della comunità in generale, incorporeremo maggiormente la voce dei volontari nei nostri sforzi di prioritizzazione informati dalla comunità.
PES1.2.4	Se pilotiamo un processo trimestrale di revisione dei desideri e dei segnali della comunità con 3 team nel primo trimestre, coinvolgeremo i Product Manager per integrare i segnali della comunità nei loro processi di pianificazione trimestrale e annuale.
PES1.3.1	Se, entro la fine del primo trimestre, coordiniamo 3 sessioni di pianificazione funzionale con il dipartimento di comunicazione e i team di prodotto per allineare la messaggistica, le esigenze creative e le tempistiche della campagna per le iniziative WP25, allora finalizzeremo i brief creativi per tutti e 3 gli esperimenti di campagna (25YiR, Easter Eggs, WikiRun).
PES1.3.2	Se istituiamo un comitato direttivo con rappresentanti del design e dell'ingegneria delle funzionalità, saremo in grado di definire le metriche di base sui contributi a Codex: consapevolezza, utilizzo, qualità dei contributi e quantità. Le informazioni ricavate dalla valutazione di queste metriche di base ci aiuteranno a determinare una tabella di marcia per federare la crescita e la diversificazione della base di contributori di Codex.

Secondo trimestre

Il secondo trimestre (Q2) del piano annuale WMF copre il periodo ottobre-decembre.

Wiki Experiences (WE) Ipotesi [ Risultati chiave di WE ] Discussione
Nome abbreviato delle ipotesi	Testo del secondo trimestre	Dettagli e Discussione
WE1.1.1	Se analizziamo un set predeterminato di indicatori principali ≥2 settimane dopo l'inizio del test Paste Check A/B, saremo in grado di identificare quali aspetti dell'esperienza end-to-end devono essere modificati o esaminati prima di poter valutare l'impatto della funzione.
WE1.1.4	Se implementiamo Reference Check su en.wiki attraverso un esperimento controllato, vedremo un aumento ≥4% delle modifiche costruttive pubblicate dai nuovi (o più recenti) volontari e scopriremo se c'è un sostegno sufficiente tra i patroller e i moderatori per abilitare la funzione su più ampia scala.
WE1.1.7	Se analizziamo un set predeterminato di indicatori principali ≥2 settimane dopo l'inizio del test A/B Tone Check, saremo in grado di identificare quali aspetti dell'esperienza end-to-end devono essere modificati o esaminati prima di poter valutare con sicurezza l'impatto della funzione.
WE1.1.8	Se applichiamo il modello Tone Check agli articoli pubblicati, scopriremo se è possibile identificare ≥10.000 problemi di tono (ciascuno con un punteggio di probabilità pari o superiore a 0,8) necessari per creare un pool di suggerimenti di alta qualità (accuratezza ≥ 70%) che aiutino gli editori a migliorare il tono degli articoli.
WE1.1.10	Se intervistiamo circa 10 volontari esperti su en.wiki e fr.wiki che scrivono AbuseFilters (e altri gadget/script/modelli/avvisi di modifica) per automatizzare i flussi di lavoro di pattugliamento/moderazione, identificheremo ≥3 modelli/esigenze che contribuiranno a definire la proposta di valore dei controlli di modifica creati dalla comunità.
WE1.1.11	Se distribuiamo un sondaggio a ≥500 nuovi arrivati con successo[i] e otteniamo dati di alta qualità rappresentativi della più ampia popolazione di nuovi arrivati con successo, saremo in grado di identificare ≥4 spunti attuabili che potremo utilizzare per stabilire quali aspetti dell'esperienza di inserimento migliorare in via prioritaria.
WE1.1.12	Se consentiamo ad almeno tre volontari di valutare almeno 30 modifiche campione ciascuno, per ciascuna delle dieci nuove lingue in cui intendiamo estendere Tone Check, potremo capire con quale frequenza i volontari concordano con le previsioni del modello e decidere a quali nuovi wiki proporre l'implementazione di Tone Check.
WE1.1.13	Se riusciamo a far sì che il 100% dei nuovi volontari su Wikipedia in inglese usi la funzione “Aggiungi un link”, l'attivazione e la fidelizzazione dei nuovi arrivati miglioreranno, aumentando le modifiche costruttive fatte dai nuovi volontari di ≥4%.
WE1.2.3	Se eliminiamo il requisito secondo cui è necessario disporre dei diritti di organizzatore di eventi per utilizzare la funzione di registrazione agli eventi sui wiki di piccole e medie dimensioni, entro la fine dell'anno fiscale vedremo almeno X eventi* in più creati sui wiki di piccole e medie dimensioni. in attesa del calcolo del valore di riferimento/obiettivo.
WE1.2.4	Se ripeteremo il Collaborative Contributions MVP con almeno 2 miglioramenti, allora verranno create ulteriori collaborazioni tramite la registrazione agli eventi.
WE1.2.5	Se definiamo una strategia di adozione per la registrazione degli eventi su Wikimedia Commons all'inizio del secondo trimestre, potremo testarla con gli organizzatori di almeno una grande campagna e consentire a cinque organizzatori locali di utilizzare la funzione.
WE1.3.3	Se lanciamo un esperimento per mostrare una dashboard di moderazione ai nuovi contributori, il 10% di coloro che la visitano lo fa per due settimane consecutive.
WE1.4.1	Se apportiamo i miglioramenti definiti in T396489, ridurremo le query lente relative alle modifiche recenti di almeno il 30% sui wiki di grandi dimensioni, consentendo al team tecnico della comunità di implementare Labels degli osservati speciali senza sovraccaricare il database delle modifiche recenti.
WE1.4.3	Se implementiamo le modifiche recenti e gli osservati speciali, possiamo definire una linea di base per la frequenza con cui gli utenti cliccano sulle pagine.
WE1.5.1	Se implementiamo un dashboard per esplorare 7 metriche dei contributori e standardizziamo il calcolo di almeno una metrica utilizzando dbt, potremo consentire ai team di prodotto dei contributori di ottenere autonomamente informazioni dettagliate sulle metriche e sviluppare uno standard per l'archiviazione della logica di calcolo delle metriche.
WE1.5.2	Se nel secondo trimestre stabiliamo quali azioni di moderazione includere nella definizione di chi è un moderatore, il team Movement Insights potrà elaborare la metrica dei moderatori attivi mensili nel terzo/quarto trimestre.
WE2.1.3	Se apprendiamo l'esperienza dei contributori nella creazione di nuovi articoli e sezioni (comprese le motivazioni, i punti critici e la loro reazione alle nuove idee su come supportarli meglio), potremo scoprire le esigenze e i comportamenti degli utenti che forniscono informazioni e strategie utili per migliorare l'esperienza di creazione degli articoli in termini di prodotto, progettazione e ingegneria.
WE2.2.12	Se implementiamo Wikifunctions nei wiki che hanno Parsoid abilitato, potremo continuare a verificare se il sistema rimane performante e utilizzabile in implementazioni sempre più ampie.
WE2.2.13	Se condividiamo la disponibilità della funzione della tabella di coniugazione con la comunità di Wiktionary, otterremo preziosi feedback sull'utilizzo della funzione e approfondimenti sui nostri utenti che potremo applicare alle future implementazioni.
WE2.2.14	Se esaminiamo il lavoro svolto dalla comunità Databox sull'uso di Wikidata per le infobox e valutiamo se Wikifunctions possa essere d'aiuto, saremo in grado di identificare un primo esperimento per Wikifunctions nelle infobox.
WE2.2.15	Se sensibilizziamo la comunità sulla possibilità di creare e tradurre messaggi di errore su Wikifunctions, assisteremo a un aumento del numero di messaggi di errore utili.
WE2.2.16	Se mostriamo alla comunità le funzioni semantiche disponibili, assisteremo a un aumento delle funzioni grammaticali del 50%.
WE2.2.17	Se forniamo un componente personalizzato per la visualizzazione delle dichiarazioni Wikidata su Wikifunctions, gli utenti saranno in grado di comprendere meglio i dati recuperati da Wikidata e si sentiranno meno sopraffatti.
WE2.2.18	Se riusciamo a prevenire picchi di consumo di memoria 10 volte superiori, l'orchestratore sarà in grado di gestire meglio gli oggetti Wikidata, supportando l'utilità di Wikifunctions come piattaforma per Abstract Wikipedia.
WE2.2.19	Se consentiamo agli utenti di condividere collegamenti diretti a chiamate di funzioni specifiche, compresi i loro input, i contributori saranno in grado di riprodurre, verificare e discutere più facilmente il comportamento delle funzioni, il che a sua volta accelererà il debug, migliorerà i flussi di lavoro di test e supporterà la risoluzione collaborativa dei problemi all'interno della comunità Wikifunctions.
WE2.3.1	Se finalizziamo la decisione di creare un nuovo wiki e decidiamo un nome insieme alla comunità, potremo socializzare più ampiamente la creazione di questo nuovo wiki con i nostri stakeholder e prepararci alla logistica di un potenziale cambio di nome del prodotto.
WE2.3.2	Se definiamo un MVP per un prototipo wiki astratto che includa l'esperienza più essenziale possibile per testare le nostre capacità di back-end e NLG e ci consenta di progettare in modo iterativo, saremo in grado di pianificare e lanciare un prototipo live nel terzo trimestre.
WE2.3.3	Se iniziamo a dialogare con la comunità ed esplorare potenziali progetti per l'esperienza utente di un wiki astratto, saremo in grado di portare avanti il lavoro nel terzo trimestre.
WE2.4.1	Se raccogliamo casi d'uso di Wikidata e WDQS dai team WMDE e WMF, saremo in grado di definire i requisiti di prodotto per il miglioramento dell'infrastruttura.
WE2.4.2	Se produciamo una vista di reporting aggregata degli indicatori chiave di prestazione (KPI) con gli obiettivi di livello di servizio (SLO) esistenti per Wikidata e WDQS, saremo in grado di articolare e monitorare i criteri di successo per i miglioramenti all'infrastruttura tecnica che supporta il caso d'uso critico di Wikidata.
WE2.4.3	Se riusciremo a valutare e confrontare i prodotti alternativi a Blazegraph utilizzando criteri realistici di produzione entro il trimestre, saremo in grado di prendere una decisione di migrazione basata sui dati e definire una roadmap concreta con tempistiche e requisiti di risorse.
WE3.1.1	Se eseguiamo un test A/B su una versione migliorata della funzione di navigazione a schede, vedremo un aumento del 5% nell'utilizzo plurigiornaliero tra gli utenti delle schede.
WE3.1.3	Se forniamo agli utenti un nuovo modo per sfogliare i contenuti immagine rilevanti all'interno delle pagine degli articoli e lo testiamo con un sottogruppo di lettori non registrati tramite un test A/B su una serie di wiki, vedremo almeno un tasso di clic del 3% tra gli utenti a cui viene presentata questa funzione.
WE3.1.4	Se mostriamo ai lettori diversi concetti per attraversare la rete di conoscenze sui wiki, otterremo un elenco prioritario di concetti da sviluppare ulteriormente.
WE3.1.5	Se offriamo ai lettori web la possibilità di visualizzare una versione tradotta automaticamente dei contenuti di Wikipedia non disponibili nella loro lingua, potremo verificare se l'attività di lettura aumenterà, misurata come un incremento del 3% delle interazioni con la pagina, attirando i lettori verso la wiki nella lingua locale con un potenziale aumento dell'attività di modifica locale. Ciò sarà fornito come impostazione di test A/B controllato per un periodo non superiore a 6 mesi e in 13 Wikipedie con previo consenso, utilizzando servizi di traduzione automatica aperti già disponibili per gli editori di Wikipedia.
WE3.1.6	Se produciamo un prototipo per la ricerca semantica e le domande e risposte all'interno degli articoli, fornito come interfaccia demo che mette a confronto l'approccio attuale con nuovi approcci esplorativi, i team Reader saranno in grado di valutare qualitativamente le prestazioni di ciascun approccio nei diversi percorsi degli utenti e individuare lacune o opportunità per ulteriori iterazioni.
WE3.1.7	Se esaminiamo le ricerche esistenti su come i lettori interagiscono con gli strumenti di ricerca e navigazione su Wikipedia e su come utilizzano la ricerca esterna per trovare informazioni su Wikipedia, saremo in grado di fornire ai team Reader ≥3 raccomandazioni e risultati attuabili che li aiutino a definire un MVP di ricerca e scoperta per colmare le lacune nelle aspettative e nelle esigenze dei lettori.
WE3.1.8	Se valutiamo 2 prototipi di ricerca semantica (ricerca in linguaggio naturale, domande e risposte) con partecipanti esterni, possiamo capire se gli utenti apprezzano gli strumenti di ricerca migliorati e fornire ai team Reader una raccomandazione su come procedere con un MVP di ricerca e scoperta.
WE3.1.9	Se mostriamo concetti di progettazione ad alta fedeltà per la scoperta di contenuti attraverso la ricerca semantica a 10-20 lettori occasionali di Wikipedia in uno studio qualitativo, vedremo un sentiment positivo per la funzione e otterremo la fiducia necessaria per procedere con un MVP di ricerca e scoperta che si basa su brevi estratti scritti da esseri umani per le query di ricerca.
WE3.1.10	Se mostriamo a 10 lettori occasionali un prototipo live della nuova esperienza di navigazione delle immagini in uno studio sugli utenti non moderato, scopriremo almeno un miglioramento dell'esperienza utente per le future iterazioni della funzione.
WE3.1.11	Se rendiamo meno rigida la corrispondenza delle parole chiave nella ricerca, potremo supportare meglio le query in linguaggio naturale e consentire al reparto Product di valutare questa funzionalità, includendola nella progettazione, nella definizione delle priorità e nella realizzazione del lavoro nell'ambito della ricerca semantica.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	Se introduciamo una funzione a Year in Review su Android che evidenzia l'impatto degli utenti e include messaggi integrati per i donatori, stimoleremo nuovi comportamenti di donazione e vedremo un aumento del 5% nel menu dell'app rispetto al 2024.
WE3.2.6	Se rendiamo le diapositive dei donatori nell'iOS Year in Review più integrate e personalizzate, vedremo un aumento del 5% delle donazioni rispetto al 2024.
WE3.3.3	Se introduciamo almeno un avatar sbloccabile nell'app Android per i titolari di account, ottenibile attraverso azioni significative da parte dei lettori, come il salvataggio di un certo numero di articoli, aumenteremo del 10% il coinvolgimento ripetuto con l'azione associata da parte degli utenti registrati nell'arco di più giorni.
WE3.3.4	Se offriamo ai lettori registrati la possibilità di salvare gli articoli in una lista di lettura privata, prevediamo un aumento dell'engagement sul sito, misurato da un incremento del 5% del traffico di riferimento interno per i lettori che utilizzano la funzione e da un aumento statisticamente significativo per tutti gli utenti.
WE3.3.6	Se rendiamo disponibili i dati relativi alle inferenze sugli argomenti degli articoli tramite un servizio che soddisfi i requisiti concordati in termini di scalabilità e disponibilità, oltre a eventuali integrazioni di dati necessarie, avremo creato le basi tecniche necessarie per supportare le future esperienze di lettura personalizzate che dipendono da questi dati.
WE3.3.7	Se sfruttiamo le capacità di elaborazione della piattaforma dati per aggregare metriche editoriali personalizzate e dati di impatto e forniamo i dati aggregati attraverso servizi adeguati con SLO definiti, possiamo migliorare le future iterazioni di Year in Review WE3.3.1 e Activity Tab WE3.3.2.
WE3.3.9	Se pubblichiamo Year in Review su Android e con un A/B test offriamo agli utenti coinvolti un premio per salvare una lista di lettura personalizzata, vedremo un aumento dell'1% nel tasso di fidelizzazione complessivo dell'app tra i lettori a cui è stato offerto il premio rispetto a quelli a cui non è stato offerto.
WE3.3.10	Se effettuiamo un test A/B richiedendo un account per visualizzare le informazioni di lettura personalizzate di Year in Review, vedremo un aumento dell'1% nel tasso di fidelizzazione complessivo degli utenti a cui è stato richiesto di avere un account, rispetto a quelli a cui non è stato richiesto.
WE3.3.11	Se eseguiamo un test A/B su una versione migliorata della scheda “Attività” su iOS che evidenzia la lettura, la modifica e altri comportamenti di partecipazione, vedremo un aumento del 5% delle visite plurigiornaliere da parte dei lettori registrati alla scheda rispetto alla versione prototipo.
WE3.4.1	Se lavoriamo per realizzare un'implementazione ibrida dei punti di presenza (PoP/CDN), potremo creare sia PoP completi che mini PoP (fisici e cloud) in base alle esigenze, gettando le basi per un prototipo di implementazione di mini PoP in futuro.
WE3.5.1	Se i reparti Product & Technology e Fundraising collaborano alla valutazione e alla documentazione degli approcci tecnici per l'identificazione dei donatori all'interno delle nostre piattaforme, saremo in grado di raccomandare una soluzione a breve e lungo termine che bilancia privacy, fattibilità e impatto. Questa comprensione condivisa contribuirà ad allineare il processo decisionale, consentirà il riconoscimento persistente dei donatori su tutte le piattaforme e sperimentazioni più mirate nelle future funzionalità relative alla raccolta fondi.
WE3.6.3	Se coinvolgiamo le comunità in discussioni sulle esigenze in continua evoluzione dei lettori e sulla natura mutevole della conoscenza su Internet, possiamo costruire un obiettivo comune su come servire i lettori e lavorare insieme per decidere se e come testare le nostre varie idee (comprese quelle relative a multimedia, ricerca e scoperta, e apprendimento automatico).
WE3.6.4	Se analizziamo le motivazioni, i comportamenti e le esigenze specifiche che stanno alla base di quando, perché e come i lettori utilizzano Wikipedia e altre piattaforme di conoscenza, saremo in grado di proporre aree prioritarie e iniziative specifiche per la strategia di consumo.
WE3.6.5	Se il reparto Product & Technology e quello Raccolta fondi collaborano a una strategia condivisa per diversificare le opportunità di donazione sulla piattaforma e gestire e riconoscere i lettori che effettuano donazioni, fisseremo obiettivi e parametri chiari e allineati, legati alle nostre strategie di consumo e raccolta fondi.
WE3.6.6	Se sviluppiamo una strategia di misurazione unificata, potremo valutare la strategia pluriennale dei consumatori e definire una tabella di marcia per guidare lo sviluppo delle metriche e le capacità di reporting.
WE4.1.1	Se creiamo un prototipo di flusso minimo funzionante per le situazioni non urgenti e manteniamo aperto un ciclo di feedback iterativo mentre lo sviluppiamo con utenti con diritti estesi, questi gruppi sosterranno una diffusione più ampia di questo flusso.
WE4.1.3	Se aggiorniamo 7 Wikipedie (francese, tedesca, spagnola, ungherese, italiana, polacca e portoghese) entro la fine di ottobre, completeremo la fase 1 dell'implementazione del nuovo piè di pagina legale in risposta ai requisiti del DSA.
WE4.1.4	Se implementiamo il sistema MVP di segnalazione degli incidenti su almeno 15 wiki, concentrandoci sulle comunità più grandi e complesse, potremo osservarne l'utilizzo previsto dalla comunità e dimostrare la validità di un modello funzionante per la segnalazione degli incidenti non urgenti.
WE4.1.5	Se progettiamo un diagramma di flusso per segnalare gli episodi di abuso ai wiki che non dispongono di procedure consolidate per la gestione degli abusi, incoraggeremo l'adozione del Sistema di segnalazione degli incidenti su tali wiki e consentiremo agli utenti di tali wiki di disporre di un percorso di assistenza chiaro e praticabile.
WE4.2.3	Se analizziamo i dati della prova di creazione dell'account hCaptcha, comprenderemo il funnel di creazione dell'account, l'efficacia del puzzle e dei punteggi di hCaptcha e avremo i dati necessari per informare l'ulteriore implementazione di hCaptcha sulla creazione degli account.
WE4.2.5	Se conduciamo ricerche, consultiamo le comunità e studiamo soluzioni tecniche, saremo in grado di definire una serie di motivi strutturati che potranno essere utilizzati in tutti i wiki della WMF.
WE4.2.6	Se sviluppiamo la capacità di implementare cluster basati su OpenSearch sulla piattaforma dati, i team di ingegneria delle funzionalità dei prodotti saranno in grado di sviluppare sistemi che integrano questa capacità, con un elevato grado di autonomia, resilienza e isolamento dagli altri sistemi basati sulla ricerca. Il primo e principale inquilino di questo sistema sarà il servizio IPoid.
WE4.2.7	Se implementiamo l'integrazione di hCaptcha Enterprise su diverse versioni di Wikipedia come prova pilota, saremo in grado di raccogliere dati sull'efficacia e il valore di hCaptcha Enterprise in termini di lotta agli abusi, rilevamento dei bot, usabilità e accessibilità.
WE4.2.8	Se rendiamo il proxy hCaptcha pronto per la produzione migliorandone la disponibilità e l'osservabilità, forniremo un servizio più stabile e affidabile alle Wikipedie di produzione nel primo trimestre.
WE4.2.9	Se integriamo l'SDK hCaptcha nelle app mobili native, valutiamo l'esperienza utente delle app native e valutiamo l'abilitazione delle sfide hCaptcha come parte dell'API di creazione dell'account, avremo una comprensione sufficiente per informare l'ulteriore implementazione di hCaptcha per l'API di creazione dell'account.
WE4.2.11	Se abilitiamo hCaptcha per rilevare i bot in scenari di modifica ad alto rischio, vedremo che hCaptcha è in grado di ridurre gli abusi automatizzati.
WE4.2.16	Se ci consulteremo con i team WMF competenti, saremo in grado di sviluppare un piano concordato per gestire in modo più granulare l'accesso degli utenti ai dati non pubblici e supportare l'implementazione di regole software difensive non pubbliche.
WE4.2.17	Se analizziamo esempi reali e intervistiamo gli utenti CheckUser per identificare almeno 2 segnali di potenziale comportamento abusivo dal prototipo della cronologia degli editor, il team Product Safety and Integrity sarà in grado di incorporare successivamente questi segnali nella funzione Suggested Investigations con un livello di fiducia più elevato che i segnali forniranno valore.
WE4.3.2	Se implementiamo le impronte digitali JA4H, che riassumono il comportamento dei client HTTP, saremo in grado di identificare e classificare meglio il traffico dei bot.
WE4.4.1	Se riusciremo ad apportare miglioramenti sulla base del feedback dei test pilota e ad implementare gli account temporanei in tutti i progetti, saremo in grado di proteggere l'esposizione delle informazioni di identificazione personale (indirizzi IP) degli utenti non registrati in tutti i nostri progetti, rendendole disponibili a meno dello 0,1% di tutti gli utenti (registrati)
WE4.4.2	Se comunichiamo con gli stakeholder del movimento interessati (comprese le comunità wiki e i funzionari globali) in modo chiaro e tempestivo, saremo in grado di implementare il sistema su tutte le wiki rimanenti, ridurre il carico di lavoro scoperto all'ultimo minuto ed evitare di dover annullare l'implementazione.
WE4.4.5	Se riduciamo l'attrito per i patrollers nell'identificare i malintenzionati che utilizzano account temporanei per vandalizzare, saremo in grado di prevenire un aumento del vandalismo misurando l'assenza di aumento del tasso di ripristino in tutti i wiki con account temporanei.
WE4.4.6	Se disattiviamo l'estensione LiquidThreads, sbloccheremo gli account temporanei distribuiti su tutti i progetti che attualmente utilizzano questa estensione.
WE4.6.1	Se automatizziamo il processo di sincronizzazione degli account all'interno di Zendesk per il ripristino delle password, alleggeriremo il carico di lavoro del reparto T&S, consentendo loro di gestire un maggior numero di richieste di ripristino 2FA in arrivo.
WE4.6.3	Se consentiamo a tutti gli utenti con un indirizzo e-mail confermato di attivare l'autenticazione a due fattori (2FA) per i propri account, ma non pubblicizziamo in modo proattivo questa modifica agli utenti, il carico di lavoro del nostro servizio di assistenza per il recupero rimarrà a un livello sostenibile.
WE4.6.4	Se continuiamo a migliorare l'esperienza utente del nostro sistema 2FA e aggiungiamo il supporto per le passkey, un numero maggiore di utenti registrerà più fattori di autenticazione e sarà più protetto contro la perdita dell'accesso all'account.
WE4.6.5	Se progettiamo e realizziamo un quadro generale per specificare i requisiti che i membri di un gruppo locale o globale devono soddisfare, utilizzeremo tale quadro per garantire che i membri del gruppo temporary-account-ip-viewer soddisfino i requisiti delle politiche esistenti.
WE4.6.6	Se analizziamo il modo in cui gli utenti con diritti estesi (UWER) fanno affidamento sugli script utente, saremo in grado di proporre un piano, che la comunità UWER potrebbe sostenere, per apportare uno o più interventi tecnici significativi che garantirebbero in modo significativo la sicurezza del sistema degli script utente.
WE4.6.7	Se valutiamo l'esperienza utente e le modifiche tecniche necessarie alle app mobili native per allineare l'esperienza di accesso mobile alla piattaforma web, attraverso l'esplorazione di meccanismi alternativi come OAuth, possiamo determinare la fattibilità dell'integrazione, nell'interesse di fornire un'esperienza più sicura e coerente agli utenti.
WE4.6.8	Se monitoriamo l'impatto dei moduli Zendesk e MediaWiki che abbiamo creato nel primo trimestre, potremo proporre interventi tecnici per i trimestri futuri che consentano di automatizzare meglio il resto del processo di recupero dell'account.
WE5.1.2b	Se integriamo più metodi per l'identificazione e l'autenticazione degli sviluppatori nel gateway API, saremo in grado di assegnare un limite di velocità appropriato a ciascuna richiesta, identificando correttamente le richieste provenienti da diversi gruppi di utenti.
WE5.1.3b	Se eseguiamo una simulazione per la limitazione della velocità su almeno 3 percorsi del gateway REST, potremo verificare la fattibilità della limitazione della velocità rispetto al consumo di risorse e definire una serie iniziale di limiti che potrebbero essere applicati con un impatto minimo sugli utenti.
WE5.1.4b	Se convalidiamo i meccanismi di segmentazione degli utenti API proposti con set di dati più ampi e revisioni manuali dei gruppi identificati, saremo in grado di finalizzare le coorti di utenti, perfezionare le metodologie utilizzate per il calcolo e comprenderne meglio l'efficacia.
WE5.1.5	Se collaboriamo con il team della piattaforma MediaWiki sull'identificazione del traffico e la limitazione della velocità, saremo in grado di implementare la limitazione della velocità per i test di prova in produzione, supportando il team della piattaforma nella creazione e nell'implementazione di questa funzionalità.
WE5.2.1b	Se coinvolgiamo i potenziali utenti del nuovo REST API Explorer, questo ci aiuterà a identificare informazioni chiave sull'usabilità che indicano se il nuovo design è facile da usare e in linea con il modello mentale degli sviluppatori.
WE5.2.2b	Se instradiamo l'API Action attraverso il gateway API centrale, possiamo iniziare a misurare in modo coerente il traffico e i modelli di utilizzo per ottenere informazioni utili a guidare le decisioni e le azioni future.
WE5.2.4	Se implementiamo modelli di documentazione standard per 2 API, saremo in grado di perfezionare le linee guida sui contenuti, comprendere ciò di cui hanno bisogno i proprietari delle API per adottare le linee guida e quantificare lo sforzo necessario per implementare le linee guida in tutti i restanti documenti API di Wikimedia.
WE5.2.5	Se sperimentiamo la definizione e l'applicazione delle regole di linting delle specifiche OpenAPI alle API REST di MediaWiki, dimostreremo un modo per applicare programmaticamente le guide di stile delle API al fine di migliorare la qualità e la coerenza delle API pubblicate su Wikimedia e nelle nostre comunità.
WE5.3.1	Se ampliamo e semplifichiamo le linee guida sull'attribuzione dell'esperienza utente aggiornando al contempo quelle esistenti, creeremo una serie di linee guida migliorate pronte per essere testate internamente e perfezionate in modo iterativo, in vista di un utilizzo pubblico più ampio.
WE5.3.1b	Se pubblichiamo e iteriamo la bozza delle linee guida UX e le demo, creeremo un framework di base pronto per essere testato internamente e perfezionato in modo iterativo, in modo da essere pronti per un uso pubblico più ampio.
WE5.3.2	Se creiamo una presentazione che dimostri i vantaggi dell'attribuzione di Wikipedia ai riutilizzatori di contenuti di terze parti e ai loro utenti finali, potremo supportare WME4.1 e WME4.2 consentendo ad almeno un altro partner di riutilizzo di accettare di partecipare a un caso di studio o a una demo sull'attribuzione entro la fine del primo trimestre.
WE5.4.2b	Se creiamo un metodo scalabile per identificare i clienti noti, possiamo consentire eccezioni ai limiti di velocità generali per i bot di origine verificata e passare all'applicazione sistematica delle nostre regole.
WE5.4.5	Se iniziamo ad applicare limiti di velocità personalizzati per diverse classi di singoli clienti, ridurremo il carico di crawling sulla nostra infrastruttura.
WE5.4.6	Se entro la fine del secondo trimestre avremo classificato i primi N spider come bot noti, potremo limitare la quantità di risorse che utilizzano.
WE5.4.7	Se stabiliamo una serie standardizzata di dimensioni consentite per le miniature sulla nostra infrastruttura multimediale e pregeneriamo quelle più costose limitando la velocità di generazione delle diverse dimensioni delle immagini, ridurremo il carico sull'infrastruttura di distribuzione multimediale.
WE6.1.2	Se aggiungiamo le wikifarms a un ambiente di test pre-merge, ciò consentirà ai team di sviluppo che lavorano sulla produzione e che necessitano di più wiki per testare le loro patch in modo isolato, di acquisire maggiore fiducia nella pre-produzione e di ridurre il numero di difetti sfuggiti al controllo.
WE6.2.1	Se rivediamo e pubblichiamo la nostra Checklist di preparazione alla produzione che definisce chiaramente i prerequisiti affinché un servizio sia considerato pronto per la produzione, insieme alle attività che possono essere svolte autonomamente, allineeremo le aspettative tra gli SRE e i team di sviluppo, migliorando la nostra efficienza operativa complessiva e la scalabilità.
WE6.2.2	Se annunciamo la creazione di una libreria Golang e nodejs che semplifica molte attività laboriose per gli sviluppatori, questi risponderanno offrendo feedback e manifestando interesse.
WE6.2.4	Se applichiamo e sosteniamo attivamente la revisione del progetto Data Persistence, potremo identificare percorsi già tracciati verso la produzione.
WE6.3.2	Se sviluppiamo nuovi parametri di misurazione, miglioriamo l'infrastruttura cache di Parsoid e lo implementiamo su due delle dieci principali wikipedia, svilupperemo criteri di prestazione per il quadro di affidabilità, che ci aiuteranno a convalidare la nostra preparazione per l'implementazione su altri wiki di grandi dimensioni e a dimostrare la nostra capacità di gestire volumi di traffico elevati su larga scala.
WE6.3.3	Se implementeremo miglioramenti fondamentali al supporto delle varianti linguistiche e distribuiremo con successo Parsoid ad almeno 3 wiki in varianti linguistiche nel secondo trimestre, identificheremo e risolveremo le principali sfide tecniche necessarie per estendere con sicurezza il servizio a tutte le restanti wiki in varianti linguistiche.
WE6.4.6	Se SRE fornisce assistenza ai team di ingegneri MediaWiki - attraverso la gestione della capacità e del traffico, la preparazione e la revisione delle modifiche di configurazione e la collaborazione per indagare e risolvere i problemi - completeremo insieme l'aggiornamento di produzione a PHP 8.3 nel secondo trimestre e documenteremo una serie di raccomandazioni per ridurre al minimo le dipendenze critiche da SRE per gli aggiornamenti futuri.	T360995
WE6.4.7	Se migriamo almeno il 90% di tutti gli utenti con accesso root globale all'utilizzo di una chiave SSH supportata da hardware per accedere ai server di produzione Wikimedia, ridurremo il rischio che un laptop compromesso causi una grave violazione della sicurezza.
WE6.4.8	Se il team di ingegneri MediaWiki monitorerà attivamente e risolverà i problemi relativi all'aggiornamento PHP in MediaWiki, il team SRE potrà completare l'aggiornamento PHP 8.3 entro novembre 2025.	T360995

Servizi di segnalazione e dati (SDS) Ipotesi [ Risultati chiave dei SDS ] Discussione
Nome abbreviato delle ipotesi	Testo del secondo trimestre	Dettagli e Discussione
SDS1.2.1	Se migriamo il processo di dump XML dall'attuale infrastruttura “Dumps 1” a una pipeline di dati che sfrutta le pipeline di contenuti MediaWiki, saremo in grado di garantire gli SLO e disattivare l'esportazione XML basata su “Dumps 1”.
SDS1.2.2	Se eseguiamo una verifica e rivediamo gli SLO per MediaWiki Content History ed Event Platform / Event Gate, possiamo convalidare i clienti, le metriche e gli stakeholder dipendenti e identificare i miglioramenti che potrebbero essere necessari per gli SLO, il che ci aiuterà a chiarire eventuali lacune nelle nostre garanzie di consegna settimanali.
SDS1.3.1	Se introduciamo segnali del lato del client e li controlliamo confrontandoli con i log delle richieste web sul lato server, troveremo ulteriori modelli di bot che possono essere caratterizzati.
SDS1.3.2	Se prendiamo come riferimento l'attuale distribuzione bot/umani e creiamo avvisi automatici per i cambiamenti nella distribuzione, ridurremo il tempo di rilevamento del prossimo modello imprevedibile di traffico automatizzato da settimane a minuti.
SDS1.3.3	Se automatizziamo il meccanismo di backfill per le richieste web e lo utilizziamo sui log di maggio, ridurremo i tempi di risoluzione dei futuri incidenti da mesi a giorni e risolveremo l'incidente relativo all'"aumento delle visualizzazioni di pagina nel mese di maggio."
SDS1.3.4	Se creiamo un processo di audit interno regolare e operativo per i risultati della classificazione dei bot, rafforzeremo la fiducia nelle nostre soluzioni e potremo anticipare i cambiamenti nei modelli di traffico che non vengono rilevati automaticamente.
SDS1.3.5	Se analizziamo il segnale di base del lato del client e lo incorporiamo nella nostra euristica, rileveremo ulteriori modelli di bot nella piattaforma dati.
SDS1.3.6	Se importiamo, analizziamo e incorporiamo nella nostra euristica la reputazione IP di Spur.us, rileveremo ulteriori modelli di bot nella piattaforma dati.
SDS1.3.7	Se importiamo, analizziamo e incorporiamo nella nostra euristica un segnale proveniente dal margine, rileveremo ulteriori modelli di bot nella piattaforma dati.
SDS1.4.1	Se riconfermiamo le analisi esistenti sulle tendenze all'interno dell'ecosistema Wikimedia (visualizzazioni di pagina, metriche relative ai contributori e ai lettori, traffico, ecc.), saremo in grado di sostenere con sicurezza i punti salienti delle nostre intuizioni più importanti sul movimento.
SDS1.4.2	If we reconfirm existing analyses of trends within the Wikimedia ecosystem (page views, contributor and reader metrics, traffic, etc.), we will be able to confidently support the key points of our most important insights about the movement.
SDS2.1.1	Se collaboriamo strettamente con i team che conducono gli esperimenti, impareremo come rendere il sistema più self-service in futuro e quali sfide concettuali o tecniche potrebbero incontrare.
SDS2.1.2	Se riusciamo a implementare un debug migliore per la registrazione degli eventi, i team di prodotto sapranno che il loro esperimento sta raccogliendo i dati degli eventi come previsto, aumentando la fiducia dei responsabili dell'esperimento.
SDS2.1.3	Se miglioriamo la registrazione e l'osservabilità per il componente del sistema di test A/B (xLab) della piattaforma di sperimentazione e per le relative parti MediaWiki, saremo in grado di stabilire delle linee guida per le prestazioni del sistema e rispondere ai guasti relativi agli esperimenti.
SDS2.1.4	Se condividiamo le storie e i risultati degli esperimenti all'interno dell'organizzazione una volta al mese (attraverso riunioni del reparto Product Ops, riunioni del team di progettazione e presentazioni tra i vari team), creeremo un'adozione organica della piattaforma di sperimentazione.
SDS2.1.5	Se comunichiamo agli utenti che il loro strumento, se creato in xLab, contiene una serie di attributi che modificano la categoria di rischio, scoraggeremo gli utenti della strumentazione dall'effettuare una raccolta eccessiva di dati e aumenteremo la chiarezza su quale combinazione di attributi richiede una revisione della privacy.
SDS2.1.6	Se il Growth Team lavora alla strumentazione di 2 casi d'uso (uno con un test A/B per ottenere informazioni sulle capacità di bucketing e uno con strumentazione a lungo termine per conoscere il supporto per metriche simili ai KPI) con l'Experiment Lab, allora potremo valutare se soddisfa sufficientemente i requisiti per sostituire la nostra configurazione di esperimenti personalizzata in GrowthExperiments.

Ipotesi del Future Audience (FA) [ Risultati chiave del FA ] Discussione
Nome abbreviato delle ipotesi	Testo del secondo trimestre	Dettagli e Discussione
FA1.1.4	[Continua dall'ultimo anno fiscale] Se creeremo una nuova esperienza Wikipedia su Roblox, scopriremo se questo potrebbe essere un modo efficace per presentare il nostro marchio al pubblico più giovane (Generazione Alpha).
FA1.1.2	Se creiamo un hub centrale per nuove esperienze Wikipedia su itch.io, potremo ampliare il nostro pubblico di oltre 50 utenti non wikipediani interessati che ci forniranno feedback, aiutandoci a capire cosa funziona e cosa no nei giochi.
FA2.2.1	Se investiamo nella gestione della community sulle piattaforme di video brevi, entro la fine del secondo trimestre (dicembre 2025) assisteremo a un aumento del 30% su base trimestrale della percentuale di visualizzazioni da parte di nuovi spettatori su TikTok e, su tutte le piattaforme SFV, otterremo un totale di 50.000 interazioni (like e commenti di risposta) sui commenti del marchio lasciati su contenuti esterni, il che ci aiuterà ad aumentare la visibilità e a stimolare il coinvolgimento di un pubblico che attualmente non riusciamo a raggiungere.
FA2.2.2	Se sviluppiamo e otteniamo l'approvazione di una strategia interna e di contenuti condivisibili esterni per il programma di partnership con i Creator di Wikipedia (compresa una descrizione del nostro valore per i creator, i criteri di partnership, il processo di contrattazione e le modalità di visualizzazione dei contenuti dei creator sui canali di proprietà e sui canali dei creator), saremo in grado di stabilire una solida strategia per i creator che ci aiuterà a raggiungere un nuovo pubblico sui social media con i nostri contenuti informativi.

Ipotesi del Product e Engineering Support (PES) [ Risultati chiave del PES ] Discussione
Nome abbreviato delle ipotesi	Testo del secondo trimestre	Dettagli e Discussione
PES1.1.5	Se integriamo gli obiettivi di livello di servizio (SLO) per MediaWiki Content History e Wikifunctions in Sloth/Pyrra, avremo altri 2 SLO in produzione.
PES1.1.6	Se testiamo Sloth con dati retroattivi provenienti dagli SLO esistenti, capiremo se Pyrra o Sloth (o qualcos'altro) è lo strumento giusto per il nostro approccio a finestra fissa alle finestre di budget di errore. Impareremo come supportare i proprietari dei servizi con un approccio self-service alle metriche SLO e come utilizzarle nel processo decisionale.
PES1.2.4	Se nel primo trimestre sperimentiamo un processo trimestrale di revisione dei desideri e dei segnali della comunità con 3 team, coinvolgeremo i Product Manager affinché integrino i segnali della comunità nei loro processi di pianificazione trimestrale e annuale.
PES1.2.5	Se aggiungiamo la possibilità di filtrare e ordinare i desideri nell'estensione Wishlist ai miglioramenti che consentono la categorizzazione con tag e votazioni, i 3 miglioramenti aumenteranno di almeno il 30% il numero di partecipanti unici nella Wishlist.
PES1.3.3	Se creiamo almeno 5 interventi piacevoli sulla piattaforma che si verificano in base alle interazioni degli utenti, definiremo quali saranno i trigger per la pagina del portale e il gadget Birthday Mode. I test di usabilità ci diranno quali interventi creano associazioni positive con il nostro marchio. Questa ipotesi ha una scadenza fissata per la fine di ottobre, in concomitanza con il WikiCon North America.
PES1.3.4	Se creiamo un sito web coinvolgente che esplora la storia, il presente e il futuro di Wikipedia, in collaborazione con i membri del reparto Comunicazione, con l'obiettivo di coinvolgere il pubblico online tra i 18 e i 34 anni nelle aree target della campagna, simuleremo una maggiore connessione con Wikipedia tramite condivisioni sui social e altre attività online. Ciò contribuirà al KR di Comunicazione di aumentare la presenza del marchio di 10 punti percentuali, indicandoci al contempo se approcci dinamici ai contenuti migliorano la gradibilità del marchio.

Q3

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

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

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

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

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

Q4

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

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

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

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

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

Pianificare insieme

Aggiornamento di Gennaio 2025

Il piano annuale è la descrizione di ciò che la Wikimedia Foundation spera di realizzare nell'anno successivo. Lavoriamo duramente per rendere il piano partecipativo, aspirazionale e realizzabile. Ogni anno, chiediamo ai contributori di condividere le loro prospettive, speranze e richieste specifiche per dare forma al piano. Alcuni dei modi in cui cerchiamo di ottenere questo contributo sono le conversazioni dei team di prodotto con le comunità, la Community Wishlist, le discussioni con la comunità come la serie di conversazioni Commons, le conferenze e le pagine wiki come questa.

Per il nostro prossimo piano annuale, da luglio 2025 a giugno 2026, stiamo pensando a come servire al meglio una visione multigenerazionale, visti i rapidi cambiamenti nel mondo e in Internet e il modo in cui ciò influisce sulla nostra missione di conoscenza gratuita.

Come ho detto l'anno scorso, dobbiamo concentrarci su ciò che ci contraddistingue: la nostra capacità di fornire contenuti attendibili anche quando la disinformazione e la cattiva informazione proliferano su Internet e sulle piattaforme che si contendono l'attenzione delle nuove generazioni. Ciò include garantire il raggiungimento della missione di assemblare e fornire al mondo la somma di tutte le conoscenze umane, ampliando la copertura delle informazioni mancanti, che possono essere causate da iniquità, discriminazione e pregiudizi. I nostri contenuti devono anche servire e rimanere vitali in un Internet in evoluzione, guidato dall'intelligenza artificiale e da esperienze arricchite. Infine, dobbiamo trovare il modo di finanziare in modo sostenibile il nostro movimento, costruendo una strategia condivisa per i nostri prodotti e la raccolta di fondi, in modo da poter sostenere questo lavoro a lungo termine.

Per fare scelte e compromessi su dove concentrare i nostri sforzi nel prossimo anno, abbiamo raccolto domande e riflettuto su come allocare le nostre risorse limitate per ottenere il massimo impatto.

Se sei interessato in modo specifico alle caratteristiche o ai servizi che il dipartimento Prodotti e Tecnologia realizzerà in base alle priorità qui stabilite, a marzo ci sarà tempo per commentare gli obiettivi specifici e i risultati chiave. (A titolo di riferimento, ecco gli obiettivi e i risultati chiave dell'attuale piano annuale).

Se vuoi riflettere sulle sfide e le opportunità del nostro ambiente tecnico e sulla direzione che dovremmo seguire nel prossimo piano annuale, ti invitiamo a considerare insieme a noi le domande riportate di seguito.

Riceviamo continuamente informazioni su queste domande in molti modi: dalle conversazioni della comunità, dai dati che raccogliamo, dalle interviste di ricerca che facciamo e altro ancora. Non è la prima volta che ci chiediamo e impariamo a conoscere molte di queste cose - e su molte di esse abbiamo già lavorato! Vogliamo chiederle ancora una volta e continuare a imparare, perché in questa fase della nostra pianificazione sono per noi di primaria importanza.

Domande:

Metriche e dati
- Quali sono i modi in cui i dati e le metriche potrebbero supportare meglio il vostro lavoro di redattori? Riesci a pensare a dati relativi all'editing, alla lettura o all'organizzazione che ti aiuterebbero a scegliere come impiegare il tuo tempo o a quando è necessario prestare attenzione a qualcosa? Potrebbero essere dati sulla tua attività o su quella degli altri.
Editing
- Quando l'editing ti sembra più gratificante e divertente? Quando è più frustrante e difficile?
- Vogliamo che i collaboratori ricevano più feedback e riconoscimenti per il loro lavoro, in modo che non sembri che nessuno non si accorga dell'impegno che dedicano alle wiki. Che tipo di feedback e di riconoscimento ti motivano? Cosa ti spinge a continuare a modificare?
- Poiché le wiki sono così grandi, può essere difficile per i redattori decidere a quale lavoro sulla wiki è più importante dedicare il proprio tempo ogni giorno. Quali informazioni o strumenti potrebbero aiutarti a scegliere come impiegare il tuo tempo? Sarebbe utile avere un luogo centrale e personalizzato che ti permetta di trovare nuove opportunità, gestire i tuoi compiti e capire il tuo impatto?
- Vogliamo migliorare l'esperienza di collaborazione sulle wiki, in modo che sia più facile per i collaboratori trovarsi l'un l'altro e lavorare insieme ai progetti, sia che si tratti di unità di arretrati, di edit-a-thon, di WikiProject o anche di due redattori che lavorano insieme. Come pensi che potremmo aiutare più collaboratori a trovarsi, a connettersi e a lavorare insieme?
Lettura/Imparare
- Le wiki si caricano più velocemente o più lentamente a seconda della zona del mondo in cui si vive. Ci sono parti del mondo in cui ritieni che sia necessario migliorare le prestazioni?
- Come possiamo aiutare le nuove generazioni di lettori a trovare i contenuti di Wikipedia interessanti e coinvolgenti? In passato, abbiamo discusso di idee relative ai contenuti interattivi e ai video e, nell’anno in corso, ci siamo concentrati sui grafici e sulla sperimentazione di nuovi modi di visualizzare i contenuti esistenti di Wikipedia. Come potremmo continuare su questa strada per utilizzare i nostri contenuti esistenti in modi nuovi e unici per Wikimedia?
Moderatori
- Cosa dovrebbe cambiare in Wikipedia affinché più persone vogliano essere coinvolte in ruoli di volontariato avanzati, come quelli di patrollers o amministratori?
- Quali informazioni o contesti sulle modifiche o sugli utenti potrebbero aiutarti a prendere decisioni di patrolling o di amministrazione in modo più rapido o semplice?
Tendenze esterne
- Quali sono i cambiamenti più importanti che stai notando nel mondo al di fuori di Wikimedia? Potrebbero essere tendenze nella tecnologia, nell'istruzione o nel modo in cui le persone imparano.
- Al di fuori del movimento Wikimedia, a quali altre comunità online partecipi? Quali lezioni possiamo trarre dagli strumenti e dai processi di altre piattaforme comunitarie?
- Come utilizzi gli strumenti di intelligenza artificiale all'interno e all'esterno del vostro lavoro su Wikimedia? Per cosa trovate utile l'AI?
Commons
- Quali decisioni possiamo prendere con la comunità Commons per creare un progetto sostenibile che supporti la creazione di conoscenza enciclopedica?
Wikidata
- Come vorresti vedere Wikidata evolversi in futuro? Come può essere più utile per costruire contenuti enciclopedici affidabili?

Discussione

–– Selena Deckelmann