Wikimania 2024/Report/Valerio Bozzolan

Da Wikimedia Italia.
Jump to navigation Jump to search

Questo è il report personale della partecipazione di User:Valerio Bozzolan a Wikimania 2024 a Katowice (Polonia) come volontario.

Questi tipi di report sono condivisi da tutte le persone a cui è stata assegnata una borsa di viaggio per tale evento (per conoscere la commissione borse o altre cose - vedi la pagina Wikimania 2024).

Il punto di vista è strettamente personale. Edit comunque ovviamente benvenuti.

Tempo investito in questo report: circa 10 ore (O.o)

Extra: Italian Linux Society Tech Boost "Wikimania Katowice"

Lunedì 5 agosto - mercoledì 7 agosto

Nel viaggio di andata e ritorno ho avuto del tempo libero per fare i seguenti avanzamenti sul gestionale interno di Italian Linux Society - associazione con cui abbiamo convenzione asd (Convenzioni/2023/convenzione Italian Linux society - WMI) - sui seguenti punti che nessuno noterà ma che migliorano il modo con cui ci prendiamo cura dei soci che amano le libertà digitali. asd

  • GitLab CI: add support to parallel stages (down from 4 minutes to 2 minutes)
  • GitLab CI: add support to unit tests needing a database (now using docker-compose)
  • AccountRow: add "amount" virtual attribute (#110)
  • PayPal file manual import: drop legacy unmaintained feature
  • Movement: make identifier nullable to add unique index (#109)
  • Movement: harden duplicate checkers (with/without identifier) (#83)
  • MovementController: fix PayPal debugger
  • Movement: add year pseudo-attribute

https://gitlab.com/ItalianLinuxSociety/ilsmanager/-/merge_requests/80

https://t.me/ItalianLinuxSociety/2/8078

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:

[Session] Google Meet, Slack, Zoom, YouTube… and other Bugs in Wikimedia Movement - Getting Ready for Emergency Exits 🌈

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:

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)

Questa proposta è stata rifiutata.

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: incontro di persona con Mario Behling di FOSSASIA

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.

Sessione: What tools you can use to fill Structure Data on Commons files

Mercoledì 7 agosto 10:30-10:55 stanza Belgrade (8) - https://wikimania.eventyay.com/2024/talk/NCJD9F/

Sessione allucinante tenuta da User:PMG ovvero la persona che ha il più grande numero di contributi nell'universo per quanto riguarda l'aggiunta di dati strutturati nei file delle categorie di Wikimedia Commons (Commons:Structured data), usando il tool semi-automatico Wikicrowd che sostanzialmente si occupa di visitare le categorie di gente con un gelato in mano per poi salvare nei dati strutturati della foto se c'è un gelato nella foto o meno. Cosa non semplicissima da fare, come dimostra questa foto:

https://wikimania.eventyay.com/media/2024/submissions/NCJD9F/resources/2024-04-10_12h31_25_21RcoLc.png

↑ Qui c'è o no del gelato? Boh. Secondo me sì. Ma non scendiamo nel dibattito. asd

Questo tool Wikicrowd sembra aver impegnato parecchio il tempo di PMG siccome ha 4.5+ milioni di edit su Commons (!!!!) e siccome l'utenza PMG sostiene di aver visualizzato ed editato ogni-singolo-gattino di tutta Wikimedia Commons (!!!!!!!!). Accipigna. asd Non credevo di poter condividere nulla di rilevante né per questo pubblico così informato né figuriamoci per chi stava presentando che è una divinità vivente di Commons... E INVECE si è presentata l'occasione di essere utili, quando hanno mostrato il fantastico tool AC/DC (creato da Lucas Werkmeister) ma NON hanno fatto vedere una cosa bellissima che avevo studiato e fatto rilasciare nel 2021/2022 quando avevo fatto un po' di revisione in Cat-a-lot per far sì che fosse generalmente più comprensibile e utilizzabile dall'esterno

https://commons.wikimedia.org/w/index.php?title=User%3AValerio_Bozzolan%2FMediaWiki%3AGadget-Cat-a-lot.js&diff=617045300&oldid=617020455

https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-Cat-a-lot.js#Making_a_stable_version_of_getMarkedLabels()

Quelle modifiche del 2021 erano per convincere appunto Lukas Werkmeister nel migliorare la dannata "selezione" del suo AC/DC che era sostanzialmente inesistente (parentesi: di solito non è buona pratica convincere nessuno a produrre del codice - meglio farselo da soli - ma quando vedi un repository in cui chi ha toccato il codice in tutti questi anni è soltanto Lukas Werkmeister e quando vedi che il codice è minificato su Commons e quindi non puoi migliorarlo da solo - e quando vedi che l'unico modo di contribuire è su GitHub, ma dal momento in cui mi fa schifo GitHub perché è un prodotto proprietario della Microsoft - e dal momento in cui solitamente lavoro con JavaScript vanilla o jQuery ma evito "npm", beh, allora ho deciso di convincere Lukas a fare al modifica asd). Gli ho detto: immagina di avere Cat-a-lot e poter selezionare molte foto. Ecco. Già la gente lo fa. Questo invece NON è possibile in AC/DC che invece ragiona quasi esclusivamente sull'intera categoria (o con una cosa potentissima chiamata "PagePile" che onestamente nessuno che conosco sa usare). Quindi, volevo convincere Lukas che fosse una indea straordinaria integrare la compatibilità di selezionare file con Cat-a-lot (= tutte le persone sanno cliccare = tutte le persone sanno farlo) e che sarebbe stata la cosa più intuitiva del mondo usare quel selettore per poi attivare AC/DC! E così è stato \o/ ed è stata integrata la modifica nel 2022 asd.

https://github.com/lucaswerkmeister/ACDC/issues/12

Non ho detto nulla di tutto questo lì nella stanza ovviamente. Nel momento delle domande ho solo mostrato il mio schermo, per far vedere che attivavo Cat-a-lot, selezionavo 3-4 foto, e poi AC/DC capiva che erano state selezionate 3-4 foto e lavorava solo su quelle. Dal fondo dell'aula almeno una persona ha sgranato gli occhi violentemente per lo stupore di questa cosa incredibile di poter addirittura cliccare su un file per lavorare solo su quel file (asd). Mi sono voltato verso il relatore che ha secondo me nascosto la sua sorpresa, per invece dirmi "eh ma questa non era una domanda - ci sono altre domande?" lol. Nessuno ha fatto altre domande ed è finita la sessione con grandi applausi verso PMG e tutto il parco tool. asd

Vedi: Wikimania 2024/What tools you can use to fill Structure Data on Commons files

Extra: Phorge (ex Phabricator) Tech Boost

Durante e dopo l'evento

Ho avuto sufficientemente tempo libero per fare triage, code review, e sviluppo software sul software Phorge. Come sapete Phorge è il software utilizzato da Wikimedia Foundation come bug tracker per implementare Wikimedia Phabricator. asd

Ecco i Task su cui ho lavorato attivamente come autore principale o in cui comunque ho almeno analizzato il problema e implementato una soluzione graziosa:

Patch di altre persone che ho revisionato, testato e approvato nel branch master durante la settimana:

Altri task su cui non ho avuto il tempo per trovare una soluzione decente:

Lunga vita a Phorge \o/ asd

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.

Vedi #Sessione: Eventyay Insights and Feedback: AMA with Mario Behling and Wojciech Pędzich

Extra: interviste a tappeto ai capitoli Wikimedia per questionario software

Durante tutta la settimana

Durante tutta la settimana ho intervistato una vagonata di persone che lavoravano in varie Wikimedia, quasi no-stop, con l'obiettivo di catalogare tutti i principali software in uso nella pagina m:FLOSS-Exchange/Matrix che ho già citato. Ho intervistato e ringrazio (da chi ho intervistato più di recente, alla meno):

Il risultato è che le organizzazioni intervistate sono passate da 21 a 32.

L'unica organizzazione che si è "compilata da sola" è Wikimedians of Albanian Language User Group e fra l'altro è l'unica organizzazione al momento presente che elenca SOLTANTO software libero. Questo mi ha spinto per il prossimo anno a dare un premio a questo tipo di gruppi/organizzazioni virtuose.

Hackaton: come aggiornare una cella - con VisualEditor core developer Bartosz

Questa è una sezione maledetta. Non leggerla.

Potra sembrare ovvio ma la tabellona in m:FLOSS-Exchange/Matrix ha spinto VisualEditor ai suoi limiti fisiologici.

Avevo la futuristica necessità di... fare una somma... ovviamente questa mia richiesta è una delle sottili cose che distingue ciò che sembra virtualmente banale da implementare, da ciò che invece è virtualmente impossibile. Infatti mi aspetto che le somme nelle tabelle wiki non saranno mai una cosa a disposizione del pubblico, nemmeno nel 2030, perché altrimenti verrà voglia di re-implementarsi LibreOffice e sarebbe una idea spaventosa. Davvero.

Ho quindi scritto qualche riga di JavaScript per contare le mie celle e aggiornare le mie somme con la promessa di non generalizzare mai la cosa. La cosa funzionava, ma non riuscivo a salvare la pagina.

Non ero in fatti in grado di informare VisualEditor che davvero qualcosa era cambiato in una cella (!) Io vedevo il cambiamento in modifica, ma VisualEditor non lo sapeva. Quindi, non riuscivo mai a salvare la pagina.

Per comprendere il funzionamento interno di VisualEditor sono entrato nella stanza hackaton e ho urlato qualcosa tipo "C'è una persona che conosce un pochino il core JavaScript di VisualEditor e a cui posso offrire un biscotto?". Si è presentato m:User:Matma Rex (Bartosz Dziewoński) che è risultat* disinteressat* al cibo ma è risultat* estremamente interessat* al problema proposto e ha concordando con me che la particolare cosa che volevo fare (= aggiornare una specifica cella) suonasse come quel tipo di cose che sembrano molto semplici ma sono in realtà virtualmente impossibili bla bla. Ci abbiamo provato lo stesso.

Lasciando stare le proposte intermedie, ecco il risultato finale per aggiornare una cella da jQuery \o/

(2 ore di lavoro)

function writeTextInCell($cell, v) {
  var s = ve.init.target.getSurface();
  var view = $cell.data('view');
  var range = view.model.getRange();
  var m = s.getModel();
  var fragment = m.getLinearFragment(range);
  fragment.insertContent('' + v);
};

Ora che avevamo condiviso a tutti il potere di... aggiornare una cella (!!!) ho integrato questa cosa nel mio accrocchio spaventoso e sono riuscito a salvare almeno 2 ore di vita al giorno (OK, questa non suona come un vantaggio se abbiamo impiegato 2 ore quel giorno - vabbeh - asd) e ho corretto parecchi errori umani che avevo introdotto facendo le somme a mano fino a quel momento...

Ecco il pezzo di software schifosamente funzionante - tappate gli occhi alle persone sensibili vi prego:

m:Talk:FLOSS-Exchange/Matrix#SUM

Le somme! Capite? LE SOMME! WOW!

Grazie Bartosz.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 entrambe le proposte erano state bocciate, 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:
    #Proposta di sessione: The importance of using Free and Open software in all activities of the Wikimedia movement: situation, opportunities and next steps
  5. 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

Sessione: Wiki Sud Italia: challenges of creating an active community in an economically challenged region

Giovedì 8 agosto 13:30–13:55 - stanza Tbilisi (7) https://wikimania.eventyay.com/2024/talk/9ATRXV/

In questa sessione siciliana sono stato bravissimo perché NON mi è assolutamente MAI saltato in mente di presenziare per capire come diavolo fosse possibile che fosse stato accettato un talk così locale/regionale in una conferenza internazionale, in un momento in cui conoscevo così tante persone a cui era stata rifiutata una sessione su un tema internazionale asd (sessione sul software libero compresa asd) asd

Penso che neanche Léa e Ferdinando si aspettassero una sessione così partecipata. Dopo aver chiesto alle persone se c'erano idee per risollevare la community del sud Italia, è stato commovente la persona volontaria di Wikimedia Community User Group Malta che ha chiesto di considerare Malta un po' come estensione della Sicilia. Standing ovation dei relatori e relatrici e non ho altro da dire. Non sono a conoscenza degli obiettivi di espansione ma direi raggiunti.

P.S. Se questa nota sull'intervento di Malta manca in qualche report di altre persone su questa sessione, è probabilmente il segno che quel report non ha senso. asd Questo mi fa ricordare che in questo preciso momento si sta promuovendo la proposta di itWikiCon 2025 in Sicilia ma ancora nessuno lo sta facendo girare a Malta - lo notifico (https://t.me/WikimedianiSicilia/788). asd

Sessione: Co-Creating a Sustainable Future for the Toolforge Ecosystem

Venerdì 9 agosto 13:30–14:10 · stanza Dilijan (3) https://wikimania.eventyay.com/2024/talk/7HGAWS/

Nonostante il tema "Toolforge" abbastanza altisonante, la stanza era inizialmente stranamente vuota. Hanno dovuto ritardare l'inizio per far sì che avesse un senso iniziare.

(Ho pensato che probabilmente molte persone stavano semplicemente chiacchierando dopo la pausa pranzo, allora ho aiutato a fare un po' da "buttadentro" comunicando l'evento in chat asd (https://t.me/wikimaniachat/24592) e portando gente a caso facendo sapere dell'evento "venite venite abbiamo biscotti" asd. Alla finela stanza comunque non si è riempita. Boh.)

La relatrice Slavina Stefanova (WMF, Cloud Services - conosciuta di persona a Singapore) inizia a sottoporre la questione: abbiamo più di un migliaio di tool, migliaia di documentazione, riusciamo a darci "obiettivi" / "metriche di successo" / "qualcosa" per aiutare a spiegare quali sono i tool che stanno "facendo meglio"? sono quindi più sostenibili?

All'inizio ho trovato ci fosse un po' troppa leggerezza nell'uso del termine "sostenibilità" in quanto era utilizzato come sinonimo di "fare meglio del software insieme".

Nella sessione mi sono molto divertito anche per il vasto spazio lasciato alle domande che tenterò di riassumere :D

Siccome fra le metriche intraviste c'erano cose abbastanza strane e scontate tipo "il progetto ha un README?" oppure "Il progetto ha un file LICENSE?" - mi sono permesso di condividere tre domanda abbastanza spontanee:

  1. quale sarebbe lo scopo finale? Nel senso, anche ipotizzando di essere riusciti a produrre questi "sustainability key performance indicators" (anche se non li hanno chiamati così) e ipotizzando di avere dei valori abbastanza attendibili per la maggior parte dei tool di Toolforge... poi? Immagino si possa togliere risorse o chiudere velocemente i tool "meno utili"? dare più risorse computazionali ai tool più strategici? → Potrei sbagliarmi ma credo che chi presentava avesse sostanzialmente sostenuto che questa mia domanda avesse senso e che non era ancora stata fatta una definizione un po' robusta di "cosa fosse sostenibile" e che fosse un po' presto dirlo. Ripeto, mi riascolterò la risposta ma mi è sembrata una situazione un po' strana. Forse "capire cosa è sostenibile" era la prima cosa da cercare di definire. Ho passato il microfono ad altre domande cercando di riflettere sul nostro scopo nel mondo asd.
  2. Altra domanda. In che senso il punto "il progetto ha una licenza?" è una misura di sostenibilità? chiedo perché produrre progetti software con una licenza libera è un requisito per essere hostati in Wikimedia Cloud (requisito punto 4.3 dei Cloud Services Terms and Conditions asd) quindi forse non dovrebbe essere parte di una valutazione "aggiuntiva" sulla sostenibilità. Forse dovremmo separare requisiti di base dai fattori di sostenibilità. → Chi presentava ha accolto che sì, così com'era scritto "Avere un README" o "Avere una licenza" erano metriche di base ma ci sono progetti in cui la licenza o la documentazione non sono evidenti mentre usi lo strumento in sè e/o mentre navighi il repository. Ho compreso la situazione che effettivamente capita sovente (per esempio, mentre usi lo strumento per dare il credito giusto alle foto di Commons, niente ti dice che quello è un gadget, niente ti dice come si chiama, niente ti dice la sua documentazione; ma tutto questo c'è - se li trovi... asd). Ci sta.
  3. Nessuno faceva più domande allora, be bold, ne ho condiviso un'altra: Questa potrebbe essere un'occasione per "premiare" i tool che condividono il software su repository completamente liberi, come per esempio la meravigliosa Wikimedia GitLab che già abbiamo? quindi dando meno punti a chi usa BitBucket.com e GitHub.com? Questo permetterebbe alle persone di unirsi al movimento senza diventare clienti Atlassian o Microsoft. → La relatrice ha sostanzialmente detto che la cosa aveva in effetti strategicamente senso perché così avrebbero anche tutto sotto maggior controllo del team WMCloud asd → Qui si è sollevata una critica dal mio compagno di merende User:Waldyrious (Portogallo) che sostanzialmente ha detto che PERÒ Wikimedia GitLab non ha la possibilità di creare siti statici, quindi non ha molto senso promuovere chi usa Wikimedia GitLab perché su certe cose è ancora indietro (non mi trovo personalmente d'accordo, credo che costringere ad usarlo costringa a inventare soluzioni per questa lacuna asd - non l'ho detto) → Oltretutto Waldyr. ha precisato che non dovremmo dire alla gente chi è "cattivo" e chi è "bravo" (su questo tutti d'accordo, non è l'intenzione del progetto dire chi è "cattivo" asd). → Waldyr ha condiviso altre criticità pratiche di Wikimedia Cloud in generale che non semplificano molto a creare una community coinvolta. Su questo penso siamo tutti d'accordo asd. → Qui si è aperto uno stratosferico sostegno dicendo di migliorare la dannata documentazione di WMCloud asd. → altra persona: «VOGLIO PIÙ AUTOMAZIONE» → altra persona: «VOGLIO PIÙ CONTINUOUS INTEGRATION(s)» → «VOGLIO PIÙ CACHE» (???) → relatrice: "sarei felice di rispondere meglio, per favore apri un task" (asd) → altra persona: «AH... PIÙ DOCUMENTAZIONE PIÙ DOCUMENTAZIONE» (l'avevano giù chiesto asd) → Tutte le persone sostanzialmente erano tutte d'accordo, più aggiungevano cose che sarebbero da migliorare in WMCloud, più tutti annuivano e saltavano in mente altre cose che vanno migliorate a caso asd. → stessa persona di prima: «PIÙ AUTOMAZIONE PER LE PULL REQUEST» (ASD) → stessa persona «PIÙ DOCUMENTAZIONE PER L'AUTOMAZIONE DELLE PULL REQUEST» (ASD ASD ASD)
  4. a questo punto, Waldyrious ha sostenzialmente e coraggiosamente sollevato una critica epica sul tabù dei repository di Magnus Manske in BitBucket a cui avevo accennato prima (!!!) (eroe asd) https://www.youtube.com/live/IKtMkTIRTVk?feature=shared&t=16410 sostenendo che molti progetti software di Magnus sono poco "wiki way" cioè per esempio non hanno issue, non hanno pull request, ed è troppo complicato unirsi a BitBucket per collaborare con Magnus. (aggiungo io: questo non aiuta nemmeno molto Magnus ad avere più tempo libero, questo lo porterà solo ad avere più burnout perché tutto il carico di lavoro è su di lui, siccome è il principale maintainer e developer)
  5. hanno poi proposto di fare riunioni di Toolforge online più spesso. Penso nessuno nella stanza fosse a conoscenza di questi meeting quindi a tutte le persone è suonata come una buona idea, relatrice compresa. Bella zi'. asd
  6. a questo punto una persona ha proposto di usare MediaWiki come repository software o qualcosa del genere. What? Ho capito bene? NON FACCIAMOLO PLS asd
  7. Siccome Waldyrious ha fatto la critica sui progetti di Magnus Manske, ho ripreso la parola per sostanzialmente difendere Magnus ma al tempo stesso riportare al problema asd https://www.youtube.com/live/IKtMkTIRTVk?feature=shared&t=16792 BEH VOGLIO DIRE TUTTI QUI AMIAMO PROFONDAMENTE Magnus Manske e TUTTI amiano i tuoi software e SIAMO ESTREMAMENTE dispiaciuti se non hai potuto avere Wikimedia GitLab fin dall'inizio e se poi avevi addirittura dovuto soffrire una tentata migrazione a Differential (che è odiato giustamente da molte persone asd) ma semplicemente siamo qui per dire che BitBucket probabilmente non è il prossimo passaggio, tutto qui, grazie Magnus. (risate in sottofondo)

Extra: Hackaton Showcase senza presentare da Apple macOS

Ultimo giorno

Siccome negli ultimi 3 hackaton wikimediani a cui ho partecipato (Grecia, Singapore, Tallinn) c'era sempre il comune denominatore di dover presentare tutti i progetti da un computer con macOS,

Siccome sostituire un computer su un podio è una cosa particolarmente semplice da cambiare, soprattutto se si tiene in considerazione che nell'intera stanza dell'hackaton ho contato 15 persone con Windows, 10 persone con macOS e 30+ con GNU/Linux o FreeBSD o qualsiasi altra cosa esoterica,

Siccome ho notato un task Phabricator dedicato proprio all'organizzazione della sessione di chiusura:

Wikimania Hackathon 2024: Showcase / Closing Session

Allora ho creato il seguente dovuto sotto-task :D

Closing Session: present all sessions from a computer with a Free Software operating system \o/

Fra l'altro, non volutamente, il mio task è stato assegnato esattamente alla persona del task genitore (cosa che generalmente NON bisognerebbe fare - non bisognerebbe assegnare i task ad altre persone) - comunque aveva semanticamente senso e quindi l'ho lasciato così, evitando di fare modifiche che generassero altre notifiche inutili.

Mi sono poi dimenticato di quel task, fino allo showcase, finché ho notato che... 150 persone stavano presentando usando sempre quel computer con Google Chrome su macOS.

  1. nessuna delle persone menzionate nel task lo ha notato in tempo per discuterne?
  2. nessuna delle persone menzionate nel task ha pensato che fosse una richiesta seria?
  3. nessuna delle persone menzionate nel task ha pensato che la mia proposta di offrire il mio computer fosse sincera?
  4. nessuna delle persone si è resa conto che forse era meglio evitare un prodotto Google, ed era facile usare Firefox?
  5. nessuna delle persone si è resa conto che premendo "F11" si potevano almeno nascondere le icone di macOS e di Google Chrome nella toolbar?
  6. cosa abbiamo di così sbagliato per cui sembro l'unica persona nella stanza di 150 a cui interessa un minimo di questo aspetto, che mi sembra piuttosto poco faticoso da discutere?

Non lo so. Intanto nel task è arrivata una persona (a cui avevo assistito al suo talk) che ha iniziato a dirmi sostanzialmente che stavo scherzando, e mi ha chiuso il task. Non credo che abbia neanche investito 10 secondi per leggere la documentazione su cui avevo lavorato. Ho colto comunque l'occasione per irrobustire il punto di documentazione a riguardo, che mi sembra abbastanza serio, chiaro, e ragionevole, cioè sostanzialmente evitare di promuovere società a caso e software proprietario a caso soprattutto in eventi registrati a video e poi potenzialmente caricati su Commons:

m:Wikimedians for software freedom#Talks and Showcases proprietary environments

Onestamente l'impossibilità di cambiare anche questa minuscolo aspetto dell'hackaton e sentirsi dire soltanto e sempre "No." mi ha fatto veramente stare di merda (si può dire? credo di sì - mi ha fatto sentire di merda. Punto).

Ciò che però mi ha fatto veramente ma veramente stare di merda, è stato il messaggio pubblico condiviso dal caro André Klapper (WMF) con cui vado molto d'accordo di solito ma che, in risposta al mio messaggio in cui dicevo che mi dispiaceva che fosse obbligatorio usare "macOS", ha risposto che "non gli risultava fosse obbligatorio presentare". Un modo per dirmi chiaro e tondo "se non vuoi usare macOS, vattene e non rompere". Se non mi sono suicidato platealmente lanciandomi giù di corsa dalle scale dello showcase per buttarmi con più forza possibile di faccia contro al muro di cemento, è veramente stato un enorme sforzo di auto-controllo, e non sto scherzando, quindi preferirei lasciarlo per iscritto, siccome, dopo tutto, questi sono i miei sentimenti se mi si chiede di andarmene dalla mia community per prese di posizione della fondazione così rigide su questioni così futili.

Poi mi è passato dopo aver parlato con Mario e altra gente che ringrazio. asd

Estratto da "https://wiki.wikimedia.it/index.php?title=Wikimania_2024/Report/Valerio_Bozzolan&oldid=1285818"