Riunione ILS per soli under 35

Quando ancora mi interessavo più attivamente di programmazione e testing ho segnalato diversi bug. Tra quelli che ricordo un paio in LO, uno in GIMP, un altro in una libreria FFmpeg. Similmente ho spesso segnalato problemi in webapplication ma anche in traduzioni e manualistica. I riscontri, anche solo per confermare la ricezione della segnalazione, sono stati scarsissimi. Inizialmente può darsi abbia agito ingenuamente pensando che bastasse un mail, ma in seguito ho seguito quelle che sembravano essere le procedure ufficiali.

Ovviamente si potrebbe obiettare che magari erano le segnalazione ad essere di scarso valore… e che quindi non fossero degne di risposta.

Ma a parte la mia esperienza personale, è dai tempi de “La cattedrale e il bazaar” che il fenomeno è ampiamente descritto.

Quindi non puoi contribuire ai progetti già noti perché non sei nel giro e se ne inizi uno tuo devi accettare di restare ai margini perché nessuno distribuirà mai il tuo software. Sì, un gran bell’incentivo per attirare nuovi programmatori :wink:
Banalmente un programmatore andrebbe giudicato dalla qualità del codice che scrive, non dalla sua età.

aperti finché ti offri di fare gratis la bassa manovalanza…
Mi fai un esempio di progetto FOSS un minimo rilevante che incentiva i giovani programmatori a contribuire?

Regole, burocrazia, gerarchia… proprio i temi ideali per attirare i giovani

E quanti sono? perché se ad esempio la possibilità è di una su 1000, conviene dedicarsi ad altro.

E’ quello che scritto sopra. Meglio buttarsi su Android ed iOS. Meno rotture e magari anche qualche guadagno in più.

Mai sentito parlare del Google Summer of Code? Ci sono tanti progetti FOSS importanti, tra cui Linux e Xfce. Cito quest’ultimo perché ci contribuisco e conosco la situazione, il GSoC ha portato due giovani a dare una mano importante.

È come se tu considerassi FOSS solo grossi progetti come Linux, GIMP, LO mentre non consideri neanche di striscio i progetti piccoli che magari servono a pochi utenti, ma anche questo è FOSS. Se l’obiettivo è quello di “sfondare” e acquisire una platea di utenti allora ci credo che i giovani non vogliano contribuire, e non è per la burocrazia e per le regole, ma è per l’atteggiamento poco aperto, per procedure criptiche e per l’ansia da prestazione per raggiungere l’obiettivo del successo.

Portando sempre l’esempio di Xfce, da quando è passato da patch via email a un’istanza GitLab è diventato molto più facile contribuire e lo si può notare dai commit e dall’attività rinata. Xfce non ha successo commerciale, a differenza di GNOME che è sponsorizzato da Red Hat e che si può permettere sviluppatori a tempo pieno, Xfce ha però una larga utenza (per esempio è usato nei laboratori della mia università) eppure in pochi contribuiscono. Ognuno cerca di fare quello che può e lo fa per sé, visto che utilizza l’ambiente desktop.

Ripeto, ogni progetto è un discorso a parte, ci sono alcuni come k8s in cui le discussioni avvengono su canali privati, altri in cui escludono i contributi esterni come Telegram Desktop. Ma se uno non sa come muoversi e non conosce l’ambiente è perso in partenza.

1 Like

Cerco di riassumere la discussione che ha sicuramente sfondato una porta aperta, ovvero la possibilità a nuovi di partecipare a un progetto che è un bel problema.

Da mantainer e anche contributor in moltissime cose ne ho viste anche io tante quindi quello che posso dire che oggi i problemi di gatekeeping si possono gestire in vario modo.
Esistono i casi in cui:

  • Il progetto è morto e il proprietario non ti risponde
  • Il progetto o alcune parti di questo non sono molto aperti ai nuovi
  • Il progetto ha priorità diverse quindi il contributo viene ignorato o messo in pausa

Nel mio libro gratuito sul mio sito (non metto il link per evitare spam) affronto un po le cose. Quelle che posso dire che da quando ho cominciato (e avevo solo l’ADSL) tante cose sono cambiate un po ovunque. L’arrivo di GitHub e la trasparenza che soluzioni del genere comportano con interfacce web accessibili a tutti ha obbligato a cambiare molti comportamenti.
A oggi l’uso delle mailing list ad esempio è molto limitato (per pochi), come anche l’invio di patch, si usano altri strumenti, come anche l’arrivo dei codici di condotta che ha portato cambiamenti su questi problemi. A parte se sei il mantainer di Vim che prende le pull request e le ricommitta a nome suo (se non ci credete guardate il repo, per quello e altri motivi nacque neovim).

Sicuramente poi ci sono nuove opportunità come GSOC ma non tutti i progetti sono complessi come libreoffice ma anche cose come portali web e altro sono accessibili. Certo non bisogna pensare che tutti i progetti siano adatti ai nuovi arrivati.

Quindi da un punto di vista concordo che queste complicazioni non aiutano i giovani (le ho viste in azione) ma da un altro punto di vista io so di ragazzi che non sanno nemmeno da dove cominciare (da usare git alla differenza tra una pr e un ticket, o perchè spesso si sviluppa meglio su linux). Oppure pensare che con il C++ fatto alle superiori si possa contribuire a Firefox a 19 anni senza sapere altro.

Direi che noi come associazione dobbiamo metterci nei panni dei ragazzi e capire come possiamo fare per aiutarli a sentirsi a loro agio, anche formarli e capire come valutare un progetto FOSS su cui lavorare. A prescindere da Android a Linux ma proprio in generale.

