Segnalo 4 interessi e che probabilmente hanno una soluzione comune 😁 ## Interesse 1) del pubblico: trovare facilmente temi Al momento per il pubblico è troppo difficile rispondere a questa domanda: 1. Quest'anno, **dove** devo andare per sentir parlare di Wikibase? o di Blender? o di Arduino? ## Interesse 2) per la stampa: avere un'idea dei temi Al momento per i giornali e la stampa e chi è blogger è troppo difficile rispondere a questa domanda: 2. Quest'anno, **di cosa si parla** in Italia più o meno al Linux Day di quest'anno? ## Interesse 3) per stakeholder: capire la copertura del tema Per "portatori di interessi" come Wikimedia Italia, al momento è troppo difficile rispondere a questa domanda: - quali sono le città in cui si parla di più di Wikibase ai Linux Day? (per trovare relatori) (o di OpenStreetMap, ecc) - quali sono le città in cui si è parlato di meno di Wikibase? (per mandare relatori) ## Interesse 4 BONUS) per chi organizza: trovare speaker Al momento è anche troppo difficile per chi organizza un Linux Day rispondere a questa domanda: - Lo scorso anno, **chi** (persone) c'era in Italia a parlare di Wikibase? o di Blender? o di Arduino? (così magari re-invitiamo le persone relatrici anche quest'anno) Nota: questa è l'unica domanda che purtroppo non ha immediata risposta con una semplice associazione di "Linux Day Città ←→ temi trattati". Tuttavia, avere almeno questa vaga associazione faciliterebbe certamente il lavoro. ## Feedback da volontari di Wikimedia Italia Riporto messaggio dalla mailing list privata di Wikimedia Italia 😁 > ciao a tutti e tutte, > stiamo pensando di proporre all'Italian Linux Society e ai LUG italiani di rinforzare la nostra collaborazione con il Linux Day, cercando di portare una presentazione sui progetti Wikimedia e/o OpenStreetMap in tanti eventi (magari includendo anche Wikibase, ancora poco conosciuto in Italia). Ci sono già state numerose presentazioni e collaborazioni al Linux Day, ma potrebbe essere bello rinforzare questa sinergia e usare anche l’occasione per affiancare nuove persone nel presentare i progetti (e allargare così la nostra rete di volontari / presentatori / formatori) e lavorare su territori in cui non sono presenti coordinatori. > > Qui una bozza di progetto https://meta.wikimedia.org/wiki/Linux_Day_con_Wikimedia_e_OpenStreetMap. > > Ne cominciamo a parlare questa sera alle 18 all'incontro del gruppo di lavoro GLAM https://meeting.wikimedia.it/rooms/gkl-ffv-5tv-ubm/join > > Se siete interessati, non esitate a segnarvi nelle pagine di progetto o a contattarmi e faremo sicuramente una presentazione specifica su questo tema. > Questa iniziativa è anche collegata al lavoro che stiamo facendo nel progetto Open movement Italia https://meta.wikimedia.org/wiki/Open_movement_Italia/Calendario > > A presto > iolanda > > https://mailman.wikimedia.it/private/associazione/2026-June/086198.html (archivio privato) ## Workaround Al momento ho visto persone proporre di aprire una cinquantina di siti web, ogni singolo anno, e mantenere dataset esterni a LinuxDay.it. Problemi: * fare una cosa del genere a mano è un lavoro enorme ogni anno * fare una cosa del genere nelle edizioni passate è ancora più complicato perché certi siti vanno offline, e Internet Archive non sempre aiuta :) * avere un proprio dataset esterno a LinuxDay.it non è necessariamente una cosa comoda, perché spesso significa che ognuno si gestisce un proprio dataset esterno, quindi che diverse persone fanno questo lavoro individualmente per sé stessi, senza riuscire con successo ad aiutare gli altri ## Non-Soluzioni: Non vogliamo importare i programmi completi La soluzione NON dovrebbe prevedere il salvataggio dell'intero programma della giornata del "Linux Day Palermo 2026" in LinuxDay.it. Nello specifico: - NON dovremmo voler portarci in casa TITOLI dei talk, perché questa info non aiuta a rispondere a nessuna delle domande di cui sopra, inoltre, è troppo variabile, e chi organizza non ha tempo da perdere per tenere aggiornato il programma in un luogo in più - e NON dovremmo voler portarci in casa gli orari di inizio ecc. dei talk - per gli stessi motivi ## Soluzione proposta: gestire quantomeno i "Temi" Ad ogni singolo Linux Day potremmo dare la possibilità a **frontend** di inventariare+mostrare i temi trattati nel programma. Esempio mockup di info da poter mostrare sotto ad un Linux Day Palermo 2026 di esempio: {width=180 height=74} Quindi serve una nuova struttura dati per ogni Linux Day, che permetta di capire: * quanti Linux Day parlavano di un tema? * quanti Linux Day **non** ne parlavano? * quanti Linux Day **non si sa** se parlassero di un tema? Quindi la stupida struttura dati proposta, per singolo Linux Day, è questa: ``` { "topics": [ "blender" => true, "wikibase" => true, "arduino" => true, "irc" => false, ], } ``` È importante avere un "3-states" per differenziare bene questi casi: - tema presente nel programma (→ true) - tema non presente nel programma (→ false) - tema che **non si sa** se fosse trattato (→ valore assente) Come popolare questa struttura dati? A backend potremmo mostrare due nuovi input: * Temi presenti: `<textarea>` in cui elenchi le parole chiave, una per riga (campo raccomandato) * Temi assenti: `<textarea>` in cui elenchi le parole chiave, una per riga (campo totalmente opzionale, utile solo per scopi di ricerca e completamento del dataset) **Questione spam e minima redazione nazionale:** Nel mentre che stiamo dando massima libertà a chi organizza di elencare qualsiasi parole chiave per popolare questo dataset, dovremmo introdurre controllo per i proprietari di LinuxDay.it su quali parole chiave mostrare pubblicamente, per evitare il caos sul sito pubblico. Tralasciando i vandalismi, che non credo saranno frequenti: Esempio: probabilmente tutti nel backend elencheranno "software libero" come tema trattato, o "free software", o "open source", o "Linux" o cose del genere implicite e non ha necessariamente senso elencarle a frontend, e non è nemmeno troppo sensato impedirle all'inserimento 😁 perché per impedirle dovremmo fornire un elenco finito di temi, ma un elenco finito limiterebbe troppo l'inserimento di dati potenzialmente ignoti e buoni. Dovremmo concedere a chi organizza l'evento di scrivere i **temi con la stessa velocità con cui scriverebbero degli hashtag**, **quindi senza rispondere ad un questionario allucinante Yes/No su 10000 temi finiti**. Quindi: **FRONTEND**: Prima di mostrare un qualsiasi tema a frontend, sarebbe utile avere una configurazione globale, valida per tutto il sito, valida per tutte le edizioni, per limitare i temi da mostrare pubblicamente sul sito. Esempio configurazione globale per indicare quali temi mostrare a video: ``` $PUBLIC_TOPICS = [ 'blender' => [ 'display' => "Blender", 'aliases' => [ "blender-foundation", .... ], ], 'wikidata' => [ 'display' => "Wikidata", 'aliases' => [ "wikidata.org", ], ], ... } ``` Quindi il frontend dovrebbe avere questa logica: - se non si è autenticati, sotto ai rispettivi Linux Day, mostra solo i temi approvati in `$PUBLIC_TOPICS` - oppure, se si è autenticati, mostrali tutti (magari in colore diverso) Il secondo caso possibilmente che riporti ad una minima spiegazione che permetta di capire **perché** quel tema non è ancora mostrato al pubblico, utile sia per chi organizza i Linux Day (per comprendere che non è in atto alcuna censura, ma semplice lavoro di revisione), e utile per i futuri amministratori del sito (e che non necessariamente si ricorderanno che devono approvare i temi). ## Dopo aver implementato i temi: si potrebbe parlare di speaker, ma un'altra volta Immaginando di aver fatto tutto quanto, potremmo già rispondere a quasi tutti gli interessi elencati, **tranne** l'ultimo punto "Interesse 4 BONUS)" citato in alto, perché quello avrebbe bisogno _anche_ dell'elenco speaker dei singoli Linux Day, e anche dell'associazione di queste/questi speaker ai temi trattati, e anche ovviamente l'associazione per città. Però questo passaggio probabilmente è una cosa che richiederebbe troppi giorni di nostro lavoro di sviluppo software anche solo per capire la struttura dati e come chiedere questi dati in modo sensato e come de-duplicare i dati, e comunque il vantaggio sarebbe? salvare 10 minuti ad una persona esterna? Credo che, avendo _almeno_ i temi a sistema, una persona può comunque aprirsi a mano i link di quel Linux Day per rispondere anche al punto "Interesse 4 BONUS)" e quindi, su un eventuale importazione dell'elenco speaker possiamo tranquillamente parlarne successivamente (fuori da questo "work item" 😁). Consapevoli che quella è una possibile ulteriore evoluzione compatibile. ## FAQ - Qualche persona volontaria in altre associazioni sta già pensando di lavorare ad un dataset esterno di "<città, anno, tema, nome speaker>". È un problema? Esempio: https://meta.wikimedia.org/wiki/Linux_Day_con_Wikimedia_e_OpenStreetMap - È sicuramente un'opportunità! così questo lavoro potrebbe essere importato, per popolare LinuxDay precedenti, senza sovraccaricare chi li organizzava. Infatti, questa pagina è stata creata proprio per venire incontro a questo: https://meta.wikimedia.org/wiki/Linux_Day_con_Wikimedia_e_OpenStreetMap