Piano annuale di Wikimedia Foundation/2024-2025/OKR del dipartimento Product & Technology
The Annual Plan draft is now available. Translations are underway. |
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.
Questa pagina fa parte del processo di redazione dei piano annuale 2024-25 dei dipartimenti Product e Technology di Wikimedia Foundation.
.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 | Metriche essenziali | 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. | 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. | 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 |
| 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 |
| 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] |
| 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 | Entro il secondo trimestre, introdurre un sistema di punteggio di stabilità per la piattaforma Toolforge su una serie di fattori tecnici e sociali. Entro il quarto trimestre, migliorare del 50% uno dei fattori tecnici chiave. | 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 |
| 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 |
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.