Per il resto per questo voglio fare la call e sentire che dicono i miei coetanei per capire se ci sono problemi comuni e come affrontarli. Ad esempio se una borsa di studio per libri/corsi è una idea valida o anche fare un hacktoberfest puramente italiano con progetti selezionati.

Non ho messo anche qui il link alle domande/temi per la riunione: Sandstorm

PS: io vedo che lavorare su android è più semplice perchè sono meno macchinosi ma anche la portata di quei progetti è minore e succede con i progetti più piccoli.

1 Like

No mai sentito :wink:
Con tutta la buona volontà considerare Google un sostenitore del software libero mi riesce un tantinello difficile… Ma anche se fosse, l’idea di una gara è l’esatto opposto dell’idea di collaborazione che dovrebbe animare il movimento

Assolutamente no, anzi i piccoli progetti sono gli unici progetti a cui se posso do una mano (eventualmente anche solo economica). Anzi ho addirittura avuto l’ardire di distribuire come FOSS un po’ di cose scritte in prima persona. Ma un discorso è fare questo per hobby, un discorso e farlo seriamente. Se un giovane deve immaginare di fare di professione il programmatore, allora deve farlo in un contesto in cui almeno mette assieme quanto serve per vivere.

Perché altrimenti stiamo dicendo di convogliare i giovani su progetti FOSS solo per la gloria. E come argomentazione non so quanto possa fare presa.

La stragrande maggioranza dei “corsi di Linux” svolti al di fuori delle università sono frequentati da over-50 e diventano rapidamente “corsi di alfabetizzazione informatica”. Che è esattamente ciò di cui i più giovani non vogliono neanche sentir parlare: sai che noia, insegnare ad un anziano come si usa il mouse?

Attività che sortiscono qualche interesse:

  • le serate tematiche su specifici temi, di taglio tecnico. Il problema qui è la promozione, ovvero far sapere che queste serate si svolgono, quando, e dove. Cosa che richiede un grosso sforzo (molto maggiore che non l’organizzazione della serata in sé). Un proposito valido è quello di aggregarsi, dove possibile, agli innumerevoli gruppi tecnici già esistenti almeno nelle città più grandi (qui una pagina che riassume e aggrega quelli attivi a Torino) e delegare a loro la comunicazione, senza la pretesa di dover fare tutto da sé o peggio di non voler partecipare ad altre iniziative (percepite come in concorrenza)
  • più di 10 anni fa (…) avevamo provato con dei LAN Party, con giochi open source e svolti nelle birrerie di Torino. Non sono stati molto efficaci nel coinvolgere persone nuove, ma lo sono stati per coinvolgere maggiormente quelle che già in qualche modo orbitavano intorno al gruppo del Linux Day Torino
1 Like

[madbob] madbob https://forum.linux.it/u/madbob
Agosto 26

skrunk:

Ad es., fare dei corsi su GNU/Linux tipo, base, intermedio, avanzato…

La stragrande maggioranza dei “corsi di Linux” svolti al di fuori
delle università sono frequentati da over-50 e diventano rapidamente
“corsi di alfabetizzazione informatica”. Che è esattamente ciò di cui
i più giovani non vogliono neanche sentir parlare: sai che noia,
insegnare ad un anziano come si usa il mouse?

Certo, concordo, su questo non ho dubbi, peggio ancora di chi è anziano è chi odia la tecnologia, vorrebbe farsi spiegare cosa deve fare ma s’incazza di brutto se non riesce e molla tutto… e di questi ce n’è di tutte le età

