Piano annuale di Wikimedia Foundation/2024-2025/OKR del dipartimento Product & Technology
Questo documento rappresenta la prima parte del processo di pianificazione annuale 2024-2025 per il dipartimento Product & Technology di Wikimedia Foundation. Descrive la bozza degli "obiettivi e risultati chiave" (OKR) del dipartimento. Questo documento è la continuazione della struttura dei portfolio di lavoro (chiamati "buckets") iniziata l'anno scorso.
.jpg)
A novembre ho parlato con tutti voi di quella che credo sia la questione più urgente che il movimento Wikimedia deve affrontare: come possiamo garantire che Wikipedia e tutti i progetti Wikimedia siano multigenerazionali? Vorrei ringraziare tutti coloro che si sono presi il tempo di riflettere su questa domanda e di rispondermi direttamente, e ora che ho avuto la possibilità di esaminare le vostre risposte, condividerò ciò che ho potuto notare.
Innanzitutto, non esiste un motivo unico per cui i volontari contribuiscono. Per favorire più generazioni di volontari, dobbiamo analizzare meglio le diverse ragioni per cui le persone contribuiscono ai nostri progetti. Poi, dobbiamo concentrarci su ciò che ci distingue: la nostra capacità di fornire contenuti affidabili mentre la disinformazione prolifera su Internet e sulle piattaforme che si contendono l'attenzione dalle nuove generazioni. Ciò include garantire il conseguimento della nostra missione di raccogliere e fornire al mondo la totalità della conoscenza umana, ampliando la nostra copertura di informazioni mancanti, dovute a disuguaglianze, discriminazioni o pregiudizi. I nostri contenuti devono servire e rimanere vitali in un Internet in evoluzione, guidato dall'intelligenza artificiale e altre esperienze . Infine, dobbiamo trovare modalità di finanziamento sostenibile del nostro movimento, costruendo una strategia condivisa per i nostri prodotti e le nostre entrate, in modo da poter finanziare questo lavoro a lungo termine.
Queste idee si ritroveranno nel piano annuale 2024-2025 di Wikimedia Foundation, la cui prima parte condivido con voi oggi sotto forma di bozza degli obiettivi per il nostro lavoro su prodotto e tecnologia. Come l'anno scorso, il nostro intero piano annuale sarà incentrato sulle esigenze tecnologiche del nostro pubblico e delle nostre piattaforme, e vorremmo ricevere un vostro feedback per sapere se ci stiamo concentrando sulle giuste questioni. Questi obiettivi si basano sulle idee che abbiamo ricevuto dai membri della community negli ultimi mesi attraverso Talking:2024, nelle mailing list, nelle pagine di discussione e agli eventi della community riguardanti la nostra strategia di prodotto e tecnologia per l'anno a venire. L'elenco completo delle bozze degli obiettivi è riportato di seguito.
Un "obiettivo" è una direzione di alto livello che darà forma ai progetti di prodotto e tecnologia che intraprenderemo nel prossimo anno fiscale. Sono intenzionalmente ampi, rappresentano la direzione della nostra strategia e, soprattutto, le sfide che proponiamo di privilegiare tra le molte aree di interesse possibili per il prossimo anno. Lo condividiamo ora, in modo che i membri della community possano contribuire a definire il nostro pensiero iniziale, prima che vengano impegnati dei budget e obiettivi misurabili per l'anno prossimo.
Feedback
Un ambito in cui vorremmo ricevere un feedback è il nostro lavoro raggruppato sotto il nome di "Esperienze Wiki" (Wiki Experiences). "Esperienze Wiki" riguarda il modo in cui offriamo, miglioriamo e innoviamo in modo efficiente l'uso diretto dei wiki da parte delle persone, che siano volontari, consumatori o donatori. Ciò comporta un lavoro di supporto alla nostra tecnologia di base e alle nostre capacità, nonché la garanzia di poter migliorare l'esperienza degli editor volontari – in particolare, gli editor con diritti estesi – attraverso migliori funzionalità e strumenti, servizi di traduzione e aggiornamenti della piattaforma.
Ecco alcune riflessioni tratte dalle nostre recenti discussioni sulla pianificazione, e alcune domande per tutti voi per aiutarci a perfezionare le nostre idee:
- Il volontariato nei progetti Wikimedia dovrebbe essere gratificante. Pensiamo anche l'esperienza di collaborazione online dovrebbe essere una parte fondamentale di ciò che fa tornare i volontari. Che cosa occorre affinché i volontari trovino gratificante l'attività di editing e lavorino meglio insieme per creare contenuti affidabili?
- L'affidabilità dei nostri contenuti è parte del contributo unico di Wikimedia al mondo e ciò che spinge le persone a visitare la nostra piattaforma e a usare i nostri contenuti. Cosa possiamo costruire per far crescere più rapidamente i contenuti affidabili, pur rimanendo all'interno dei limiti di qualità stabiliti dalle comunità per ogni progetto?
- Per rimanere importante e competere con le altre grandi piattaforme online, Wikimedia ha bisogno di una nuova generazione di consumatori che si sentano coinvolti dai nostri contenuti. Come possiamo rendere i nostri contenuti più facili da scoprire e da consultare per i lettori e i donatori?
- In un'epoca in cui gli abusi online prosperano, dobbiamo assicurarci che le nostre community, la nostra piattaforma e il nostro sistema di servizi siano protetti. Dobbiamo anche far fronte all'evoluzione degli obblighi di conformità, in cui i responsabili politici globali cercano di definire la privacy, l'identità e la condivisione delle informazioni online. Quali miglioramenti alle nostre capacità di contrastare gli abusi ci possono aiutare ad affrontare queste sfide?
- MediaWiki, la piattaforma software e le interfacce che permettono a Wikipedia di funzionare, ha bisogno di un supporto continuo per il prossimo decennio, al fine di garantire la creazione, la moderazione, l'archiviazione, la scoperta e il consumo di contenuti aperti e multilingue su scala. Quali decisioni e miglioramenti della piattaforma possiamo prendere quest'anno per garantire la continuità di MediaWiki?
Obiettivi bozza
Al momento è pubblicato il livello più elevato di pianificazione - gli "obiettivi".
Il livello successivo - la bozza "risultati chiave" (KR) per ogni obiettivo finalizzato è fornito di seguito.
Le "ipotesi" sottostanti per ogni KR verranno aggiornate sulle pagine dei progetti/team di lavoro durante l'anno e adeguate a quanto appreso.
| Bozza degli obiettivi Wiki Experiences (WE) | ||||
|---|---|---|---|---|
| Obiettivo | Area di riferimento | Obiettivo | Contesto | Owner |
| WE1 | Esperienza del collaboratore | Collaboratori esperti e nuovi si riuniscono online per costruire un'enciclopedia affidabile, con più facilità e meno frustrazione. | Affinché Wikipedia sia solida anche negli anni a venire, dobbiamo realizzare un progetto che favorisca più generazioni di volontari e che renda il contributo qualcosa che le persone desiderano fare. Generazioni diverse di volontari hanno bisogno di investimenti diversi: i collaboratori più esperti hanno bisogno che i loro potenti flussi di lavoro siano ottimizzati e riparati, mentre i nuovi collaboratori hanno bisogno di nuovi modi di editing che abbiano senso per loro. Inoltre, tutti i collaboratori di diverse generazioni devono essere in grado di connettersi e collaborare tra loro per svolgere il loro lavoro nel modo più efficace. Con questo obiettivo, miglioreremo i flussi di lavoro critici per i collaboratori esperti, abbasseremo le barriere ai contributi costruttivi per i nuovi arrivati e investiremo in modo che i volontari possano trovare e comunicare tra loro in base a interessi comuni. | Marshall Miller |
| WE2 | Contenuto enciclopedico | Le comunità sono aiutate a colmare in modo efficace le lacune di conoscenza attraverso strumenti e sistemi di supporto più facili da accedere, adattare e migliorare, garantendo una maggiore crescita di contenuti enciclopedici affidabili. | I contenuti enciclopedici presenti su Wikipedia possono essere incrementati e migliorati attraverso un impegno e un'innovazione continui. Gli strumenti e le risorse (tecniche e non) che sono a disposizione dei contributori per le loro esigenze possono essere resi più accessibili e affidabili. Questi strumenti dovrebbero essere supportati maggiormente da WMF, attraverso miglioramenti delle funzionalità realizzabili in cicli brevi. Alla luce delle recenti tendenze sulla generazione di contenuti assistita dall'intelligenza artificiale e sul cambiamento del comportamento degli utenti, esploreremo anche le basi per cambiamenti sostanziali (ad esempio, le Wikifunctions) che possono aiutare la crescita su scala della creazione e del riutilizzo dei contenuti. I meccanismi per identificare le lacune di contenuto dovrebbero essere più facili da scoprire e da programmare. Le risorse che supportano la crescita dei contenuti enciclopedici, compresi i contenuti dei progetti affiliati, i progetti come la Wikipedia Library e le campagne, possono essere meglio integrate nei flussi di lavoro dei contributi. Al tempo stesso, i metodi utilizzati per la crescita dovrebbero avere delle protezioni contro le minacce crescenti, in grado di garantire una fiducia costante nel procedimento, pur rimanendo fedeli ai principi fondamentali del contenuto enciclopedico, come riconosciuto nei progetti Wikimedia.
Pubblico: volontari, traduttori |
Runa Bhattacharjee |
| WE3 | Esperienza del consumatore (lettura & media) | Una nuova generazione di consumatori si rivolge a Wikipedia per scoprire una destinazione privilegiata per conoscere, coinvolgere e creare un legame duraturo con i contenuti enciclopedici. | Obiettivi:
Mantenere le attuali e nuove generazioni di consumatori e donatori. Aumentare la rilevanza per le generazioni esistenti e nuove di consumatori rendendo i nostri contenuti più facili da scoprire e da interagire. Lavorare su più piattaforme per adattare le nostre esperienze e i contenuti esistenti, in modo che i contenuti enciclopedici possano essere esplorati e curati da e per una nuova generazione di consumatori e donatori. |
Olga Vasileva |
| WE4 | Trust & Safety | Migliorare la nostra infrastruttura, i nostri strumenti e i nostri processi in modo da essere ben equipaggiati per proteggere le community, la piattaforma, e i nostri sistemi di servizi da diversi tipi di abusi in scala e diretti, mantenendo la conformità con un ambiente normativo in evoluzione. | Alcuni aspetti delle nostre capacità di lotta agli abusi hanno bisogno di un aggiornamento. La mitigazione degli abusi basata sull'IP sta diventando meno efficace, diversi strumenti di amministrazione necessitano di miglioramenti in termini di efficienza e dobbiamo mettere a punto una strategia unificata che ci aiuti a combattere gli abusi su larga scala utilizzando di concerto i vari segnali e meccanismi di mitigazione (captchas, blocchi, ecc.). Nel corso di quest'anno, inizieremo a fare progressi sui problemi più gravi in questo settore. Inoltre, questo investimento nella protezione dagli abusi deve essere bilanciato da un investimento nella comprensione e nel miglioramento della sicurezza della comunità, di cui diversi aspetti sono inclusi in vari requisiti normativi. | Suman Cherukuwada |
| WE5 | Piattaforma di conoscenza I (evoluzione della piattaforma) | Evolvere la piattaforma MediaWiki e le sue interfacce per soddisfare al meglio le esigenze principali di Wikipedia. | MediaWiki è stato costruito per consentire la creazione, la moderazione, l'archiviazione, la scoperta e il consumo di contenuti aperti e multilingue su larga scala. In questo secondo anno di Piattaforma di conoscenza daremo uno sguardo curativo al sistema e inizieremo a lavorare per migliorare la piattaforma per supportare efficacemente le esigenze fondamentali dei progetti Wikimedia nel prossimo decennio, a partire da Wikipedia. Ciò include il proseguimento del lavoro di definizione della nostra piattaforma di produzione di conoscenza, il rafforzamento della sostenibilità della piattaforma, l'attenzione al sistema di estensioni/ganci per chiarire e semplificare lo sviluppo delle funzionalità, e il proseguimento degli investimenti nella condivisione della conoscenza e nel consentire alle persone di contribuire a MediaWiki. | Birgit Müller |
| WE6 | Piattaforma di conoscenza II (servizi per gli sviluppatori) | Il personale tecnico e gli sviluppatori volontari hanno gli strumenti necessari per supportare efficacemente i progetti Wikimedia. | Continueremo il lavoro iniziato per migliorare (e ridimensionare) i flussi di lavoro di sviluppo, test e distribuzione in Wikimedia Production ed espanderemo la definizione per includere i servizi per gli sviluppatori di strumenti. Vogliamo anche migliorare la nostra capacità di rispondere alle domande più frequenti nel campo dei flussi di lavoro degli sviluppatori/ingegneri e del pubblico e rendere accessibili i dati pertinenti per consentire un processo decisionale informato. Parte di questo lavoro consiste nell’esaminare le pratiche (o la loro mancanza) che attualmente rappresentano una sfida per il nostro ecosistema | Birgit Müller |
| Obiettivi bozza Signals and Data Services (SDS) | ||||
|---|---|---|---|---|
| Obiettivo | Area di riferimento | Obiettivo | Contesto | Owner |
| SDS1 | Shared insights | Le nostre decisioni su come sostenere la missione e il movimento di Wikimedia sono informate da metriche e dati di alto livello. | Per costruire in modo efficace ed efficiente la tecnologia, supportare i volontari e sostenere le politiche che proteggono e fanno progredire l'accesso alla conoscenza, dobbiamo comprendere l'ecosistema Wikimedia e allinearci sulle caratteristiche del successo. Ciò significa tracciare un insieme comune di metriche che siano affidabili, comprensibili e disponibili in modo tempestivo. Significa anche fa emergere ricerche e approfondimenti che ci aiutino a capire il perché e il come delle nostre misurazioni. | Kate Zimmerman |
| SDS2 | Piattaforma di sperimentazione | I responsabili di prodotto possono valutare in modo rapido, semplice e sicuro l’impatto delle caratteristiche del prodotto. | Per consentire e accelerare il processo decisionale sullo sviluppo delle funzionalità di un prodotto, i product manager 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. | Tajh Taylor |
| Obiettivo bozza Future Audiences (FA) | ||||
|---|---|---|---|---|
| Obiettivo | Area di riferimento | Obiettivo | Contesto | Owner |
| FA1 | Ipositi di prova | Fornire raccomandazioni sugli investimenti strategici che la Wikimedia Foundation deve perseguire, sulla base delle intuizioni degli esperimenti che affinano la nostra comprensione di come la conoscenza viene condivisa e consumata online, per aiutare il nostro movimento a servire un nuovo pubblico in un Internet che cambia. | A causa dei continui cambiamenti nella tecnologia e nel comportamento degli utenti online (ad esempio, la crescente preferenza per l'ottenimento di informazioni tramite app sociali, la popolarità di brevi video di intrattenimento educativo, l'ascesa dell'intelligenza artificiale generativa), il movimento Wikimedia si trova ad affrontare sfide per attrarre e mantenere lettori e collaboratori. Questi cambiamenti portano anche opportunità di servire 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…
Per garantire che Wikimedia diventi un progetto multigenerazionale, verificheremo le 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. |
Maryana Pinchuk |
| Obiettivo bozza Product and Engineering Support (PES) | ||||
|---|---|---|---|---|
| Obiettivo | Area di riferimento | Obiettivo | Contesto | Owner |
| PES1 | Efficienza delle operazioni | Rendere il lavoro della Foundation più veloce, più economico e con maggiore impatto. | Il personale fa molto nel suo lavoro ordinario per rendere le nostre operazioni più rapide, economiche e d'impatto. Questo obiettivo mette in evidenza le iniziative specifiche che: a) consentono di ottenere risultati sostanziali in termini di rapidità, economicità e impatto; b) richiedono uno sforzo coordinato e un cambiamento delle prassi formali e informali della Foundation. In sostanza, i RK inclusi in questo obiettivo sono i miglioramenti più difficili e migliori che possiamo apportare quest'anno all'efficienza operativa del lavoro che tocca i nostri prodotti e la nostra tecnologia. | Amanda Bittaker |
Bozza Key Results
La bozza "risultati chiave" (KR) per ogni obiettivo finalizzato è riportata qui. Essi corrispondono a ciascuno degli obiettivi sopra indicati.
Le "ipotesi" sottostanti per ogni KR saranno aggiornate sulle pagine wiki del progetto o del team in questione nel corso dell'anno, seguendo le informazioni acquisite.
| Wiki Experiences (WE) Bozza risultati chiave | |||
|---|---|---|---|
| Nome abbreviato del risultato chiave | Testo del risultato chiave | Contesto del risultato chiave | Responsabile |
| WE1.1 | Sviluppare o migliorare un flusso di lavoro che aiuti i contributori con interessi comuni a connettersi tra loro e a contribuire insieme. | Riteniamo che gli spazi comunitari e le interazioni sui wiki rendano le persone più felici e più produttive come contributori. Inoltre, gli spazi comunitari aiutano ad accogliere e guidare i nuovi arrivati, a modellare le migliori pratiche di contribuzione e a colmare le lacune conoscitive. Tuttavia, le risorse, gli strumenti e gli spazi esistenti che supportano la connessione interpersonale sui wiki sono insufficienti e non soddisfano le sfide e le esigenze della maggior parte dei contributori di oggi. Nel frattempo, il lavoro del team Campaigns ha dimostrato che molti organizzatori sono desiderosi di adottare e sperimentare nuovi strumenti con flussi di lavoro strutturati che li aiutino nel loro lavoro comunitario. Per queste ragioni, vogliamo concentrarci sull'incoraggiare e promuovere un senso di appartenenza tra i contributori ai wiki. | Ilana Fried |
| WE1.2 | Attivazione costruttiva: #% di aumento annuale della percentuale di nuovi arrivati che pubblicano ≥1 modifica costruttiva nel namespace principale su un dispositivo mobile. |
Le attuali esperienze di editing a pagina intera richiedono troppo contesto, pazienza e tentativi ed errori affinché molti nuovi arrivati possano contribuire in modo costruttivo. Per sostenere una nuova generazione di volontari, aumenteremo il numero e la disponibilità di flussi di lavoro di editing più piccoli, strutturati e specifici per le attività (ad esempio Controllo delle modifiche e Incarichi strutturati).
Nota: le linee di base saranno stabilite solo verso la fine del quarto trimestre dell'anno fiscale in corso, dopo di che sarà stabilita anche la nostra percentuale della metriche obiettivo dei KR. |
Peter Pelberg |
| WE1.3 | Aumentare la soddisfazione degli utenti nei 4 prodotti di moderazione del X%. | I contributori con diritti estesi utilizzano un'ampia gamma di funzioni, estensioni, strumenti e script esistenti per svolgere compiti di moderazione sui progetti Wikimedia. Quest'anno vogliamo concentrarci sul miglioramento di questi strumenti, piuttosto che intraprendere progetti per creare nuove funzionalità in questo spazio. Nel corso dell'anno intendiamo intervenire su diversi prodotti, apportando a ciascuno di essi miglioramenti significativi. In questo modo speriamo di migliorare l'esperienza di moderazione dei contenuti in generale. Definiremo X% a partire dalla misurazione delle linee di base per alcuni strumenti comuni per i moderatori, che potrebbero essere oggetto di questo flusso di lavoro. La Wishlist comunitaria contribuirà in modo sostanziale a decidere le priorità di questo KR. We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR. |
Sam Walton |
| WE2.1 | Entro la fine del secondo trimestre, supportare gli organizzatori, contributori e istituzioni con strumenti, informazioni e approcci organizzativi specifici che aumentino la copertura di contenuti di qualità in aree tematiche chiave [TBD] del X%. | Questo KR è volta a migliorare la copertura degli argomenti per ridurre le lacune conoscitive esistenti. Abbiamo stabilito che le comunità traggono beneficio da strumenti efficaci abbinati a campagne mirate ad aumentare la qualità del contenuto dei nostri progetti. Quest'anno vogliamo concentrarci sul miglioramento degli strumenti esistenti e sulla sperimentazione di nuovi modi per dare priorità alle aree tematiche chiave che affrontano le lacune conoscitive. Il nostro obiettivo di aumento dell'X% della copertura sarà determinato esaminando i parametri di riferimento esistenti per la creazione di contenuti di qualità. Inoltre, le aree tematiche su cui ci concentreremo con le comunità e le istituzioni saranno determinate entro il prossimo trimestre. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | Entro la fine del secondo trimestre, implementare e testare due raccomandazioni, sia sociali sia tecniche, per supportare l'inserimento delle lingue nelle piccole comunità linguistiche, con una valutazione per analizzare il feedback della comunità. | Esistono edizioni di Wikipedia in circa 300 lingue. Eppure, ci sono molte altre lingue, parlate da milioni di persone, in cui non esiste Wikipedia e nessun wiki. Questo è un ostacolo alla realizzazione della nostra visione: che ogni singolo essere umano possa condividere liberamente nella somma di tutte le conoscenze. L'Incubatore Wikimedia è il luogo in cui i potenziali wiki del progetto Wikimedia nelle nuove versioni linguistiche possono essere organizzati, scritti, testati e dimostrati degni di essere ospitati da Wikimedia Foundation. L'Incubatore è stato lanciato nel 2006 con il presupposto che i suoi utenti avessero una conoscenza pregressa dell'editing di wiki. Questo problema è aggravato dal fatto che questo processo dovrebbe essere eseguito per lo più da persone che sono le più nuove e le meno esperte nel nostro movimento. Mentre l'editing sui wiki di Wikimedia è migliorato significativamente da allora, l'Incubatore non ha ricevuto questi aggiornamenti a causa di limitazioni tecniche. Attualmente, ci vogliono diverse settimane perché un wiki si dipoli dall'Incubatore e solo circa 12 wiki vengono creati ogni anno, mostrando un significativo problema.
Ricerche e materiali esistenti rivelano sfide tecniche in ogni fase dell'avviamento linguistico: l'aggiunta di nuove lingue all'Incubatore, le complessità nello sviluppo e nella revisione dei contenuti e la lentezza del processo di creazione di un sito wiki quando una lingua esce dall'Incubatore. Ogni fase è lenta, manuale e complessa, il che indica la necessità di un miglioramento. Risolvere questo problema permetterà di creare wiki in nuove lingue in modo più veloce e semplice e permetterà a un maggior numero di persone di condividere la conoscenza. Vari stakeholder, ricerche e risorse esistenti hanno evidenziato proposte di redditi sia sociali sia tecniche. Questo risultato chiave propone di testare due redditi sia sociali sia tecniche e di valutare il feedback della comunità. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | Entro la fine del secondo trimestre, 2 nuove funzioni guidano i contributori ad aggiungere materiali di partenza conformi alle linee guida del progetto e 3-5 partner hanno contribuito con materiale di partenza che affronta le lacune linguistiche e geografiche. | Per incrementare l'accesso al materiale di qualità necessario a colmare le lacune strategiche in termini di contenuti, provvederemo a:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | Entro la fine del secondo trimestre, attivare le funzioni di Wikifunctions su almeno una Wikipedia in una lingua più piccola per fornire un modo più graduale per la creazione di nuovi contenuti. | Per ridurre efficacemente le nostre lacune conoscitive, dobbiamo migliorare i flussi di lavoro che supportano una crescita graduale dei contenuti di qualità, specialmente nelle comunità linguistiche più piccole. | Amy Tsay |
| WE3.1 | Pubblicare due esperienze di navigazione e apprendimento curate, accessibili e orientate alla comunità per i wiki rappresentativi, con l'obiettivo di aumentare del 5% la fidelizzazione dei lettori disconnessi. | Questo KR si concentra sull'aumento della ritenzione di una nuova generazione di lettori sul nostro sito web, consentendo a una nuova generazione di costruire un legame duraturo con Wikipedia, esplorando le opportunità per i lettori di scoprire e imparare più facilmente dai contenuti a cui sono interessati. Questo includerà l'esplorazione e lo sviluppo di nuove esperienze di navigazione e apprendimento curate, personalizzate e guidate dalla comunità (ad esempio, feed di contenuti rilevanti, raccomandazioni e suggerimenti di contenuti di attualità, opportunità di esplorazione di contenuti curati dalla comunità, ecc).
Abbiamo intenzione di iniziare l'anno fiscale sperimentando una serie di esperienze di navigazione per determinare quali vorremmo utilizzare in produzione e su quale piattaforma (web, app o entrambe). Ci concentreremo poi sulla gestione di tali esperimenti e sulla verifica della loro efficacia nell'aumentare la fidelizzazione in ambienti di produzione. Il nostro obiettivo entro la fine dell'anno è lanciare almeno due esperienze su wiki rappresentativi e misurare con precisione un aumento del 5% della fidelizzazione dei lettori impegnati in queste esperienze. Per raggiungere questo KR in modo ottimale, dovremo avere la possibilità di effettuare test A/B con gli utenti disconnessi, nonché una strumentazione in grado di misurare la fidelizzazione dei lettori. Potremmo anche aver bisogno di nuove API o servizi necessari per presentare raccomandazioni e altri meccanismi di curatela. |
Olga Vasileva |
| WE3.2 | Aumento del 50% del numero di donazioni tramite punti di contatto al di fuori dei banner annuali e degli appelli via email per piattaforma. | Il nostro obiettivo è fornire una varietà di fonti di entrate, riconoscendo al contempo i donatori esistenti. In base ai riscontri e ai dati, la nostra attenzione si concentra sull'aumento del numero di donazioni al di là dei metodi su cui la Foundation ha fatto affidamento in passato, in particolare gli appelli annuali con banner. Vogliamo dimostrare che, investendo in esperienze di donazione più integrate, possiamo sostenere il nostro lavoro ed espandere il nostro impatto, fornendo un'alternativa ai donatori e ai potenziali donatori che non rispondono agli appelli tramite banner. Il 50% è una stima iniziale basata sulla diminuzione della visibilità del pulsante per le donazioni sul Web come risultato del Vector 2022 e sull'aumento del numero di donazioni grazie al progetto pilota dell'esercizio 2023-2024 sulle app di Wikimedia per migliorare l'esperienza dei donatori (aumento del 50,1% delle donazioni). La valutazione di questa metrica in base alla piattaforma ci aiuterà a capire le tendenze delle piattaforme e se in futuro sarà necessario adottare tattiche diverse in base alle differenze comportamentali del pubblico della piattaforma. | Jazmin Tanner |
| WE3.3 | By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE4.1 | Fornire una proposta di 3 contromisure contro le molestie e i contenuti pericolosi, basata sui dati e conforme con il contesto normativo in evoluzione, entro il terzo. | Garantire la sicurezza e il benessere degli utenti è una responsabilità fondamentale delle piattaforme online. In molte giurisdizioni esistono leggi e regolamenti che impongono alle piattaforme online di intervenire contro le molestie, il cyberbullismo e altri contenuti dannosi. Se non si affrontano questi problemi, le piattaforme possono essere esposte a responsabilità legali e a sanzioni normative.
Al momento non abbiamo un'idea precisa dell'entità di questi problemi o delle ragioni che li determinano. Ci affidiamo in larga misura a prove aneddotiche e a processi manuali che ci espongono sia a rischi legali sia ad altre conseguenze di vasta portata: sottovalutazione del problema, escalation del danno, danni alla reputazione ed erosione della fiducia degli utenti. Dobbiamo costruire una forte cultura di misurazione dell'incidenza di molestie e contenuti dannosi e attuare in modo proattivo le contromisure. |
Madalina Ana |
| WE4.2 | Sviluppare almeno due segnali da utilizzare nei flussi di lavoro anti-abuso per migliorare la precisione delle azioni sui soggetti scorretti entro il terzo semestre. | I wiki fanno molto affidamento sul blocco degli IP come meccanismo per bloccare vandalismo, spam e abusi. Tuttavia, gli indirizzi IP sono sempre meno utili come identificatori stabili di un singolo soggetto, e il blocco degli indirizzi IP ha effetti negativi indesiderati sugli utenti in buona fede che condividono lo stesso indirizzo IP dei soggetti scorretti. La combinazione tra la diminuzione della stabilità degli indirizzi IP e la nostra forte dipendenza dal blocco degli IP si traduce in una minore precisione ed efficacia nel colpire i soggetti scorretti, oltre che in un aumento dei danni collaterali per gli utenti in buona fede. Vogliamo che si verifichi la situazione opposta: diminuzione dei danni collaterali e aumento della precisione delle misure di mitigazione contro i malintenzionati.
Per sostenere meglio il lavoro anti-abuso dei funzionari e per fornire elementi di base da riutilizzare negli strumenti esistenti (ad esempio CheckUser, Special:Block) e in quelli nuovi, in questo KR proponiamo di esplorare modi per associare in modo affidabile un individuo alle sue azioni (mitigazione del sockpuppetting) e di combinare i segnali esistenti (ad esempio indirizzi IP, cronologia degli account, attributi delle richieste) per consentire azioni più precise nei confronti dei soggetti scorretti. |
Kosta Harlan |
| WE4.3 | Ridurre del 50% l'efficacia di un attacco distribuito su larga scala, misurata in base al tempo necessario per adattare le nostre misure e al volume di traffico che possiamo sostenere in una simulazione. | L'evoluzione del panorama di Internet, compresa la crescita di botnet su larga scala e di attacchi 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 contributori con privilegi elevati e la nostra comunità tecnica.
Abbiamo urgentemente bisogno di migliorare la nostra capacità di rilevare automaticamente, resistere e mitigare o fermare tali attacchi. Per misurare i nostri miglioramenti, non possiamo basarci solo sulla frequenza/intensità degli attacchi effettivi, perché dipenderemmo da azioni esterne e sarebbe difficile avere un quadro quantitativo chiaro dei nostri progressi. Impostando più attacchi simulati di varia natura/complessità/durata da eseguire in sicurezza contro la nostra infrastruttura, ed eseguendoli ogni trimestre, saremo in grado sia di testare le nostre nuove contromisure mentre non siamo sotto attacco, sia di fornire un resoconto oggettivo dei nostri miglioramenti. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | Entro il terzo trimestre, completare almeno 5 interventi finalizzati ad aumentare la stabilità della piattaforma. | La stabilità della piattaforma MediaWiki è un impegno costante, importante per la nostra capacità di dimensionare, aumentare o evitare il degrado della soddisfazione degli sviluppatori e far crescere la nostra comunità tecnica. È difficile da misurare e dipende da fattori tecnici e sociali. Tuttavia, abbiamo una conoscenza tacita di aree specifiche di miglioramento che sono strategiche per la stabilità. Gli interventi previsti possono contribuire ad aumentare la stabilità e la mantenibilità della piattaforma o a evitarne il degrado. Abbiamo in programma di valutare l'impatto di questo lavoro nel quarto trimestre, con raccomandazioni per gli obiettivi di stabilità da perseguire in futuro. Esempi di interventi per la stabilità sono: semplificare i domini di codice complessi che sono fondamentali per MediaWiki, ma solo poche persone ne conoscono il funzionamento; aumentare l'uso di strumenti di analisi del codice per informare sulla qualità della nostra base di codice; snellire i processi come il packaging e i rilasci. | Mateus Santos |
| WE5.2 | Identificare entro il secondo trimestre e completare entro il quarto uno o più interventi per far evolvere le interfacce di programmazione dell'ecosistema MediaWiki in modo da favorire lo sviluppo di funzionalità disaccoppiate, più semplici e più sostenibili. | L'obiettivo principale di KR 5.2 è quello di migliorare e chiarire l'interazione tra la piattaforma principale di MediaWiki e le sue estensioni, skin e altre parti. Il nostro intento è quello di fornire miglioramenti funzionali all'architettura di MediaWiki che consentano una modularità e una mantenibilità pratiche, per le quali sia più facile sviluppare estensioni, e che diano forza ai requisiti della visione più ampia del prodotto MediaWiki. Questo lavoro ha anche lo scopo di informare su cosa dovrebbe esistere (o meno) all'interno del core, delle estensioni o delle interfacce tra di loro. L'anno sarà diviso in due fasi: una fase di ricerca e sperimentazione di 5 mesi che informerà la seconda fase in cui verranno implementati interventi specifici. | [TBD] |
| WE5.3 | Entro la fine del secondo trimestre, completare un'iniziativa di raccolta dati e un esperimento di miglioramento delle prestazioni per informare gli interventi successivi sul prodotto e sulla piattaforma per sfruttare le capacità sbloccate dalla strutturazione di MediaWiki di una pagina come composizione di frammenti strutturati. | L'obiettivo principale è quello di mettere gli sviluppatori e i product manager in condizione di sfruttare le nuove capacità della piattaforma MediaWiki per soddisfare le esigenze attuali e future dei contenuti enciclopedici, rendendo possibili nuove offerte di prodotti attualmente difficili da implementare e migliorando le prestazioni e la resilienza della piattaforma.
In particolare, a livello di piattaforma MediaWiki, vogliamo spostare il modello di elaborazione di MediaWiki dal trattare una pagina come un'unità monolitica al trattare una pagina come una composizione di unità di contenuto strutturate. Le visualizzazioni di lettura basate su Parsoid, l'integrazione di Wikidata e l'integrazione di Wikifunctions nei wiki sono tutti passi impliciti verso questo obiettivo. Nell'ambito di questo progetto KR, vogliamo sperimentare in modo più intenzionale e raccogliere dati per informare i futuri interventi basati su queste nuove funzionalità, per assicurarci di poter ottenere gli impatti previsti sull'infrastruttura e sul prodotto. |
[TBD] |
| WE5.4 | By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management. |
Mateus Santos |
| WE6.1 | Risolvere 5 questioni per consentire l'efficienza e le decisioni informate sui flussi di lavoro e sui servizi per sviluppatori e ingegneri e rendere accessibili i dati pertinenti entro la fine del quarto trimestre. | "È complicato" è una risposta frequente a domande come "quali repository sono distribuiti nella produzione di Wikimedia". In questo articolo esploreremo alcuni dei nostri "evergreen" nel campo della produttività e dell'esperienza ingegneristica - domande ricorrenti che sembrano facili ma a cui è difficile rispondere, domande a cui possiamo rispondere, ma i dati non sono accessibili e richiedono ricerche personalizzate da parte di esperti in materia, o domande su cui è difficile ottenere una risposta per lacune nel processo o per altri motivi. Definiremo il significato di "risolvere" per ciascuna domanda: Per alcune può significare semplicemente rendere accessibili i dati esistenti e accurati. Altre domande richiederanno più ricerca e tempo di progettazione per essere risolte. L'obiettivo generale di questo lavoro è quello di ridurre il tempo, le procedure e gli sforzi necessari per ottenere informazioni su aspetti chiave dell'esperienza degli sviluppatori e consentirci di apportare miglioramenti ai flussi di lavoro e ai servizi di ingegneria e degli sviluppatori. | [TBD] |
| WE6.2 | Entro il quarto trimestre, migliorare un progetto esistente ed eseguire almeno due esperimenti volti a fornire ambienti controllabili e mirati che ci portino verso una consegna sicura e semi-continua. | Sviluppatori e utenti dipendono dal Wikimedia Beta Cluster (beta) per individuare i bug prima che colpiscano gli utenti in produzione. Nel corso del tempo, gli usi di beta sono cresciuti e sono entrati in conflitto: sono troppo diversi per essere inseriti in un unico ambiente. Miglioreremo un ambiente alternativo esistente ed eseguiremo esperimenti volti a sostituire un'unica esigenza di test ad alta priorità attualmente soddisfatta da beta con un ambiente alternativo gestibile che risponda meglio alle esigenze di ciascun caso d'uso. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | Toolforge, la piattaforma chiave per gli strumenti costruiti dai volontari di Wikimedia, svolge un ruolo cruciale, dall'editing all'antivandalismo. Il nostro obiettivo è migliorare la fruibilità di Toolforge, ridurre le difficoltà di contribuzione, migliorare le pratiche della comunità e promuovere l'adesione alle politiche stabilite. A tal fine, introdurremo un sistema di punteggio entro il secondo trimestre per valutare la stabilità della piattaforma Toolforge, concentrandoci sugli aspetti tecnici e sociali. Utilizzando questo sistema come guida, ci proponiamo di migliorare del 50% uno dei fattori tecnici chiave. | Slavina Stefanova |
| Servizi di segnali e dati (SDS) Bozza risultati chiave | |||
|---|---|---|---|
| Nome abbreviato del risultato chiave | Testo del risultato chiave | Contesto del risultato chiave | Responsabile |
| SDS1.1 | I leader di 2 programmi o iniziative guidate da KR hanno prodotto una documento ampiamente condiviso che spiega il legame logico tra il lavoro del loro team e l'impatto su una o più metriche fondamentali della Foundation. | Le nostre metriche organizzative principali servono come base per valutare i progressi della Foundation verso i suoi obiettivi. Quando assegniamo risorse ai programmi e progettiamo flussi di lavoro orientati ai risultati chiave (KR), queste metriche di alto livello devono guidare il modo in cui colleghiamo questi investimenti agli obiettivi generali della Foundation, definiti nel piano annuale. Il lavoro svolto in questo risultato chiave riconosce che la Foundation nel suo complesso è in una fase iniziale della sua capacità di collegare quantitativamente gli impatti di tutti gli interventi pianificati a metriche di alto livello o fondamentali. Nel perseguire questo obiettivo finale, questo KR mira a sviluppare il processo con cui condividiamo i collegamenti logici e teorici tra le nostre iniziative e le nostre metriche di alto livello. In pratica, ciò significa collaborare con i responsabili delle iniziative in tutta la Foundation per capire come il risultato del loro lavoro a livello di progetto sia collegato e abbia un impatto sulle nostre metriche principali a livello di Foundation. Per garantire coerenza e rigore nella documentazione dell'impatto potenziale del lavoro, verranno utilizzati quadri ed esercizi di mappatura dell'impatto come la "mappatura della teoria del cambiamento" e la costruzione di grafici causali. Per realizzare questo risultato chiave, dovremo anche sviluppare materiali di supporto che aiutino i responsabili delle iniziative a comprendere le metriche organizzative e a capire come costruire le teorie del cambiamento associate al loro lavoro. |
Omari Sefu |
| SDS1.2 | Rispondere a 2 domande strategiche di ricerca aperte entro dicembre 2024 per fornire raccomandazioni o informare la pianificazione annuale dell'anno fiscale 26. | Ci sono molte domande di ricerca aperte nell'ecosistema Wikimedia e rispondere ad alcune di queste domande è strategico per WMF o per gli affiliati. Le risposte a queste domande possono informare il futuro sviluppo di prodotti o tecnologie o possono supportare il processo decisionale e di advocacy nello spazio di policy. Mentre alcune di queste domande possono essere risolte utilizzando competenze puramente di ricerca o di ingegneria della ricerca, data la natura socio-tecnica dei progetti di WM, arrivare a intuizioni degne di fiducia spesso richiede la collaborazione di più team per la raccolta dei dati, la costruzione del contesto, l'interazione con gli utenti, l'attenta progettazione degli esperimenti e altro ancora. Con questo progetto KR ci proponiamo di dare priorità ad alcune delle nostre risorse per rispondere a una o più di queste domande.
Il lavoro in questo KR comprende la definizione delle priorità di un elenco di domande aperte strategiche e l'esecuzione di lavori sperimentali per trovare una risposta a un numero X (attualmente stimato in 2) di esse. Il tipo ideale di domande che affrontiamo in questo KR sono quelle che, una volta ottenuta una risposta, possono avere un effetto sbloccante, consentendo a più team o gruppi di svolgere un lavoro (meglio? informato) su prodotti, tecnologie o politiche. Vogliamo che il lavoro in questo KR sia complementare ai seguenti KR:
|
Leila Zia |
| SDS1.3 | Ottenere una riduzione di almeno il 50% del tempo medio richiesto agli stakeholder dei dati per comprendere e tracciare i flussi di dati per 3 metriche fondamentali ed essenziali. | Richiesto per gli standard di Data Governance.
Risalire alla trasformazione e all'origine dei set di dati è difficile e richiede la conoscenza di repository e sistemi diversi. Dovremmo semplificare la comprensione dei flussi di dati all'interno dei nostri sistemi, in modo che gli stakeholder dei dati possano lavorare in modo più autonomo. Questo lavoro supporterà i flussi di lavoro in cui i dati vengono trasformati e utilizzati per analisi, funzionalità, API e lavori di qualità dei dati. Ci sarà un successivo KR per documentare le metriche. |
Luke Bowmaker |
| SDS2.1 | Entro la fine del secondo trimestre, saremo in grado di supportare un team di prodotto nella valutazione di una funzionalità o di un prodotto tramite test A/B di base, riducendo del 50% il tempo necessario per ottenere dati sull'interazione con l'utente. | Riteniamo che l'uso di strumenti condivisi aumenterà la fiducia dei team di prodotto nel processo decisionale basato sui dati, migliorerà l'efficienza e la produttività e favorirà la strategia e l'innovazione di prodotto. Esamineremo le linee di base individuali del team relative al tempo di interazione con l'utente e le miglioreremo del 50%. Studieremo inoltre come contestualizzare questi guadagni nel contesto più ampio di tutti i team di prodotto. Ci aspettiamo di imparare come possiamo migliorare l'esperienza e di identificare e dare priorità ai miglioramenti delle capacità in base al feedback del team che adotta e ai risultati dell'SDS2.2. |
Virginia Poundstone |
| SDS2.2 | Entro la fine del secondo trimestre, disporremo di 2 metriche essenziali per l'analisi degli esperimenti (test A/B) a sostegno della verifica delle ipotesi di prodotto/caratteristiche relative alle KR dell'anno fiscale 24-25. | Quando un product manager (o un designer) ha l'ipotesi che un prodotto/una funzionalità possa risolvere un problema/bisogno degli utenti o dell'organizzazione, un esperimento è il modo in cui testa l'ipotesi e apprende l'impatto potenziale della sua idea su una metrica. I risultati dell'esperimento informano il product manager e lo aiutano a decidere quale azione intraprendere (abbandonare l'idea e provare un'ipotesi diversa, continuare lo sviluppo se l'esperimento è stato eseguito nelle prime fasi del ciclo di vita dello sviluppo o rilasciare il prodotto/la funzionalità a un maggior numero di utenti). I responsabili di prodotto devono essere in grado di prendere questa decisione con fiducia, supportata da prove di cui si fidano e che comprendono.
Un ostacolo importante è rappresentato dal fatto che attualmente i team di prodotto formulano le loro ipotesi con metriche personalizzate e specifiche per il progetto, che richiedono un supporto analitico dedicato per definirle, misurarle, analizzarle e produrre report. Il passaggio a un insieme di metriche essenziali per la formulazione di tutte le ipotesi di prodotto/caratteristiche verificabili renderebbe:
Riteniamo che un insieme di metriche essenziali ampiamente comprese e utilizzate in modo coerente - e informate/influenzate da metriche standard del settore - migliorerebbe anche l'alfabetizzazione organizzativa sui dati e promuoverebbe una cultura di revisione, sperimentazione e apprendimento. Ci concentriamo sulle metriche essenziali che (1) sono necessarie per misurare e valutare al meglio il successo/impatto dei prodotti/caratteristiche relative a due KR di Wiki Experiences - WE3.1 e WE1.2 - e (2) riflettono o si rifanno alle metriche standard del settore utilizzate nella web analytics. |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| Audience future (FA) Bozza risultati chiave | |||
|---|---|---|---|
| Nome abbreviato del risultato chiave | Testo del risultato chiave | Contesto del risultato chiave | Responsabile |
| 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 sta tracciando le tendenze esterne che possono avere un impatto sulla nostra capacità di servire 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:
|
Maryana Pinchuk |
| Supporto tecnico e di prodotto (PES) Bozza risultati chiave | |||
|---|---|---|---|
| Nome abbreviato del risultato chiave | Testo del risultato chiave | Contesto del risultato chiave | Responsabile |
| PES1.1 | Cultura della revisione: migliorare progressivamente i punteggi relativi al sentimento del personale P+T in relazione alla nostra fornitura, all'allineamento, alla direzione e alla salute del team in un sondaggio trimestrale. | Una cultura di revisione è una cultura di sviluppo del prodotto basata su cicli più brevi di iterazione, apprendimento e adattamento. Ciò significa che la nostra organizzazione può fissare obiettivi annuali, ma ciò che facciamo per raggiungere questi obiettivi cambierà e si adatterà nel corso dell'anno, man mano che impariamo. Ci sono due componenti per costruire una cultura della revisione: i processi e i comportamenti. Questo documento si concentra su questi ultimi. I cambiamenti comportamentali possono far crescere e rafforzare la nostra cultura della revisione. Ciò comporta cambiamenti nelle abitudini e nelle routine individuali, mentre ci muoviamo verso uno sviluppo del prodotto più iterativo. Questo metodo di lavoro si baserà sui cambiamenti autodichiarati nei comportamenti individuali e sulla misurazione dei cambiamenti che ne derivano, se ce ne sono, nel sentimento del personale. | Amy Tsay |
| PES1.2 | Entro la fine del secondo trimestre, la nuova Wishlist collega meglio le idee e le richieste dei movimenti alle attività P+T della Fondazione: le voci della Wishlist sono state affrontate attraverso una KR 2024-2025, Foundation ha completato 10 Wishes più piccoli e ha collaborato con i volontari per identificare più di 3 aree di opportunità per l'anno fiscale 2025-2026. | La Community Wishlist rappresenta una fetta ristretta del movimento; vi partecipano circa 1.000 persone, la maggior parte delle quali sono contributori o amministratori. Le persone spesso aggirano la Lista dei desideri scrivendo richieste di funzionalità e segnalazioni di bug tramite Phabricator, dove è difficile distinguere le richieste di WMF o della comunità. Per i partecipanti, la Wishlist è un investimento di tempo costoso con un guadagno minimo. Si impegnano comunque con la Wishlist perché ritengono che sia l'unico veicolo per richiamare l'attenzione su bug e miglioramenti di funzionalità di grande impatto, o per segnalare la necessità di opportunità più ampie e strategiche. I desideri sono spesso scritti come soluzioni e non come problemi. Le soluzioni possono sembrare sensate sulla carta, ma non considerano necessariamente la complessità tecnica o le implicazioni strategiche del movimento.
La portata e l'ampiezza dei desideri a volte supera la portata e la capacità di Community Tech o di un singolo team, perpetuando la frustrazione e portando a RFC e a richieste di smantellamento della Wishlist. Mentre i membri della comunità preferiscono usare la Wishlist per le idee di progetto, i team della Fondazione guardano alla Wishlist e ad altri processi di assunzione per stabilire le priorità, in parte perché i desideri non sono adatti alla pianificazione annuale e sono difficili da incorporare nelle roadmap / OKR. La Wishlist del futuro dovrebbe essere un ponte tra la comunità e la Foundation, dove le comunità forniscono input in modo strutturato, in modo che noi siamo in grado di agire e, a nostra volta, rendere felici i volontari. Stiamo creando un nuovo processo di inserimento che consente a qualsiasi volontario connesso di inviare un desiderio, 365 giorni all'anno. I desideri possono segnalare o evidenziare un bug, richiedere un miglioramento o ideare una nuova funzionalità. Chiunque può commentare, discutere o sostenere un desiderio per influenzare la definizione delle priorità. La Foundation non classificherà i desideri come "troppo grandi" o "troppo piccoli". I desideri che si ricollegano a un'area problematica più ampia possono influenzare la pianificazione annuale e le roadmap del team, offrendo indicazioni strategiche e opportunità. I desideri saranno visibili al Movimento in una dashboard che categorizza i desideri per progetto, prodotto/area problematica e tipo di desiderio. La Foundation risponderà ai desideri in modo tempestivo e collaborerà con la Comunità per classificare e dare priorità ai desideri. Collaboreremo con i wikimediani per identificare e dare priorità a tre aree di miglioramento, incorporate nel Piano annuale 2025-26 della Foundation, che dovrebbero migliorare il tasso di adozione e la realizzazione di desideri d'impatto. Segnaleremo i desideri ben individuati per la comunità di sviluppatori volontari e per i team della Foundation, in modo da aumentare l'impegno dei team e degli sviluppatori e la realizzazione dei desideri, con conseguente soddisfazione della comunità. La realizzazione di un maggior numero di desideri migliora la felicità, l'efficacia e la fidelizzazione dei collaboratori, il che dovrebbe generare più modifiche di qualità, contenuti di qualità superiore e un maggior numero di lettori. |
Jack Wheeler |
| PES1.3 | Eseguire e concludere due esperimenti su prodotti/caratteristiche esplorative esistenti, che ci forniscano dati/spunti su come far crescere Wikipedia come destinazione di conoscenza per il nostro pubblico attuale di consumatori e volontari nel 1° e 2° trimestre. Completare e condividere i risultati e le raccomandazioni per la potenziale adozione per il futuro lavoro OKR nel settore Esperienze Wiki entro la fine del terzo trimestre. | Questo lavoro è una controparte dell'obiettivo Future Audiences, ma si concentra invece sulla scoperta di opportunità per aumentare e approfondire il coinvolgimento del nostro pubblico esistente (di consumatori e collaboratori di Wikipedia) attraverso la sperimentazione più agile di idee di prodotto sulla piattaforma.
Il progetto vive in PES1 come un energizzatore e moltiplicatore - incanalando il tempo che gli individui e i team hanno già dedicato all'hacking/sperimentazione di progetti collaterali per mettere a fuoco caratteristiche più promettenti. Invece di far languire questi progetti collaterali (non è un buon uso delle nostre risorse limitate), questo KR fornisce un percorso per alcune di queste idee che potenzialmente possono essere inserite in APP più grandi attraverso esperimenti comprovati, utilizzando così in modo più efficiente il tempo del personale e motivando la loro creatività e produttività. Con l'introduzione di un maggior numero di questi progetti più piccoli e brevi, diversifichiamo anche la nostra gamma di "scommesse" per ottenere più insegnamenti e sperimentare idee che possano trasformare Wikipedia in linea con le mutevoli esigenze e aspettative del nostro pubblico attuale. Questo renderà il nostro lavoro più efficace e più veloce, in quanto aiuterà la fondazione ad allinearsi sull'obiettivo corretto in meno tempo. |
Rita Ho |
| PES1.4 | Imparare a: definire, monitorare e prendere decisioni sugli SLO. Scegliere almeno una novità per la quale definire gli SLO non appena la rilasciamo. Collaborare con i rispettivi team (tipicamente: prodotto, team di sviluppo, SRE) per definire tale SLO. Riflettere e documentare le linee guida per quali release dovranno avere SLO in futuro e come definirli. | Futuro KR:
Impostare un processo e strumenti rudimentali per la definizione e il monitoraggio degli SLO per le nuove versioni. Fare un rapporto su base trimestrale e usarlo per prendere decisioni su quando (e non) dare priorità al lavoro per correggere qualcosa. Condividere il bilancio con la comunità. PERCHÉ: Non sappiamo quando dobbiamo dare priorità al lavoro per risolvere qualcosa. E abbiamo un sacco di codice. Con la crescita di questo spazio, aumentano le situazioni in cui potremmo dover decidere se affrontare i problemi o concentrarci sull'innovazione, e aumenta l'incertezza su quando dovremmo farlo. Inoltre, non è chiaro al personale e alla comunità quale sia il nostro livello di supporto/impegno in termini di affidabilità e prestazioni per tutte le diverse caratteristiche e funzionalità con cui interagiscono. Se definiamo un livello di servizio atteso, possiamo sapere quando è il caso di destinarvi risorse o meno. |
Mark Bergsma |
Hypotheses
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
Q1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | |
| WE3.2.1 | If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year | phab:T368765 |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.3.1 | If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs. | |
| WE4.1.1 | If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take. | |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | phab:T368388 |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | WE4.2.9 Talk page |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts | WE4.2.2 Talk page |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | phab:T368389 |
| WE4.3.2 | If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.4 | If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool. | phab:T369480 |
| WE4.4.1 | If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully. | |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.2 | If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress. | |
| WE5.1.3 | If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1. | phab:T344944 |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers. | |
| WE5.2.1 | If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful. | [1] |
| WE5.2.2 | If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. | [2] |
| WE5.3.1 | If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform. | T371713 |
| WE5.3.2 | On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits. | T363421 |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.1 | If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests. | |
| WE6.1.2 | If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers. | compito T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | mw: New Engagement Experiments#PES_1.3.3:_Incubator_space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
Q2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator_Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024_Moderator_Tools_project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024_Reader_and_Donor_Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | https://meta.wikimedia.org/wiki/Incident_Reporting_System# |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia_Technical_Documentation_Team/Doc_metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data_Platform_Engineering/Data_Products/work_focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | compito T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| TBA | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
Spiegazione dei buckets
Wiki Experiences
Lo scopo di questo bucket è quello di fornire, migliorare e innovare in modo efficiente le esperienze wiki che consentono la distribuzione della conoscenza libera in tutto il mondo. Questo settore è in linea con le raccomandazioni della strategia del movimento n. #2 (Migliorare l’esperienza dell’utente) e n. #3 (Garantire la sicurezza e l’inclusione). Il nostro pubblico comprende tutti i collaboratori sui nostri siti web, nonché i lettori e gli altri consumatori di conoscenza libera. Supportiamo un sito web globale top-10 e molte altre importanti risorse culturali gratuite. Questi sistemi hanno requisiti di prestazioni e tempi di attività pari a quelli delle più grandi aziende tecnologiche del mondo. Forniamo interfacce utente per i wiki, traduzioni, API per gli sviluppatori (e altro ancora!) e applicazioni e infrastrutture di supporto che formano una solida piattaforma per i volontari che collaborano per produrre conoscenza libera in tutto il mondo. I nostri obiettivi per questo settore dovrebbero consentirci di migliorare la nostra tecnologia di base e le nostre capacità, di garantire un continuo miglioramento dell'esperienza dei redattori e dei moderatori volontari dei nostri progetti, di migliorare l'esperienza di tutti i collaboratori tecnici che lavorano per migliorare o potenziare le esperienze wiki e di garantire un'ottima esperienza ai lettori e ai consumatori di conoscenza libera in tutto il mondo. Faremo questo attraverso il lavoro sui prodotti e sulla tecnologia, oltre che attraverso la ricerca e il marketing. Ci aspettiamo di avere al massimo cinque obiettivi per questo settore.
La conoscenza è costruita dalle persone! Di conseguenza, il nostro piano annuale si concentrerà sui contenuti, sulle persone che vi contribuiscono e su quelle che vi accedono e li leggono.
Il nostro obiettivo è produrre un piano operativo basato sulla strategia esistente, soprattutto sulle nostre ipotesi sul "volano" dei collaboratori, dei consumatori e dei contenuti. Il cambiamento principale che chiedo è un'enfasi sulla porzione di contenuto del volano e l'esplorazione di ciò che i nostri moderatori e i nostri funzionari potrebbero avere bisogno da noi ora, con l'obiettivo di identificare le metriche di salute della comunità in futuro.
Signals and Data Services
Per essere allineati con raccomandazione della strategia per Garantire l'equità nel processo decisionale (Raccomandazione #4), Migliorare l'esperienza dell'utente (Raccomandazione #2) e Valutare, Iterare e Adattare (Raccomandazione #10), i responsabili delle decisioni di tutto il movimento Wikimedia devono avere accesso a dati, modelli, approfondimenti e strumenti affidabili, pertinenti e tempestivi che li aiutino a valutare l'impatto (sia realizzato che potenziale) del loro lavoro e del lavoro delle loro comunità, consentendo loro di prendere decisioni strategiche migliori.
Nell'ambito del bucket Signals & Data Services, abbiamo identificato quattro destinatari principali: Personale della Wikimedia Foundation, affiliati e gruppi di utenti di Wikimedia, sviluppatori che riutilizzano i nostri contenuti e ricercatori di Wikimedia. Il nostro lavoro abbraccerà una serie di attività: definizione delle lacune, sviluppo di metriche, costruzione di pipeline per il calcolo delle metriche e sviluppo di esperienze e percorsi di esplorazione dei dati e dei segnali che aiutino i decisori a interagire in modo più efficace e gioioso con i dati e gli approfondimenti.
Pubblici futuri
.svg)
Lo scopo di questo settore è quello di esplorare strategie per espandersi al di là dei nostri attuali pubblici di consumatori e collaboratori, nel tentativo di raggiungere veramente tutti nel mondo come infrastruttura essenziale dell'ecosistema della conoscenza libera. Questo settore si allinea alla raccomandazione #9 della strategia del movimento (Innovare nella conoscenza libera). Sempre più persone consumano le informazioni in esperienze e forme che si discostano dalla nostra tradizionale offerta di un sito web con articoli - le persone usano gli assistenti vocali, passano il tempo con i video, si impegnano con l'intelligenza artificiale e altro ancora. In questo gruppo di lavoro proporremo e testeremo ipotesi sul potenziale futuro a lungo termine dell'ecosistema della conoscenza libera e su come noi saremo la sua infrastruttura essenziale. Lo faremo attraverso il lavoro sui prodotti e sulle tecnologie, oltre che attraverso la ricerca, le partnership e il marketing. Man mano che identificheremo gli stati futuri più promettenti, gli insegnamenti tratti da questo settore influenzeranno ed estenderanno i settori n. 1 e n. 2 dei piani annuali successivi, orientando le nostre offerte di prodotti e tecnologie verso il punto in cui devono essere al servizio dei cercatori di conoscenza del futuro. I nostri obiettivi per questo settore dovrebbero spingerci a sperimentare ed esplorare mentre mettiamo a fuoco una visione del futuro della conoscenza libera.
Sub-buckets
Abbiamo anche altri due "sottogruppi" che consistono in aree di funzioni critiche, che devono esistere alla Foundation per sostenere le nostre operazioni di base, e alcune delle quali sono in comune con qualsiasi organizzazione di software. Questi "sottogruppi" non avranno obiettivi propri di alto livello, ma avranno input e sosterranno gli obiettivi di alto livello degli altri gruppi. Essi sono:
- Fondamenti dell'infrastruttura. Questo gruppo comprende i team che sostengono e fanno evolvere i nostri data center, le nostre piattaforme di calcolo e di archiviazione, i servizi che le gestiscono, gli strumenti e i processi che consentono il funzionamento dei nostri siti e servizi rivolti al pubblico.
- Supporto tecnico e di prodotto. Questo settore comprende i team che operano "su scala" fornendo servizi ad altri team che migliorano la produttività e le operazioni di altri team.