Scusa Giovanni se ti sembro noioso, però ripeto: Non tutte le lezioni richiedono interattività sincrona fra studenti e alunni.

Direi addirittura che la maggioranza delle lezioni potrebbe trarre vantaggio da un canale di comunicazione asincrono, dove video lezioni distribuite via peertube (e perché no, bittorrent) si affiancassero a mailing list, slide, videocall uno a uno, faq etc...
Se non ci limitiamo a provare a riprodurre le dinamiche della scuola fisica via videoconferenza, ma proviamo a pensare ad una didattica cibernetica (ovvero capace di sfruttare efficientemente le potenzialità del mezzo, pur se non appieno a causa del poco tempo disponibile), potremmo scoprire che non è poi così difficile e costa meno banda/energia/cpu etc di quanto non costi mettere su una videoconferenza per ogni lezione in ogni classe.

Cioè è bello vivere in un epoca in cui possiamo vederci e chiacchierare pur restando a casa nostra, e ora che dobbiamo limitare gli spostamenti questa facoltà diventa socialmente e didatticamente importante.

Ma non dimentichiamoci il buon senso: Keep it simple.

Giacomo

On Monday, 9 March 2020, Giovanni Biscuolo <g@xelera.eu> wrote:
> Buongiorno Stefano, buongiorno Nexa
>
> aggiungo qualche mia considerazione da sistemista e compagno di
> un'insegnante (che mi permette di osservare una serie di esempi "sul
> campo")
>
> purtroppo non ho avuto mai modo di effettuare test sul campo, avendo le
> risorse mi piacerebbe tanto ma questo aspetto non è sotto il mio
> controllo :-)
>
> Stefano Zacchiroli <zack@upsilon.cc> writes:
>
> [...]
>
>> (Quinta: ho visto che chiedevi info su questo
>> punto l'altro giorno su Twitter, ma non ho capito se hai raggiunto una
>> conclusione.)
>
> AFAIU purtroppo le informazioni in merito alle risorse hardware
> necessarie in funzione dei partecipanti per coinferenza scarseggiano
> anche nella community Jitsi... ma non la seguo "da dentro" per cui
> potrei essermi perso qualcosa; in generale la documentazione
> *sistemistica* di diverse applicazioni web di successo è scarsina, non è
> questa solitamente la priorotà upstream (cioè del team di sviluppo
> dell'applicazione)
>
>> Si può raccomandare Jitsi senza incorrere in rischi
>> eccessivi di deludere gli utenti?
>
> assolutamente sì, nessuno può rimanere deluso da Jitsi... specialmente
> se è chiaro cosa si può aspettare da Jitsi (da considerare anche la
> qualità della traduzione della documentazione utente... ma chi legge
> oggi la documentazione utente?!? :-) )
>
> l'esperienza utente può anche essere migiorata se è integrato con il
> sistema di didattica online, tipo https://moodle.org/plugins/mod_jitsi;
> Jitsi ha anche API per poter essere integrato in altre applicazioni web
> (mai sperimentato)
>
> sarebbe interessante valutare anche altri strumenti alternativi, ma
> questo comporterebbe una pianificazione ancora più articolata rispetto a
> quella che già non si sta facendo (modulo emergenza SARS-CoV-2, che
> merita di essere affrontata come caso a sè)
>
>> Nel caso, si può raccomandare l'istanza pubblica
>
> io non credo, c'è il concreto rischio di saturarla e con questo rovinare
> la reputazione dell'intero progetto
>
> in generale, con questa Internet completamente priva di un sistema
> multicasting [1], solo aziendine come Google, Facebook e poche altre
> possono permettersi di avere una "potenza di fuoco concentrata" adeguata
> a questa emergenza, in particolare per applicazioni con discrete
> necessità di banda
>
>> oppure meglio consigliare un'installazione on premise ad hoc?
>
> sì, assolutamente sì: più distribuita è meglio è; l'ideale sarebbe avere
> una istanza per istituto, ma per reggere deve avere comunque un sacco di
> risorse se si vogliono creare stanze di circa 20 alunni per circa 40
> classi (e magari stanze anche per gruppi di docenti?); questo pone un
> serio problema di risorse *e* sistemistico, che si può risolvere solo
> con una adeguata pianificazione
>
> non fornirò dettagli nemmeno sotto tortura ma mi è giunta voce di un
> progetto da parte di un editore importante - che prevedeva tra altre
> cose la messa a disposizione di una grande istanza Jitsi - saltato
> perché i costi per istanziare i servizi su una piattaforma cloud ben
> nota erano esorbotanti, i costi per il lavoro dei sistemisti e dei
> system integrator in confronto _pare_ fossero contenuti rispetto al
> totale (anche se non ho le proporzioni)
>
> l'ordine dei problemi sistemistici per pacchettizzare Jitsi [2] per
> essere distribuito in modo riproducibile e per effettuare il deployment
> (installare le istanze di tutti i servizi necessari sulle varie macchine
> dell'infrastruttura) in modo automatizzato è molto interessante, ci sono
> diversi strumenti per affrontarli [3] ma servirebbe pianificazione e
> risorse per metterli in campo
>
> [...]
>
> cordiali saluti, Giovanni
>
>
>
> [1] https://secushare.org/broken-internet#scalability
>
> [2] per fare un esempio è dal 2013 che in Debian non si riesce a
> pacchettizzare Jitsi, dal 2017 non ci sta provando più nessuno
> https://tracker.debian.org/pkg/jitsi, anche se Jitsi ha un proprio repo
> per pacchetti Debian https://jitsi.org/downloads/
>
> [3] in particolare ritengo Guix https://guix.gnu.org/ di un ordine di
> grandezza superiore rispetto ad altri
>
> --
> Giovanni Biscuolo
>
> Xelera IT Infrastructures
>