Registro Elettronico libero

Facciamo il punto qui:

4 Likes

Mi piace, bisogna puntare molto sulla formazione perché è quello che secondo me le scuole vogliono di più.

Mi pare che c’era un fork di lampschool su github più aggiornato fatto da una scuola ma non mi ricordo granchè bene.

questo sembra avere aggiornamenti negli ultimi giorni:

il sito ufficiale dice che una scuola ha dismesso il supporto nel nov2018, in un modo da lasciar intendere che è abbandonato. Il forum vede l’ultima attività nel gen20.

Lo usa ancora qlcn?

Ciao a tutti,
sono Pietro Tamburrano, il titolare della pagina su github a cui è stato fatto riferimento nel post precedente.
Vi confermo, coe spiegato anche nel riepilogo di Valerio, che il progetto LAMPSchool non è morto ma è stato semplicemente abbandonato dalla rete DematVR che si è sciolta.
Nel frattempo altri istituti (tra cui il mio) hanno continuato (o hanno continuato) ad utilizzare il registro che ha ricevuto anche aggiornamenti riguardanti vari aspetti (tutti presenti su GitHub).
Il sito www.lampschool.it (che era di titolarità della rete DematVR) non è stato più aggiornato dando l’impressione che il progetto fosse morto.
Nel riepilogo di Valerio sto facendo qualche aggiornamento per precisare meglio lo stato del progetto.

2 Likes

Grazie mille per le precisazioni, la cosa è incoraggiante!
Mi chiedevo in generale, dovebdo partire da zero, se non fosse prioritario liberare le scuole dalla morsa di classroom, che è Google, piutttosto che dalla piccola srl italiana.
Ma se la soluzione al registro funziona ed è utilizzata, allora è più importante tenerla viva e farla crescere!

-------- Messaggio originale --------
On 2 lug 2021, 18:19, Scaforchio via forum.linux.it < nobody@discourse.example.com> ha scritto:

Questo è interessante. Si può anche dire che pilotare un progetto come questo può spingere ad offrire un registro elettronico con già sistemi Jitsi/BigBlueButton/… integrati e allora si potrebbe iniziare a mandar via anche Google Classroom.

1 Like

Io sono stato bloccato per un certo periodo di tempo col messaggio «Utente bloccato per accesso tramite App non autorizzata dall’Argo Software oppure non aggiornata alla versione minima 2.1.0» (tra l’altro loro negavano che ci fosse un blocco sull’utenza e mi suggerivano inutilmente di disinstallare e reinstallare l’app) solo perché avevo osato installare una comoda applicazione alternativa che faceva anche la media dei voti.

La “piccola S.r.l. italiana” tanto piccola s.r.l. non è, ma è una fornitrice quasi monopolistica (con poche altre aziende del settore), che crea tanto se non più danno di Google & co. da questo punto di vista.

Auspicando di non commettere un precoce necrobumping, approfitto di questo spazio per non escludere, ma per valutare attentamente la possibilità di abbracciare un principio a me molto caro, ovvero quello del non reinventare la ruota, qualora non sia effettivamente necessario e conveniente.

Seguendo la discussione, nonché la sua più recente evoluzione, mi sembra di aver capito che potrebbe essere necessaria una profonda e, per certi requisiti, evidente riscrittura di LampSchool.

Questa possibilità mi ha spinto a rinfrescare il catalogo delle soluzioni attualmente offerte e mantenute nel panorama FLOSS e, tra le tante, mi sono imbattuto nel progetto AlekSIS.

Dal nome si può intuire che si tratta di un SIS, ovvero uno school information system. È scritto in python usando il framework Django (con PostgreSQL e Redis su NGINX) ed è facilmente estendibile ed adattabile alle esigenze di un sistema scolastico nazionale, nonché singolo istituto, attraverso un sistema ad App, già discretamente completo (qui la guida all’installazione, per chi intendesse provarlo in locale, anche in 5 minuti con docker).

L’interfaccia è molto semplice e minimale (material design) e potrebbe prestarsi all’utilizzo degli operatori meno formati. Insomma un bel progetto, solido, mantenuto e promettente.

Ad occhio, attualmente la mancanza più significativa è l’assenza di una traduzione ufficiale in lingua italiana (task relativamente semplice e rapido da implementare), ma per esserne certi occorrerebbe operare una verifica side to side con le feature attualmente implementate in LampSchool e che si intendono integrare in futuro.

Nonostante fino ad ora mi sia concentrato su AlekSIS (qui il codice su EduGit), il mio è un invito a guardarsi intorno e valutare possibilità più efficienti prima di addentrarsi in imprese che potrebbero rivelarsi potenzialmente faraoniche, per difficoltà e tempi.

Mi chiedo inoltre se sia possibile programmare, oltre al mensile, qualche meeting online ad-hoc su Jitsi Meet (un po’ come accaduto per una recente metafisica questione), incontri ai quali, insieme ad alcuni compagni del Linux User Group di Caserta (LUGCE), saremmo interessati a partecipare.

Grazie per aver letto questo interminabile post :grin:

1 Like