Attività che sortiscono qualche interesse:

  • le serate tematiche su specifici temi, di taglio tecnico. Il
    problema qui è la promozione, ovvero far sapere che queste serate
    si svolgono, quando, e dove. Cosa che richiede un grosso sforzo
    (molto maggiore che non l’organizzazione della serata in sé). Un
    proposito valido è quello di aggregarsi, dove possibile, agli
    innumerevoli gruppi tecnici già esistenti almeno nelle città più
    grandi (qui una pagina che riassume e aggrega quelli attivi a
    Torino https://torinotechscene.it/) e delegare a loro la
    comunicazione, senza la pretesa di dover fare tutto da sé o peggio
    di non voler partecipare ad altre iniziative (percepite come in
    concorrenza)

Anche qui niente da obiettare, anch’io avevo asserito che nei grandi centri, vedi Torino, Milano, Genova, Roma, ecc., ci sono grandi Università, in alcune città, vedi Milano o Roma, ci sono diverse Università, percui in questi
luoghi non penso abbiano grossi problemi a metter su dei gruppi per fare attività tipo quelle a cui fa riferimento il tuo link. A proposito, grazie per il link.
Io mi riferivo soprattutto ai LUG dei centri più piccoli, nelle Provincie, dove fai fatica a metter su qualunque cosa… e soprattutto lì che l’interesse dei giovani latita…

  • più di 10 anni fa (…) avevamo provato con dei LAN Party
    https://torinolinuxtaskforce.wordpress.com/tag/open-gamers-tour/,
    con giochi open source e svolti nelle birrerie di Torino. Non sono
    stati molto efficaci nel coinvolgere persone nuove, ma lo sono
    stati per coinvolgere maggiormente quelle che già in qualche modo
    orbitavano intorno al gruppo del Linux Day Torino

Eh, bel problema…

Ma nei piccoli centri mi pare che manchino proprio i giovani… O trovi minorenni, che sono comunque minorenni e anche volendo difficilmente possono muoversi in modo autonomo (niente serate e niente sedi difficili da raggiungere), o sono all’università, e dunque o pendolano o si trasferiscono nei grandi centri.
L’unica chance, forse, è quella di instaurare degli incontri tipo alla domenica pomeriggio nel bar della piazza centrale (o anche vicino alla stazione, ed in un orario scelto consultando la tabella dei treni, affinché siano comodi anche per chi viene dai paeselli limitrofi).

Il punto successivo è: incontri per fare cosa?

[madbob] madbob https://forum.linux.it/u/madbob
Agosto 26

skrunk:

Io mi riferivo soprattutto ai LUG dei centri più piccoli, nelle
Provincie, dove fai fatica a metter su qualunque cosa… e
soprattutto lì che l’interesse dei giovani latita…

Ma nei piccoli centri mi pare che manchino proprio i giovani… O trovi
minorenni, che sono comunque minorenni e anche volendo difficilmente
possono muoversi in modo autonomo (niente serate e niente sedi
difficili da raggiungere), o sono all’università, e dunque o pendolano
o si trasferiscono nei grandi centri.
L’unica chance, forse, è quella di instaurare degli incontri tipo alla
domenica pomeriggio nel bar della piazza centrale (o anche vicino alla
stazione, ed in un orario scelto consultando la tabella dei treni,
affinché siano comodi anche per chi viene dai paeselli limitrofi).

Il punto successivo è: incontri per fare cosa?

Vero… bel problema…

Ma nei piccoli centri mi pare che manchino proprio i giovani… O trovi
minorenni

Ottima osservazione.
Non sono sicuro di come sia stata scelta l’età “under 35” per questa
riunione, ma se vogliamo parlare di giovani che possano davvero dare il
loro contributo, 35 mi sembra… sbagliato.

O meglio, sarebbe bene differenziare due degli obiettivi nelle domande
poste da @mte90

15-25: ottimi per farli crescere sul FOSS, ma pessimi per il ricambio
generazionale dell’associazione;
35+: impossibile da far crescere sul FOSS, ma se già sono senior, ottimi
per il ricambio generazionale.

Certo che crescere col FOSS non è divertente come andare a giocare a
calcetto: è praticamente una seconda scuola, dove inevitabilmente si
fanno anche cose noiose, con l’aggravante che c’è poco spazio per
socializzare coi coetanei.
Il LUG deve essere un centro di socializzazione, per funzionare.

“Purtroppo” il LUG è già pieno di “vecchi maestri” con lunga esperienza
sul software libero, che rendono noiosa l’esperienza del giovane, alla
lunga. Bisognerebbe trovare i giovani sempre in due o più, magari anche
amici, per poi fargli fare il loro percorso di crescita insieme, sotto
la supervisione dei vecchi, ma con tutto lo spazio che gli serve per
svagarsi tra loro.

Assicuro che un giovane di anni 16 e uno di anni 22 sono già due giovani
appartenenti a due ere geologiche diverse, e non ci vengono al LUG per
passare una serata e far scoccare poi quella scintilla di collaborazione
e interesse sul software libero.

L’unica chance, forse, è quella di instaurare degli incontri tipo alla
domenica pomeriggio nel bar della piazza centrale

Non vorrei spegnere l’entusiasmo, ma nel mio polo scolastico di (più o
meno) provincia, “ai miei tempi” eravamo 900 studenti, avevamo una
docente particolarmente fissata col software libero, e solo in 10 (?)
siamo stati disposti a sacrificare i nostri sabati pomeriggio al
LinuxDay, di cui solo 3-4 per confluire infine nel LUG locale.

1 Like

Ne aggiungo un terzo: trovare qualcuno che sappia comunicare
(perché altrimenti si finisce sempre a parlare delle ‘mitiche origini’ e di quanto sia f**a la shell testuale)

Al momento io non faccio limiti sull’età quindi coinvolge sia superiori che università.

Non mi sto focalizzando in questa fase su incontri dal vivo o meno ma cose che possiamo fornire noi come associazione a livello nazionale. Non possiamo scalare altrimenti perché ogni lug o realtà locale è completamente diversa.

Lo scopo è vedere cosa accomuna le varie realtà locali ed età per vedere come possiamo dare una mano generale. Poi con il tempo piano piano dove le cose funzionano meglio andiamo nello specifico ma tutto questo sarà possibile trovando persone disposte a dedicarci del tempo.

Sulla questione promozione era mia idea di estendere il manuale dei lug per aggiungere anche altro. Ho vari appunti da trascrivere ma prima volevo aspettare questa riunione per vedere se c’è altro da aggiungere.

Come giorno per questa riunione dal sondaggio é uscito Giovedí prossimo ore 21.

Per partecipare alla riunione useremo questa stanza: --------------

Il verbale della riunione, da prendere come riferimento ma con le pinze visto il basso numero ma che ha confermato varie cose del sondaggio e chiacchierate informali:

Partecipanti: 8
Membri del LUG Roma Sapienza, Golem e altri per conto proprio

  • Coinvolgere nel contribuire a progetti grandi è difficile causa burocrazia o lentezze varie anche nel solo revisionare, quindi non sono adatti per neofiti o per chi non ha pazienza
    • Servono progetti con una curva di ingresso non troppo bassa e al tempo stesso trovare progetti piccoli è difficili, per via della competizione qualcuno ti batte sempre sul tempo
    • Per partecipare servono persone motivate a partecipare e non solo per dedicare quei 5 minuti di tempo ma servono cose da fare
    • Non tutti conoscono l’hacktoberfest
      • La variante italiana (progetti italiani o di italiani) senza tutoraggio potrebbe essere difficile
        • Si può creare una chat comune dove ci sono persone che danno una mano da Git ai vari progetti/linguaggi stessi
        • Organizzare i progetti per temi può attirare l’attenzione per questa tipologia di evento e si potrebbe usare il forum
  • I LUG funzionano per divertirsi e socializzare dal vivo e non, in tempo di Covid fare dei momenti post incontro liberi/salotto per parlare del più e del meno è recuperare quel contatto che dal vivo erano le cene (ad esempio) - Questo finisce nel manuale per i LUG
  • Per coinvolgere i giovani ma anche nuove persone funzionano gli eventi dedicati alla sensibilizzazione su tematiche attuali come privacy o sicurezza, non tanto gli eventi su software specifici se non che siano dei corsi - Questo finisce nel manuale per i LUG
    • I giovani vengono per fare qualcosa non solo seguire una slide quindi bisogna trovargli da fare o da mettere in pratica durante l’incontro stesso per non perdere il loro interesse anche per farli rivenire
    • I corsi attirano l’attenzione e dopo si parla del LUG
    • Non si vive di soli corsi e non li può fare sempre lo stesso
      • I corsi sono utili in ambito universitario anche per altri corsi come Statistica, Ingegnerie Informatica e Fisica
      • Avvicinano alla programmazione
      • Creare dei progetti durante il corso senza utilità ma fine a se stesso non raccoglie molto interesse
      • Una metodologia per i corsi: si fanno finchè non si è soddisfatti a quel punto si registra e si fa una versione differente o specifica
    • Bisogna rompere il muro tra il docente, membri del lug e partecipanti perché si viene visti in modo troppo scolastico (tipo dando del lei)
  • Strumenti come una mailing list allontanano i giovani, la comunicazione deve essere semplificata
  • La retorica Open Source non funziona più se non messa in secondo piano, bisogna partire da temi attuali per mostrare poi in seconda battuta la proposta del mondo Open Source (del tipo non nel titolo o alla prima slide ma dopo un po)
    • La questione politica non funziona sempre, intesa come “oss gratuito” o “licenze foss”. L’introduzione di queste tematiche deve arrivare in sordina o le persone fuggono
  • La realizzazione di attività con tutor/mentore sono utili per imparare e creare un legame che spesso causa social i giovani non hanno con persone interessate in questo ambiente vicino a loro
    • Realizzare delle attività passo passo, in italiano (da parte di ILS) se aggiornate possono funzionare e aiutare quei lug che non sanno cosa proporre e anche motivare a organizzare incontri a chi non lo ha mai fatto oltre che proporre cose nuove
  • Necessario per ogni lug avere del materiale e storico di libero accesso sia per immagine che come presentazione
  • Trovare le persone da altri LUG o una rubrica sia per incontri dal vivo o no - Niente di nuovo ci stiamo già lavorando
    • Fare più aggregatori (quello degli eventi non è sufficiente) tra materiali e persone - Niente di nuovo ci stiamo già lavorando
  • Ancora oggi il gazebo dal vivo in posti affollati funzionano ma con il Covid è tutto da vedere
  • Difficile che i giovani abbiano un lavoro autonomo che gli permetta di trovare il tempo da dedicare al contribuire come sviluppatori

Idee nate durante l’incontro

  • Realizzare un podcast con ogni puntata data in gestione ad un lug per presentarsi
    • Risulta faticoso da dover gestire ma può andare bene se è al di fuori del target dei membri del lug
  • L’associazione dovrebbe dotarsi di un social media manager anche a pagamento

Aggiungo i miei commenti, alcune cose ci stiamo già lavorando in altre ci servono persone che possono dedicare del tempo alla associazione per linguaggi come PHP per la implementazione.

Sicuramente intanto che non si sviluppa possiamo occuparci di realizzare questo materiale passo passo e aggiornare la guida per i LUG che come lavoro è stato già avviato.

Altro commento pare che trovare tra i giovani persone che conoscano PHP sia difficile.

3 Likes

Un amico di Torino si era inventato il format delle HackNight: una volta al mese (almeno nell’epoca pre-COVID…) si sceglie un progetto open source su cui smanettare e ci si trova una sera per smanettarci insieme. All’atto pratico partecipano prevalentemente persone con modeste competenze di programmazione, oggettivamente non in grado di essere realmente produttive su una base di codice sconosciuta, ma comunque partecipano e tentano di imparare qualcosa mettendo le mani su del codice reale.

Già esiste una sezione “Progetti” su questo stesso forum, ed eviterei di rifare daccapo quello che qualsiasi community di smanettoni già fa (ad esempio, la rubrica settimanale “Mostrami il codice!” sul ben più che popolato e consolidato /r/ItalyInformatica).

1 Like

Si lo ho menzionato e siamo arrivati alla conclusione che funziona per via del tutoraggio dal vivo che da supporto anche i meno pratici.

Il riferimento era per l’organizzazione di un eventuale hacktoberfest italiano. Però potremmo effettivamente strutturarlo con discourse usando i tag o una categoria.

Non ho potuto partecipare all’incontro perché non potevo quel giorno, ho letto il verbale/riassunto e vorrei aggiungere qualche commento.

Personalmente, infatti, ho seguito e tuttora seguo un progetto all’interno di un’università dove ci sono vari studenti, volontari, che fanno cose tra cui realizzare software open source.
Non faccio nomi perché non è rilevante, la cosa rilevante è che in questo “team” mi sono passati davanti decine di studenti, quindi under 35, e per anni ci siamo già scontrati con gli stessi problemi e tentato alcune soluzioni di cui avete parlato.

Tutto il mio discorso è focalizzato sulla produzione di software perché è l’area che conosco meglio, non posso commentare su quanto queste cose siano applicabili ad altri tipi di contributi al mondo open source.

La prima cosa di cui tenere conto è che a pochissimi studenti interessano queste attività, si possono fare stime in vari modi ma siamo sempre intorno all’1% o meno. Questo forse perché gli studenti studiano già a tempo pieno e non tutti hanno voglia di caricarsi di altro lavoro e nemmeno retribuito, di fatto, o per semplice disinteresse verso il tema.

La seconda cosa è che quell’1% sono comunque studenti, che stanno all’università per imparare, quindi inutile illudersi che abbiano già competenze incredibili. Anche perché, tra i programmatori duri e puri, al di là del nozionismo con cui vengono ingozzati dall’università, l’esperienza fa tantissimo e l’esperienza si acquisisce solo in anni e anni e anni passati a pigiare tasti, provare, sbagliare e riprovare.

La terza cosa è che la motivazione degli studenti, quella che spinge la gente a imparare l’impossibile in 5 minuti e scrivere migliaia e migliaia di righe di codice di getto, non è mai stata “Che bello contribuire all’open source”, anche perché il software è principalmente di backoffice e ad uso interno quindi non ha neanche un impatto diretto sul genere umano, né tantomeno il “Così imparo qualcosa e faccio la gavetta” anche se un pochino forse fa, e neppure “Questo software risolve problemi reali a persone reali, che quindi sto aiutando” anche se questo può contribuire.
La massima motivazione viene dal fatto che quel software sia utile per sé e dal fatto di avere controllo e libertà per sperimentare e imparare.

E chi arriva in quella situazione, tale da avere quelle due forti motivazioni, è forse un 1% dell’1% poiché devono verificarsi una serie di congiunture: dev’essere una persona che si trova bene nel team e va d’accordo con gli altri studenti (il team diventa la cerchia sociale di alcuni, che invoglia a spendere più tempo lì), che abbia capito le dinamiche interne per evitare di fare una cosa inutile (che motivazione può mai dare creare un software bellissimo e poi vedere che nessuno vuole usarlo a parte sé stessi, o ancora peggio venir criticati?), deve trovare un problema che affligge sé e anche in qualche misura gli altri, deve avere in mente una possibile soluzione (c’è anche un aspetto di autonomia di chi fa le cose, in tutto questo) e deve avere il coraggio di proporla.
Praticamente qualunque cosa venga proposta in tal senso viene approvata con entusiasmo, che di solito è l’ultimo impulso, dopodiché è fatta: quella persona realizzerà il progetto che tanto desideriamo, studiando l’impossibile per farlo, sfornando codice di qualità in tempi record, e così via.

Questa serie di condizioni non è strutturabile, non è meccanizzabile, non è riproducibile a comando, non esistono ricette magiche, non ci sono panacee, non ci sono soluzioni tecnologiche a problemi sociologici: bisogna solo costruire e favorire un certo tipo di cultura, faticando, impegnandosi costantemente, con attenzione e cura, e sperare che nel mucchio di studenti ci sia qualcuno che si ritrovi in quella fortunata congiuntura.

Sì, è anche possibile convincere gli studenti a contribuire dicendo “Guarda che bello l’open source, guarda che bello fare questo software che abbiamo già deciso come fare e che risolve problemi reali”, ma non è la stessa cosa e i progetti che gestiamo in questo modo, per quanto vadano avanti, vanno molto più a rilento e le issue da risolvere aumentano soltanto, perché ci vengono sempre più idee per migliorie incredibile rispetto a quante riusciamo a realizzare in un dato tempo.

E anche in quel caso, l’intera cultura del team dà un aiuto non indifferente. La direzione che ho cercato di dare (perché la cultura non può essere imposta né non può essere pianificata a tavolino, è una proprietà emergente) è di essere sempre disponibili e comunicare per non abbandonare mai la gente a sé stessa in caso di dubbi o difficoltà, tenere conto di ogni dubbio o critica per evitare di realizzare l’inutile o cose che non funzionano, ascoltare chiunque abbia una proposta, non criticare mai (dopotutto è gente che lavora gratis…), prendere le decisioni su base tecnica ma mediarle sempre sulla base di chi ha voglia di fare cosa. Probabilmente queste sono ovvietà, ma non è banale trovare una cultura del genere e non è banale che chi è già “dentro” abbia la forza e la voglia di mantenerla viva.

È infatti molto più facile pensare “nessuno ha voglia di lavorare, sono tutti degli imbecilli tranne me” e decidere tutto di testa propria, fare tutto senza guardare in faccia nessuno o smettere completamente di fare qualunque cosa, o formare cricche che escludono gli altri finché tutti non si stancano e se ne vanno.
Ho sempre cercato di stroncare questi comportamenti sul nascere, spingendo le persone a collaborare o almeno condividere le informazioni e demolendo le cricche come potevo. Questo, di nuovo, richiede costante sforzo, costante vigilanza e anche sufficiente rispetto da parte degli altri per essere ascoltato: non posso demolire una cricca se sono l’ultimo degli ultimi e la cricca sta in cima alla “gerarchia”, non sono i nuovi a poter cambiare le cose, non da soli almeno.

Questo è ovviamente diverso dalla gente che ha voglia di fare e quindi realizza un progetto da sola ma comunicando con gli altri e ascoltando e proponendo e capendo e imparando, le cricche sono diverse dai “jelled team” (un gruppo di persone affiatato) che lavorano per un obiettivo comune e utile a tutti.

Per fare un parallelismo azzardato, in ILS i LUG e le sezioni locali sono da un lato considerabili dei “jelled team” perché la gente che ne fa parte spesso si trova bene e diventano una cerchia sociale che poi organizza anche attività, ma dal punto di vista di ILS sono anche spesso delle cricche, dove può essere difficile entrare per gli esterni e che talvolta (non sempre, lo so) preferiscono occuparsi delle “proprie cose” e contribuire in maniera esigua alle attività di ILS stessa.
Ovviamente non dico di demolire i LUG perché l’aspetto di “coesione sociale” è molto buono e appunto è essenziale secondo me, però vale la pena riflettere su questa cosa e pensare a come far pendere l’ago della bilancia verso “jelled team” piuttosto che cricca. A parte fare i ritrovi in birerria invece che in luoghi sperduti come ha proposto in vari momenti Bob, perché il luogo è solo parte di quello che è più un problema culturale e che richiede cambiamenti forse più ampi di quello che possa fare un singolo LUG.

Ho visto che avete parlato dei corsi: noi ci abbiamo provato e abbiamo fallito miseramente.
Dato che avevamo davanti degli studenti che quindi non sanno già tutto, abbiamo provato a organizzare dei corsi interni al team, non di programmazione ma di ambito informatico, tenuti da altri studenti un po’ più esperti in un determinato campo.
Chi ha seguito i corsi ne era entusiasta e ne voleva ancora con sete insaziabile, ma quello che ci aspettavamo è che la gente, carica di conoscenze e competenze che prima sosteneva di non avere, poi contribuisse alle attività del team. Questo quasi mai è successo. Percepivano i corsi come dei corsi universitari: da seguire attentamente ma fini a sé stessi, da non applicare mai alla realtà neanche per sbaglio. Sono stati solo un colossale spreco di tempo rispetto ai nostri fini, per quanto siano stati apprezzati.

Quanto ai tutoraggi/mentoring, non so esattamente in che ottica ne abbiate parlato, ma da un lato sì, alcune informazioni sono utili ed è meglio che le fornisca un essere umano che parla ad altri esseri umani e non un testo scritto buttato da qualche parte, ma non credo che siano risolutivi.
Intendo dire che, sì, reputo utile è spiegare come funzionano i progetti già avviati, quali sono i requisiti, com’è organizzato il codice, etc… ma quelle mi sembrano informazioni essenziali che in sostanza i maintainer di qualunque progetto dovrebbero fornire ai nuovi contributor.
Può anche essere utile dare qualche indicazione sulle questioni più annose dove la gente spesso inciampa o rischia di perdere tempo. Ad esempio, far vedere come configurare alcune cose utili su Pycharm di persona è più immediato che dire “vai a leggerti la documentazione” che è immensa, oppure se ho esperienza con una certa libreria e so che la documentazione non è molto chiara posso spiegare a un’altra persona come fare alcune cose.

Al di là del fatto che si potrebbe pensare di contribuire alla documentazione della libreria per migliorarla, che si ricollega a un altro punto che volevo sollevare: la cattedrale e il bazaar.

Il software che realizziamo in team è gestito come un bazaar, sia a livello del singolo progetto, sia a livello dell’intero sistema di software che interagiscono: se c’è una buona idea su feature da aggiungere si aggiunge, se qualcuno esterno che usa il nostro software fa una pull request la accettiamo (è successo una manciata di volte), se qualcosa come viene proposto non è fattibile si cerca una soluzione alternativa che abbia senso per tutti, se del codice che qualcuno vuole aggiungere non va bene per qualche motivo (bug, problemi di sicurezza) con educazione si propongono modifiche o chi accetta la pull request fa direttamente le modifiche, se qualcuno vuole realizzare un nuovo progetto gli diciamo “vai!” con entusiasmo se è effettivamente utile, il tutto comunicando come esseri umani.

Invece su progetti open source più grossi dei nostri mi rendo conto che questo sistema sia meno sostenibile, perché se ti arrivano 2 issue in cui non si capisce il problema di solito la voglia di chiedere educatamente delucidazioni la trovi, se te ne arrivano 200 o 2000 a un certo punto non hai più tempo e forza e le chiudi e basta, anche se può sembrare maleducato.
Da qui può avere senso un tutoraggio specifico su questi progetti, tenuto da qualcuno che li conosca decentemente, per evitare che i nuovi contributor si vedano tutte le pull request scartate senza commenti. Non so se era stato proposto questo. In ogni caso dev’essere qualcosa di tenuto da un maintainer o contributor regolare, non è banale trovare qualcuno che lo sia e che abbia tempo e voglia di aiutare i nuovi, né trovare nuovi che abbiano voglia di contribuire proprio a quel progetto, o che abbiano le competenze necessarie. Sui progetti che abbiamo in team possiamo chiudere un occhio su varie cose, essendo principalmente di backoffice l’importante è che funzionino bene per noi, ma per progetti ad uso più pubblico è più difficile trascurare incompatibilità strane con gli ambienti di produzione, bug reconditi, edge case assurdi, potenziali questioni di sicurezza, etc…

Un altro problema è anche che, come ho evidenziato prima, la voglia di contribuire e farsi un mazzo così per farlo, studiando e imparando e facendo cose, viene dalla necessità di risolvere i propri problemi. Quindi chi si trova in quella situazione vuole contribuire proprio a un certo progetto, dove magari vuole aggiungere una feature che ritiene utile o risolvere un bug fastidioso.
Io probabilmente ho avuto sfortuna, ma tutte le volte che ho provato a contribuire a progetti altrui in questo senso mi sono scontrato con un muro: “no questa feature non la voglio perché io non la userei”, “il mio progetto punta al minimalismo, questa funzionalità è troppo complicata”, “no, aggiungere la compatibilità con questa cosa non va bene perché non voglio aggiungere altri test e non sarebbe coperta, anche se la copertura dei test è il 20% del codice al momento”.
Non è il “gatekeeping” del “formatta meglio il codice, riorganizza l’architettura, fai passare i test, risolvi i warning del linter e poi ti accettiamo le modifiche” che potrebbe avere un grande progetto, è una gestione dei progetti a cattedrale, spesso nel deserto, dove il maintainer (dittatore benevolo, azienda, gruppo di amiconi, etc…) rifiuta una modifica con motivazioni più o meno sensate ma senza possibilità di appello.

Questo è un altro problema culturale e che ovviamente non possiamo essere noi a risolvere: la gente dovrebbe solo farsi furba e capire che se arriva qualcuno col codice in mano e ti implora di accettarlo è perché risolve problemi reali e dovresti solo essere contento di poter aiutare qualcuno con uno sforzo minimo, così come sicuramente hai usato gratis migliaia di programmi e librerie realizzati da altri e che ti hanno aiutato. Oppure leggere “La cattedrale e il bazaar”, è un testo veramente breve, non ci cono scuse per non conoscerlo.

Quindi? Quindi se io voglio contribuire proprio a quel progetto e non genericamente “contribuire all’open source” che è un obiettivo che nessuno ha come primario, cosa me ne faccio di un hackathon dove ci sono tanti bei progetti, che non conosco, che non uso, che magari non mi interessano, per risolvere issue decise da altri in maniere spesso decise da altri, per fare pull request che magari non verranno mai accettate?
Oppue, a cosa può servirmi un tutoraggio “generico” (di nuovo, non so bene se se ne sia parlato) su progetti che non mi interessano, o sul “contribuire” generico che magari dà qualche informazione generale ma non aiuta a leggere nella testa dei maintainer e capire cosa vogliono?
L’hackathon secondo me può essere utile per “imparare a programmare”, certo, ma non per fare la “gavetta”, non per essere motivati, non per fare qualcosa di utile per sé, è alla stregua di dire “contribuisci all’open source perché è bello”, credo che pochissime persone possano trovarlo stimolante da quel punto di vista. E le infinite liste di TODO di ILS, che continuano a crescere, temo che crescano per la stessa ragione.
L’unica speranza che vedo è una congiunzione astrale difficilissima per cui qualcuno è infastidito da un certo problema e per miracolo la issue è su quel medesimo problema e la issue è un po’ l’equivalente dell’entusiasta “vai!” che dà l’impulso, piutosto che dividere per temi o fare TODO list colossali. Ma è inutile illudersi che un 1% di un 1% di una ridotta % di persone che sanno programmare e hanno un minimo di tempo e voglia si trovi in quella situazione guardando la LugMap o LinuxSi o altro: è possibile, ma le possibilità sono veramente esigue e l’unico modo per aumentarle è a monte e consiste in un costante lavoro per attirare persone e realizzare una cultura che incoraggi questo genere di contributi. Oltre a cercare di diffondere il più possibile i propri progetti e fare in modo che siano più utilizzati, che è impossibile per i vari repository con siti, lo so, nessuno si metterà mai a self-hostare LinuxSi perché non avrebbe senso.
Non è per nulla semplice e richiede un sacco di tempo e fatica, non ho soluzioni semplici da proporre purtroppo.

Ho invece una proposta più azzardata, che mi è venuta in mente mentre scrivevo quindi non è molto ragionata quindi prendetela con le pinze.
Insomma, si potrebbe considerare l’aspetto economico: sia dal punto di vista che i soldi sono una motivazione a sé stante, sia dal punto di vista che un lavoro pagato purtroppo viene considerato in maniera leggermente più seria del “fare cose a caso gratis” anche noto come volontariato.

Ad esempio, ho visto vari studenti preferire tirocini e stage pagati una miseria rispetto al “lavoro” in team, dove invece di essere seguiti e sostenuti come avremmo fatto noi venivano messi come polli in batteria davanti a un computer e spinti a produrre codice-spazzatura senza alcuna indicazione, del tipo che il capo dice “realizzami questa cosa con questa libreria, se hai dubbi leggi la documentazione, tra 3 giorni torno e valuto il tuo lavoro, ciao” e dopo 3 giorni tornava per dire che erano cambiati i requisiti e bisognava rifare tutto da capo. Questo in qualche modo veniva visto dagli studenti come un’esperienza edificante o almeno che valesse la pena fare, e veniva vista così a posteriori.
Personalmente non me ne capacito, però se lo standard è questo, se in ILS vogliamo giovani che contribuiscano scrivendo codice con le loro manine, si potrebbero proporre agli studenti dei tirocini pagati. Loro si prendono dei CFU e 600 € in cambio di 300 ore di lavoro, noi ci prendiamo il codice, magari gli studenti si appassionano e restano anche dopo, in quel giro la gente inizia a vedere ILS come “una cosa seria” con gente che lavora e non come una banda di scappati di casa dove dei nerdacci barbuti che non si lavano fanno cose inutili gratis, si demolisce il meme che “il software libero non paga perché è fatto interamente da volontari volenterosi” (che già non è vero perché è pieno di aziende con dipendenti regolarmente saliarati che fanno software open source, ma è una cosa veramente poco nota, per quanto a noi sembri assurdo).
Tuttavia non ho idea se ciò sia fattibile dal punto di vista legale.

Qualcosa del genere sarebbe, secondo me, molto più efficace sui giovani rispetto a promettere premi (dove 10 persone lavorano, 1 vince e si prende i soldi e gli altri hanno solo perso tempo) o pagare cifre misere a gente che lavora.
Infatti lo stadio successivo degli studenti universitari è il lavoro, a tempo pieno, presso un’azienda, che rende molto più faticoso contribuire volontariamente ad altro (che voglia hai dopo 8 ore o più passate a pigiare tasti su una tastiera, di accendere il computer e fare di nuovo la stessa cosa?) e non rende minimamente attraenti “100 € se fai questa cosa”, per quanto gli stipendi medi dei neolaureati siano una miseria quei 100 € possono creare problemi burocratici (chi lavora in una grande azienda spesso deve dichiarare e chiedere autorizzazioni per fare qualsiasi altra forma di lavoro retribuito) o fiscali (vale davvero la pena complicarsi la vita per dichiarare correttamente quei 100 € o rischiare multe? Per una persona che ha un unico reddito da lavoro dipendente, cioè la schiacciante maggioranza della gente comune, è solo una rottura di scatole ulteriore).
Invece non ho mai visto alcuno studente esprimere anche solo lontanamente il desiderio di lavorare in proprio, cosa che permetterebbe di accettare più facilmente eventuali miseri pagamenti a progetto e affini, per questo la struttura del tirocinio/stage potrebbe avere più senso.

Ah, un’ultima cosa: è vero, è difficile trovare programmatori PHP. Ma i linguaggi di programmazione dello stesso tipo sono tutti uguali: chi sa già programmare in altri linguaggi OOP, ad esempio, non ci mette nulla a imparare PHP se vuole. Non si parte da 0 in quel caso, è più un partire da 90 per arrivare a 100.
Conoscere i concetti senza tempo permette di saltare da un linguaggio all’altro senza difficoltà: la logica booleana è la stessa, le strutture di controllo sono sempre le stesse, le classi sono sempre le stesse, le strutture dati sono sempre le stesse, gli algoritmi sono sempre gli stessi, il funzionamento del debugger è sempre lo stesso… Sì, cambia la sintassi, cambiano le funzioni di libreria, ma non è una tragedia, una persona che sappia programmare quelle cose le impara in fretta o le cerca nella documentazione.
Se cercando “programmatore con lunga e larga esperienza pluriennale in PHP” non si trova nessuno, si può provare umilmente a cercare “programmatore che conosca decentemente un paio di linguaggi OOP e disposto a programmare in PHP”.
Il problema forse è che PHP non attira, per via delle gente che vive per meme e ripete come scimmie “PHP è incoerente, è insicuro, è brutto, è cattivo, è un martello con due levachiodi”, ma non so bene come risolvere questo, a parte ripetere ossessivamente dei concetti opposti ma più verosimili di queste critiche ormai stantie da un decennio…

2 Likes

Rientra nell’idea di avere dei mentor o dei referenti sia in ILS che per le attività suggerita in riunione.

Si ci sono entrambi i lati della medaglia, spero che la proposta di fare altre attività possa aiutare a modificare la situazione nel tempo.

Più o meno quello che ha detto il lug universitario che ha partecipato. Bisogna creare un ambiente informale per fare gruppo, in modo tale da trovare poi qualcuno che sta dall’altra parte della barricata.

Inteso come dici tu ma anche ho un dubbio chiedo a lui, insomma un rapporto umano qualunque però hai qualcuno a cui puoi chiedere cose non per forza del progetto. Aiuta sia a fare gruppo che creare quel rapporto umano informale da lug da birreria di una volta per dire.

Si anche questo naturalmente, l’idea è di togliere la barriera “sei da solo con la documentazione” che allontana queste persone.

Potrebbe essere utile sia per farsi conoscere come progetto/ILS, ma anche per dare uno stimolo. Naturalmente se è quello gestito da noi parteciperanno progetti che aderiscono non che li scegliamo noi. Quindi se si fa una pull request di conseguenza non verrà ignorata ma valutata. Altrimenti non ha senso come dici tu :slight_smile:

Per creare relazioni ma anche per imparare parlando con qualcuno. I giovani hanno bisogno di relazionarsi per cominciare e fare esperienza, il classico calcio che da il via ma non se lo daranno mai da soli.

È uno stimolo, poi partecipano 100, te ne rimangono 10 che partecipano anche ad altro per quello che hanno imparato.

Ora si evolverà Progetti online da fare insieme per coinvolgere nuove persone (#11) · Issues · Italian Linux Society / Brainstorm · GitLab grazie anche alla riunione.

Rientra nell’idea di borsa di studio o in (fresca fresca) Offerta di lavoro per sviluppatori PHP7 (avanzamento registri elettronici liberi)LAMPSchool
Abbiamo visto che i bug bounty non funzionano e la gente non li risolve e ils ha investito in vari ticket di vari progetti.

Saltato fuori durante la riunione, diciamo che manca proprio l’idea anche perchè (secondo me) il mondo è cambiato. Prima ad esempio era normale grazie a PHP trovare lavoro o farlo in proprio e fare una web agency, oggi invece studiando cose completamente diverse e meno cose web questo interesse è minore quindi in proprio per fare machine learning non ha molto senso per fare un esempio. Questo porta anche il problema che non troviamo contributor in PHP ma forse lavorare in python potrebbe cambiare la situazione.

Questo lo dice uno che ha esperienza ma se parliamo di questi giovani che non sono motivati già di loro, è ancora più difficile buttarli in qualcosa di cui non sanno niente. Cioè mettiamo altri scalini di fronte a loro quindi c’è ancora meno interesse.

I primi effetti di questa riunione :slight_smile:

TODO - Linux.it c’è attività che è un link (da rendere più evidente direi) che rimanda a Attività - Linux.it con attività per contribuire a 4 progetti ma è in espansione :blush:

1 Like