Wikimania 2024/Report/Valerio Bozzolan
BOZZA
Questo è il report personale della partecipazione di User:Valerio Bozzolan a Wikimania 2024 a Katowice (Polonia) come volontario.
Questi tuoi di report è condiviso da tutte le persone a cui è stata assegnata una borsa di viaggio (per conoscere la commissione borse vedi la pagina Wikimania 2024).
Il punto di vista è strettamente personale. Edit comunque ovviamente benvenuti.
Proposta di sessione: The importance of using Free and Open software in all activities of the Wikimedia movement: situation, opportunities and next steps
Siccome durante il Wikimedia Hackaton 2024 a Tallinn (Estonia) eravamo riusciti a discutere di software libero e software proprietario nelle organizzazioni Wikimedia, in questa mia sessione:
Siccome usciti da quella sessione è stato chiaro per tutti che era inutile parlarne fra di noi "utenze tecniche",
il 10 aprile 2024 ho inviato una proposta di sessione per Wikimania Katowice 2024 con l'obiettivo di raggiungere finalmente persone non-necessariamente-tecniche e l'ho sottoposta a revisione della chat dei "Wikimedians for Software Freedom" (gruppo che sto fondando).
Qui la proposta originale che... è stata rifiutata! :( senza una particolare motivazione.
Title: The importance of using Free and Open software in all activities of the Wikimedia movement: situation, opportunities and next steps. Abstract: In the field of privacy and Software Freedom in the Wikimedia movement, let's analyze the current impact, concerns, and possible solutions for organizations and individuals. While Wikimedia projects (and MediaWiki) are completely Open and designed to protect users; we might consider whether possibly introduce these values also during online meetings and conversations. For example, tools like Zoom, Google Meet, Google Calendar, Google Docs, YouTube, Slack and many others.. are controversial, and generally not in line with the Vision of the Movement, that is, building a Free Infrastructure for Free Knowledge. Description: - Short introduction to the Free Software key values. - Examining key factors that can be used to analyze our negative impacts. - Showing an overview of principal tools (also controversial ones) widely adopted in the Movement to communicate. - Determining how to harden our Strategies, to address these technical and ethical issues. - Possible ways by which organizations can invest in Free Infrastructures. - Success cases, and practical solutions GDPR-friendly and freedom-respecting. Tell us about yourself: I'm the Chair of Italian Linux Society, organization promoting software freedoms. I'm in the Tech Commission of Wikimedia Italy and Open Source consultant for Wikimedia Switzerland. I'm contributor of the [[FLOSS-Exchange]] project on Meta-wiki and author of the RFC user group [[Wikimedians for software freedom]] on Meta. Past experiences: I enjoy holding conferences about digital freedom. Some of them: ▪️FOSDEM 2024 - Unpack Phabricator, Welcome Phorge - Forking the Opinionated Open Source Project Manager ▪️2024 Zabbix Monitoring Tool online @ Free Circle (Palermo, Italy) ▪️2023 - 200 Licenses in 25 minutes on YouTube @ End Summer Camp ▪️2023 SPARLQ Lab @Linux Day Milano .... ▪️ MediaWiki APIs @ ItWikiCon2018 ▪️ MediaWiki templating and Lua @ ItWikiCon2018 ▪️ Introduzione a Wikipedia @ Dipartimento di Matematica (2017) ▪️ Bot workshop @ ItWikiCon (2017) ▪️ Corso introduttivo al software libero @ LDTO16 ▪️ F-Droid privacy sugli smartphone @ LDTO15 @ Cyberia (2014) ▪️ Software libero nella PA @ Didattica Aperta (2014) ▪️ Backtrack5R3 e la offensive security @ IIS Avogadro, Torino, Italy (2013)
Ho cercato di non abbattermi troppo su questo rifiuto e ne ho poi parlato con altre persone, fra cui:
#Extra: incontro di persona con Mario Behling di FOSSASIA (in questa sezione parlo anche dell'incontro con w:m:User:Arianit dalla comunità albanese che aveva proposto una sessione simile - ma anche la sua sessione era stata rifiutata - anch'essa senza allegare una motivazione).
Ho chiesto in giro e altre 4-5 persone vicine avevano avuto proposte rifiutate (su temi totalmente differenti). Mal comune mezzo gaudio.
Ho chiesto in giro se fosse normale che le proposte venissero rifiutate senza un commento. Risulta di sì. Probabilmente questo aspetto sociale si potrebbe ampiamente migliorare, ma chi sono io per permettermi di proporlo. asd. Per esempio, nessuno mi ha chiesto se mi sarebbe andata bene lo stesso la metà del tempo, o un terzo del tempo (onestamente sì). Magari un compromesso si trovava per dare spazio a più persone.
Egoisticamente non nascondo di essermi chiesto come mai la commissione programma WIkimania 2024 fosse riuscita a trovare spazio per una sessione su... come riavvivare la specifica community siciliana! asd (nel corridoio ho comunque poi sentito Ferdi e Lea ritenersi increduli per l'accettazione della loro proposta - e questa frase molto tenera mi ha addolcito la cosa asd - SCHERZO EH BRAVI FERDI E LEA FORZA SICILIA TUTTI CREDEVAMO NELLA SESSIONE SICILIANA asd).
Onestamente questa è l'ennesima goccia che fa traboccare il mio personale vaso pieno di consapevolezza su quanto il software libero non freghi alla maggioranza delle persone nelle organizzazioni Wikimedia. E su quanto dovrei prendermi del tempo per formalizzare l'user group Wikimedians for Software Freedom, nel tentativo di presentarsi come realtà interna strutturata, per convincere tutte le persone che NON fanno software, che non c'è Free Content senza Free Software. In ogni caso da parte mia è stato stupido e anche un po' arrogante da parte mia presentarsi da solo su questa sessione. Prossimo anno si fa diversamente (certo, sapere il motivo dello scarto farebbe comodo per capire cosa irrobustire in questa proposta). Esempio per il prossimmo anno:
Extra: risoluzione problema tecnico su computer aziendale di Wikimedia Italia
- Martedì 6 agosto - prima mattinata
Questa sezione segue lo schema dei report degli incidenti tecnici in produzione in uso in Wikimedia Foundation - w:wikitech:Incident status.
Segnalazione:
Il membro dello staff Utente:Dario Crespi si presenta a Wikimania con il suo amato computer portatile aziendale "Tuxedo" che purtroppo ha iniziato a non avviarsi correttamente da circa 1-2 giorni «dopo un aggiornamento di sistema». Ci siamo dati allora appuntamento all'hackaton room in cui c'era sempre dello spazio libero per lavorare in tranquillità.
Sintomo:
Ad ogni avvio del portatile, il computer si fermava sulla ("schermata nera") shell interattiva di emergenza di w:it:GNU GRUB. Il bootloader GRUB non riusciva a lanciare il sistema operativo.
Ipotesi:
Si è escluso fosse un problema noto legato a dual-boot con Windows 10+ perché il computer ne era sprovvisto (mi è noto che Windows 10+ dopo certi aggiornamenti rompe a prescindere il dual-boot, qualsiasi sistema operativo ci metti di fianco).
Ho informato Dario che nella migliore e più verosimile delle ipotesi avremmo risolto in pochi minuti dopo aver a rigenerato i "menù di avvio di GRUB" eventualmente usando strumenti grafici e semplici da usare come Boot Repair. Questa ipotesi deriva dal fatto che l'aggiornamento dei menu di avvio GRUB è effettuata automaticamente proprio dopo ogni installazione di ogni nuova versione minore del kernel inclusa con gli aggiornamenti di sistema (APT), e mi era già capitato che durante questi aggiornamenti non si completasse con successo `update-grub` per varie ragioni. All'Officina Informatica Libera di San Salvario a Torino consiglio di solito di usare tool grafici, poiché spesso funzionano, punto, dando anche alle nuove utenze GNU/Linux un senso di maggiore controllo del proprio computer, invece che affidarsi ciecamente a persone esterne che digitano "comandi a caso sul mio computer". Inoltre questi tool grafici evitano alle utenze inesperte di commettere errori molto più gravi in futuro quando ri-utilizzati.
Ho informato anche Dario che nella peggiore delle ipotesi aveva perso irrimediabilmente tutti i dati presenti a bordo nella partizione principale, per un problema irreversibile al disco o al filesystem... magari per un precedente impatto al computer o cose del genere che solitamente le utenze non ammettono mai. asd. Questa seconda ipotesi deriva sempre da diverse esperienze dirette (che non c'entrano niente con Dario asd).
Preparazione:
Siccome non mi trovo a mio agio ad operare dal terminale di emergenza di GRUB senza poter aprire neanche un browser di fianco per documentarmi, e siccome risolvere i problemi senza interfaccia grafica spesso fa sollevare il panico nelle utenze che osservano vicino; ho riavviato il computer da una mia chiavetta USB esterna che tengo per queste occasioni per analizzare la situazione da un sistema operativo funzionante. Per avviare il sistema dalla periferica esterna ho dovuto riavviare il computer premendo ripetutamente il pulsante F2 (ho impiegato circa tre tentativi - se ricordo correttamente F12 non avviava il menu di selezione che mi aspettavo, e F1 avviava il boot via rete PXE).
Analisi:
Una volta avviato il sistema live dalla mia chiavetta, ho potuto lanciare w:it:gparted per analizzare le partizioni. La partizione di boot in formato FAT32 risultava - in effetti - danneggiata.
Azioni:
Ho applicato la risoluzione automatica della partizione danneggiata usando gparted stesso (onestamente senza sperare troppo in una risoluzione, poiché il formato FAT32 è un formato proprietario di Microsoft e mi era capitato che `parted` si lamentasse dell'impossibilità di auto-correggere la partizione. Invece....) gparted ha risolto il problema segnalato nella partizione di boot. Ho allora riavviato il computer, constatando però che il problema originario non era ancora rientrato.
Ho allora investito altri 10 minuti sull'attivazione di un ambiente `chroot` funzionante (https://superuser.com/a/111215/390314) con l'intenzione di lanciare `update-grub` come faccio di solito. Nonostante avessi montato tutti i dispositivi speciali come al solito, ho avuto questo problema nel lancio di `update-grub`:
/usr/sbin/grub-probe:error:failed to get canonical path of /cow
Mi sono documentato (https://unix.stackexchange.com/q/96977) senza però risolvere, neanche creando il file vuoto come suggerito in https://unix.stackexchange.com/a/659712 o altro.
Ho allora utilizzato semplicemente Boot Repair come proposto fin dall'inizio. È stato come sempre sufficiente installarlo come da guida. Si avvia da solo dopo l'installazione. Si pigia "OK OK OK avanti avanti avanti OK" a caso spegnendo il cervello, e di solito il problema rientra. Così è stato. asd.
Ho informato Dario che il suo problema era stato risolto magicamente da Boot Repair - e che se proprio ci teneva potevo leggergli a voce 2K righe di report tecnico di Boot Repair per capire quale fosse davvero il problema originario. Dario ha sorriso e ha rimesso nello zainetto il suo portatile aziendale - ora funzionante - e ci siamo salutati cordialmente. Ho scorso velocemente il report di Boot Repair per vedere se qualche cosa assurda saltava all'occhio. Non ho notato niente di particolarmente interessante, quindi ho buttato il report nell'immondizia. asd
Cosa è andato bene:
Per Dario è andata bene che un membro volontario della commissione tecnica (e quindi con NDA firmata) avesse tempo per prestare assistenza e avesse con sè una chiavetta USB pronta e avesse già incontrato quel problema in precedenza. In generale è andata bene che Dario è potuto tornare operativo durante l'evento.
Per Wikimedia Italia è andata bene perché non è stato necessario disturbare l'assistenza tecnica di Tuxedo, cosa che ha fatto risparmiare tempo all'amministrazione e denaro all'organizzazione.
(Attenzione a non fraintendermi: in altri contesti NON raccomando a Wikimedia Italia di affidarsi a persone tecniche "a caso" in una stanza di un hackaton. Bisognerebbe sempre affidarsi all'assistenza ufficiale come prima opzione, o, a persone con una NDA firmata - siccome durante questo tipo di assistenza tecnica si ha ovviamente totale accesso ai dati della persona coinvolta, e questa persona potrebbe accedere, estrarre, manipolare, compromettere i dati e i software sul dispositivo, installando malware o spyware ecc.)
Per Valerio è andata bene che Boot Repair nel 2024 sia ancora un tool decisamente semplice e funzionale e lo consiglierei ancora per risparmiare tempo.
Con tutto il rispetto per il nostro movimento, è anche andata bene che era il primo giorno, quindi, l'aria nell'hackaton room non profumava ancora di "80 calzini di 40 Wikipediani molto operosi" - come spesso irrimediabilmente capita quando metti così tante persone a produrre codice per tre giorni di fila. asd (cosa che comunque si è puntualmente verificata al terzo giorno di hackaton - inutile tentare di negarlo in questo report in cui ho dovuto giurare di non omettere alcuna verità asd)
Cosa è andato male:
Se avesse funzionato la multi-selezione di avvio che si attiva solitamente con F12 avrei avviato prima la mia chiavetta, risparmiando 5 minuti.
Se avesse funzionato il primo tentativo di `update-grub` da `chroot` avrei risparmiato altri 10 minuti.
Dove abbiamo avuto fortuna:
Dario ha avuto fortuna di poter risolvere in pochi minuti un problema che era potenzialmente legato a corruzione del filesystem / problemi hardware / perdita irreversibile di dati.
Valerio ha avuto fortuna che la chiavetta live-USB Ventoy in tasca fosse ancora perfettamente funzionante. Altrimenti sarebbero stati investiti altri 10-20 minuti per scaricare l'immagine ISO e ri-scrivere la chiavetta.
Tempo totale del disservizio:
"1-2 giorni"
Tempo totale della risoluzione:
20-30 minuti saluti compresi.
Extra: aiuto con Eventyay e Giggity
- Martedì 6 agosto - per tutta la settimana
Siccome il software libero Eventyay è stato (fortunatamente) adottato per la seconda Wikimania di fila, e siccome non mi faccio i fatti miei, e siccome ho incontrato diverse persone nei corridoi che trovavano fastidioso doversi collegare ad un sito web (Eventyay) per vedere il programma completo e aggiornato, e siccome in effetti ho alcune critiche costruttive su Eventyay ma non mi piace quando questo si estende ad un generale risentimento negativo nei confronti di tutto il mondo del software libero...;
Ho quindi informato più persone possibili sul fatto che Eventyay supportasse diversi formati aperti di export proprio per dover evitare di navigare sul sito ufficiale (cosa che invece non era possibile durante Wikimania 2021 e 2022 online e questo quindi lo considero un nettissimo miglioramento - vedi mio report m:wikimania:2021:Present and future e m:wikimania:2022:Present and future); ho quindi informato dell'esistenza di una comoda app per Android chiamata Giggity, usata soprattutto durante la conferenza annuale w:it:FOSDEM, per navigare appunto nel fitto e bestiale programma del FOSDEM, comodamente offline, con aggiornamenti non appena torna la rete, e con notifiche sul prossimo evento di interesse, visuale a griglia oppure corrente / futura, ecc. Questo è stato anche un motivo per far conoscere il FOSDEM.
Per far funzionare l'app è sufficiente installarla, per esempio dallo store proprietario Google Play o dallo store libero w:it:F-Droid:
https://f-droid.org/it/packages/net.gaast.giggity/
E poi incollando in Giggity il seguente indirizzo che si otteneva visitando Eventyay e cliccando su Add to Calendar > Sessions XML (da desktop):
https://wikimania.eventyay.com/2024/schedule/export/schedule.xml
Mi hanno consigliato di promuovere l'app Giggity anche nella chat di Wikimania (https://t.me/wikimaniachat/23995) cosa che ha spinto circa una decina di persone a farmi domande in privato su come funzionasse l'app. Alcune persone si sono lamentate della modalità a griglia che aveva le gesture un po' caotiche. Siccome è un problema noto e concordo (https://github.com/Wilm0r/giggity/issues/370), ho consigliato a diverse persone la modalità "Now and Later" che è nettamente più accessibile e hanno tutti apprezzato.
P.S.
Con alcune persone a caso che invece erano già abituate al FOSDEM ho potuto avere una bella conversazione sul formato XML di interscambio, formato che personalmente considero molto funzionale ma un po' limitato, e che comunque vorrei fosse adottato da altri siti di eventi proprietari (affinché sia possibile evitare di navigare sui loro siti proprietari). Sul formato dell'evento ho potuto scambiare pareri in qualità di autore del CMS del Linux Day Torino (https://gitlab.com/LinuxDayTorino/LinuxDay-Torino-website) che appunto esporta gli eventi in quel formato, nonché come contributore di un'app per vedere il programma del Linux Day Torino e che appunto si basa su FOSDEM companion per ingestire quel formato (https://github.com/LinuxDayTorino/LinuxDay-Torino-companion-Android). Generalmente ho raccomandato a tutti di NON creare nuove app come abbiamo fatto noi ma di rafforzare quelle già esistenti, data la quantità di lavoro mostruosa dietro la creazione di ogni app.
Almeno altre 3-4 persone con iOS sono riuscite comunque ad importarsi il programma sul telefono esportando gli eventi in formato iCal da Eventyay (da un menù che è nascosto da mobile). Anche questa è una funzionalità che generalmente non è concessa da soluzioni proprietarie, o comunque non è generalmente possibile senza registrarsi, e invece Eventyay lo permette. Lo svantaggio di questa soluzione è che poi non è semplicissimo aggiornare gli eventi ottenuti in locale. Quindi consiglio comunque Giggity.
Data la quantità di feedback che ho raccolto su Eventyay ho poi partecipato alla apposita sessione nel programma.
Extra
Sessione: Eventyay Insights and Feedback: AMA with Mario Behling and Wojciech Pędzich
- Mercoledì 7 agosto 2024 - https://wikimania.eventyay.com/2024/talk/NF8MDL/
Questa è stata una Meta-sessione per incoraggiare a ricevere segnalazioni di problemi tecnici di Eventyay (il software libero in uso per mostrare il programma a Wikimania Katowice). Sessione tenuta dal carismatico Mario Behling di FOSSASIA, il quale è la principale persona con cui parlare riguardo l'aver portato Eventyay già da Wikimania a Singapore ed essere riuscito a continuare questa direzione anche qui a Katowice.
Il clima generale dei partecipanti sembrava... "finalmente posso andare in questa stanza a parlare con qualcuno per dire quanti problemi ho trovato su Eventyay". Clima comprensibile, perché Eventyay alla versione corrente aveva davvero molte evidenti criticità, ma non sarebbe stato simpatico mantenere questo clima di sfogo per mezz'ora di fila. Mario è subito riuscito a stimolare i partecipanti a condividere sì le molte critiche nell'aria, ma in modo positivamente Wikimediano, quindi, con pazienza, accuratezza, comprensione reciproca e spirito di collaborazione e avanzamento.
La sessione è iniziata mostrando i punti di forza filosofici ma soprattutto pratici, unici di Eventyay (export in 4 formati, varie modalità di visualizzazione, nessuna necessità di login, neanche per mettere i preferiti, possibilità di esportare solo i preferiti, programma multi-lingua ecc.). Questo ha aiutato molto ad aumentare il valore percepito di questo strumento.
La sessione di 30 minuti è avanzata dando la parola a più di 15 persone e alle loro relative segnalazioni. Si capiva che Mario aveva già parlato con diverse persone nei corridoi nei giorni precedenti e aveva già un'idea abbastanza chiara di molti problemi, ma durante la sessione li ha comunque catalogati tutti alla lavagna. Esempi (tradotti):
- "su mobile non si vede il tasto login"
- (problema che onestamente ho riscontrato anche io).
- → Mario ci ha tenuto a spiegare che il problema era probabilmente causato dall'eccezionale quantità di lingue per Eventyay (il programma Eventyay era infatti stato tradotto in 5 lingue: Inglese, Arabo, Spagnolo, Francese, Polacco). Questo ha quindi fatto slittare il link del login fuori dal layout visibile. Questa probabilmente è una variazione CSS minore.
- "su mobile quando esporto gli eventi ottengo solo i miei eventi - potreste aggiungere la funzionalità di esportare tutti gli eventi?"
- (inizialmente ho pensato: eh sì! è importantissimo)
- → Mario ha ricordato che ci sono 8 opzioni di esportazione e tutte includono "solo i miei" oppure "tutti" quindi probabilmente la funzionalità è già implementata ma è stato fatto un click sull'opzione sbagliata.
- (effettivamente sono andato a controllare ed era esattamente così)
- → Mario ha aggiunto che probabilmente non era necessariamente colpa dell'utente ma magari c'era un problema di layout per cui si crede di cliccare su un'opzione ma in realtà si sta cliccando su un'altra (nascosta per errore per problemi di layout).
- "su mobile, ogni tanto, la pagina non si carica la prima volta, e devo ricaricarla"
- (cosa che onestamente anche a me era capitata una volta, ma non sono più riuscito a riprodurre il problema, neanche svuotando la cache)
- → Mi ha stupito che Mario non abbia risposto "eeeeeeh 'sti*****" o qualcosa del genere poiché è quello che avrei risposto io asd. Invece, se l'è appuntato, ringraziando.
- "su mobile non viene occupato tutto lo spazio orizzontale disponibile nella visuale a calendario"
- (effettivamente capitava anche a me)
- → Mario ha suggerito di utilizzare la visuale a "Sessioni". Effettivamente quella funzionava discretamente bene su mobile.
- "su mobile, la visuale a 'Sessioni', su un particolarissimo browser libero chiamato Fennec, il layout ha troppo margine a destra"
- Questa segnalazione mi ha fatto cadere dalla sedia perché sorprendentemente stavo usando esattamente quel browser di nicchia MA... NON sono riuscito a riprodurre quel problema... mi sono sentito in dovere di avvicinarmi alla persona segnalante per mostrare che sul mio telefono purtroppo non riuscivo a riscontrare il suo problema. Mi ha guardato con una certa incredulità per il fatto che lui non fosse l'unica persona nella stanza con quel browser. Guardando sul suo telefono vedevo però il sito di Eventyay con tema scuro, mentre io lo vedevo con tema chiaro, ma non mi risultava ci fosse un'opzione per cambiare tema, quindi ho ipotizzato che forse aveva qualche estensione installata per cambiare lo stile dei siti (tipo Greasemonkey), e forse era guasta e avremmo dovuto disabilitarla. Ho condiviso questa ipotesi (il tutto bisbigliando al fondo, mentre la sessione proseguiva...) e la persona ha detto che no, non aveva estensioni in Fennec, non usava Greasemonkey, e semplicemente aveva il tema scuro attivato sul telefono. Ho condiviso che anch'io avevo solo il tema scuro attivato e che il mio tema scuro funzionava in altri siti web (tipo https://forum.linux.it/ che vedo nero anche da sloggato) ma io Eventyay lo vedevo chiaro. Ci siamo guardati perplessi, incapaci di capire chi dei due avesse davvero un problema, e abbiamo entrambi pensato ad alta voce "boh, allora 'sti*****", ognuno pensandolo intensamente nella propria lingua. Mi sono riseduto al mio posto. Intanto mi ero "perso" 3-4 altre segnalazioni; Mario ha continuato a sorridere a tutte le segnalazioni che intanto arrivavano.
- ...
- "su mobile, ogni tanto non si riesce a leggere i menu in alto"
- → Mario ha spiegato che probabilmente non aiutava aver scelto come immagine di sfondo una foto carina di Katowice tutta blu e bianca, non molto compatibile con il testo bianco in sovrimpressione.
- Ho pensato che effettivamente era vero e che bastava qualche aggiustamento di CSS.
- "sarebbe proprio utile creare un'app per Wikimania per dispositivi mobili"
- (ho spalancato gli occhi siccome comprendo che suoni come una buona idea ma ho una forte opinione a proposito cioè NO. asd)
- → Mario ha risposto che sarebbe da valutare, e sarebbe fattibile, ma che forse sarebbe più comodo investire in una webapp responsive, o una webapp progressiva, e non un'app nativa.
- Ho chiesto la parola per dire che concordavo con Mario ma soprattutto volevo raccomandare di non creare un'app per ogni singolo tipo di conferenza perché questo è il genere di software che poi viene abbandonato dopo una edizione. Se proprio servisse un'app nativa converrebbe di più sostenere lo sviluppo software di app come Giggity - e ho mostrato a tutti che dal mio telefono vedevo il programma anche se ero in modalità aereo - cosa che ha scatenato grandi relazioni di sorpresa in diversi volti - e che possono essere usati per centinaia di eventi, inclusi Wikimania. Le modifiche da poter apportare sono poco dispendiose, come per esempio aggiungere ogni anno il default dell'evento Wikimania in Giggity, così la gente non deve aggiungerlo a mano (e.g. https://github.com/Wilm0r/giggity/pull/367) ecc.
- → Mario ha affermativamente scosso la testa durante tutto il mio monologo aggiungendo che sì, effettivamente ci sono tante app in giro e le comunichiamo poco e potremmo fare poco di più.
Mario ha continuato a segnare tutto sulla lavagna in modo attento, ringraziando con wikilove ogni persona.
E altre cose - quasi totalmente riguardanti i dispositivi mobili. Questo mi ha fatto riflettere sul fatto che il backend di Eventyay ne era uscito praticamente senza critiche, e davvero la quasi totalità delle richieste riguardavano schermi piccoli, quindi la direzione per il progetto è sicuramente quella di investire più tempo in quel frangente con chi fa sviluppo web frontend.
Applausi e ringraziamenti generali a Mario. Neanche un pomodoro lanciato contro la scritta Eventyay sulla lavagna. Obiettivi quindi raggiunti.
Al termine della sessione ho ringraziato Mario per aver aiutato parecchio a creare un clima positivo, nonostante il rischio di "clima di lamentele da sportello delle Poste".
Ci siamo dati appuntamento al banchetto FOSSASIA per continuare a parlare dell'argomento fra noi due, e per analizzare insieme i risultati delle mie interviste ai capitoli Wikimedia riguardo al software libero e proprietario adottato. Ne parlo a parte.
Extra: incontro di persona con Mario Behling di FOSSASIA
- Mercoledì 7 agosto 2024
Dopo la sessione di Mario Behling di FOSSASIA (https://fossasia.org/team/) mi sono spostato al suo banchetto per parlare in privato con calma.
Alcuni degli argomenti trattati e appunti:
- sistematizzare l'inserimento di Wikimania come default in Giggity
- In pratica, facendo questa modifica ogni anno, prima dell'evento: https://github.com/Wilm0r/giggity/pull/367
- Mario concorda.
- Ho mostrato a Mario il risultato delle interviste alle org Wikimedia sul software in uso ed in particolare Zoom e Google Calendar e Google Drive - m:FLOSS-Exchange/Matrix. A volte molte org hanno solo bisogno di una Nextcloud integrata ad una BigBlueButton e fine.
- Abbiamo discusso sul core business attuale di Nextcloud. Ad entrambi ci risultava che al momento Nextcloud NON facesse "as a service" (cosa che serve più o meno a tutte le piccole-medie organizzazioni come per esempio Wikimedia Italia, che lo usa as-a-service, e Wikimedia Svizzera che lo usa self-hosted). A Mario risultava che Nextcloud ora fosse concentrata su medio/grandi appalti governativi per fornire assistenza su Nextcloud, sull'infrastruttura esterna del cliente stesso. Anche a me risultava che altre società si occupassero di questi servizi e che non lo facesse Nextcloud in primis ma non ne ero così sicuro. Comunque Nextcloud non è un servizio solitamente erogato da FOSSASIA. Mi ha chiesto se conoscevo società che prestassero questo servizio per i capitoli. L'ho informato che il fornitore di Nextcloud di Wikimedia Italia è Cloud68 da anni e che non mi risultavano problemi, e che la stessa cosa la stavo valutando con Wikimedia Svizzera proprio in quei giorni, sebbene in Svizzera ci sia CH-Open che anche eroga BigBlueButton.
- l'ho informato che sia io che un'altra persona dall'albania (w:m:User:Arianit) avevamo sottoposto un talk legato esattamente all'adozione di software nelle org Wikimedia, e che la cosa era stata bocciata, e mi chiedevo se il prossimo anno avremmo magari potuto fare squadra per avere una submission più robusta. Mario ha detto che era una buona idea. Ne ho già parlato qui:
- ho anche ingiustamente sfruttato il banchetto FOSSASIA per chiacchierare con chi era attratto dal "badge magic" di FOSSASIA. Per esempio si era avvicinata una persona di Wikimedia Korea (m:위키미디어 한국) che non avevo intervistato in m:FLOSS-Exchange/Matrix e ho ottenuto il suo contatto, creandogli parecchia confusione perché gli interessava solo il "badge magic". asd. Ho poi promesso a Mario che non gli avrei più rubato la gente del suo banchetto. asd asd