Sono d’accordo con molti dei ragionamenti, premettendo che qualsiasi sia la soluzione a lungo termine, ora ci sono soluzioni già adottate da committenti ben delineati con richieste ben precise e con fondi disponibili e che vorrebbero semplicemente più assistenza commerciale, anche solo per piccole patch.

La licenza di questi registri elettronici incoraggia le persone a fornire servizi di assistenza commerciale, ed è esattamente quello che dovremmo fare ora. Forse possiamo provarci con questo annuncio:

Se al momento la bozza è rivolta a dev PHP è perché i fork di LAMPSchool sono in PHP, come questo:

Ma sì dovremmo rimanere aperti a vedere qual è la soluzione a lungo termine migliore, e a cercare quel profilo.

1 Like

Il mio unico dubbio è la tecnologia in cui è sviluppato. PHP da parte sua ha la comodità che ti gira sul tuo hosting dove hai già il sito e non devi avere un accesso ssh per configurare una macchina. Diciamo che per il classico professori di informatica delle superiori sarebbe troppo e quindi non lo potrebbero neanche installare, figuriamoci docker. Diciamo che per un uso self hosted una in PHP è più pratica anche perchè spesso le scuole queste cose le fanno in casa per risparmiare.

Intendi degli incontri online dove ognuno programma o si contribuisce ad un progetto specifico?

Ciao, avrei delle domande/spunti sulla roadmap (il documento di bozza condiviso), e altre domande di ordine pratico.

Roadmap:
Visto che che si sta pensando ad un programma/supporto a lungo termine (2023),
sarebbe saggio considerare un paio di punti, alla lunga lavorare/supportare 2 software così diversi sarà una “pesante” problematica, l’enorme differenza che c’è tra le 2 codebase,
è mia opinione che questo aspetto penalizzerà tutti i coinvolti nel progetto.

  • L’associazione in se, è difficile che riesca nei propri obbiettivi (1 software sicuro, stabile, performante, con un incremeto annuo delle adozioni/installazioni che va al 200%)

  • Gli sviluppatori o fornitori di assistenza tecnica sia quelli formalmente assunti che i singoli sviluppatori “volontari” le 2 codebase sono ad anni luce di distanza,
    Implementare una feature X su uno dei 2 potrebbe richiedere 3 giorni, mentre la stessa cosa sull’altra codebase potrbbe richieder 3 settimane.
    Non mi pare ci sia la possibilità di sviluppare dei package comuni tra i 2 software

  • Gli utilizzatori finali intesi come istituti, alunni, genitori, si troverebbero con un registro elettronico che va a 2 velocità diverse con una forte penalizzazione per chi usa LampSchool

Penso che come associazione/gruppo di lavoro si debba in qualche modo valutare questi aspetti e magari scrivere del codice comune che vada a pianificare per quanto possibile
la situazione attuale, altrimenti si corre il rischio di fare il triplo dello sforzo necessario, di trovare sviluppatori disposti a lavorare solo su giuia@school o di avere una selezione naturale del mercato verso l’una o l’altra soluzione

Personalmente trovo giusto in questa fase iniziale supportare entrambbi i software, ma non credo che sia una soluzione sostenibile nel lungo termine se non si trova una soluzione ai punti sopraelencati.

Domande di ordine pratico.

Ci sono dei numeri/stime sull’attuale adozione (installazioni attualmente in produzione) dei 2 software?
sarebbero utili per definire/capire su dove o cosa investire le risorse.

Eventuali post o dicussioni “Tecniche” hanno un’iter stabilito c’è un coordinamento?

  • si discute qui sul forum (questo tread? altro tread?) poi si apre issue, poi PR su l’uno o l’altro repo.
  • C’è una roadmap tecnica? comune ai 2 software o per singolo repo?

Faccio un esempio pratico invece di porre domande così “a sentimento”

Una feature comune, utile e che manca nei 2 software e un deploy/rollback automatizzato.
Se fosse ritenuta utile come procedere? chi decide se è utile o meno?

Ciao scusate la lungaggine, e vorrei precisare per evitare equivoci che non c’è nessuna critica nelle mie parole, ne verso il progetto ne verso l’uno o l’altro software. Sono solo domande per capire come essere di aiuto e massimizzare il mio e il vostro tempo.

Ciao :wave: a presto.

1 Like

Infatti uno dei commenti era di fare nel fork un importatore dal vecchio lampschool così da deprecare il vecchio progetto e passare al nuovo che è seguito.

Credo che come la proposta è definita e si trovi qualcuno disposto a fare il lavoro ci si organizza nel modo più adatto e migliore. Dopotutto dobbiamo sentire anche l’altro progetto cosa preferisce e se preferisce.

Credo che si definiranno nel contratto poi le cose da fare ecc

Il forum c’è apposta per questo :smiley:

Ho aperto una Issue sul repo lampschool ha una certa attinenza anche con il progetto di supporto al registro visto che in qualche modo si dovrà valutare il lavoro degli eventuali sviluppatori assunti tramite l’annuncio qui sul forum.

7 messaggi sono stati spostati in un nuovo Argomento: Domande su LampSchool/GiuaSchool

6 messaggi sono stati uniti a un argomento esistente: Domande su LampSchool/GiuaSchool