tra i punti.
Il 03/08/2015 17:18, Sandro Santilli ha scritto:
E' invece un problema per uno stakeholder pubblico, il quale ha
difficolta' a operare con queste modalita'.
Non che non si possa in assoluto, ma sicapisce bene che se si da' un
incarico a un developer di studiare un problema, non si puo' poi
dargli un nuovo incarico per l'implementazione del lavoro stesso.
Scusa ma io questo non lo capisco. Non "si capisce bene", almeno io
non lo capisco bene. Perche' un ente pubblico non puo' dare un
incarico per la sola analisi e progettazione ? Non e' proprio la
pianificazione una delle fasi piu' importanti in qualunque progetto ?
Certo, ma il problema e' la sequenzializzazione in due incarichi
distinti e differenti, alla medesima persona.
Il primo per progettare e il secondo per realizzare.
Potrebbe essere inteso come "frazionamento".
Ma qui nasce poi il secondo problema:
Ovvero, la community stessa, la quale e' essa stessa una entita che
oserei definire "liquida" e variabile.
Il risultato di questa liquidita' e' che cambia spesso opinione,
dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e
sottovaluta la visione strategica di un prodotto.
Questa mi sembra una generalizzazione, e bisognerebbe portare
esempi specifici e concreti per capire meglio di cosa parli.
Ma che esempi.
Uno non lo fa' mica di mestiere di partecipare tutti i giorni alla
community.
Te stesso leggi solo ogni tanto.
Quindi il tuo pensiero e' presente a sprazzi.
Idem per chiunque altro. Per cui le opinioni variano in relazione a chi
legge e risponde.
Non mi pare che sulla community di qgis organizzino votazioni dando
tempi settimanali per esprimere pareri. Chi risponde risponde, poi le
decisioni sono prese sulla base di cio' che e' stato detto.
La modalita' aperta dello sviluppo rende davvero difficile
"dimenticare" qualcosa di quel che e' stato fatto.
NOn sto dicendoche le cose vanno perse, ma una volta che un rilascio di
qgis ha rotto qualcosa , te lo tieni in tal modo.
Non e' che chi lo ha rotto , si prende la briga di rimettere le cose a
posto, e se anche lo facesse, prima del successivo rilscio non sarebbe
nuovamente disponibile.
Te continui a vederla con l'ottica di uno sviluppatore che sicompila da
se' il prodotto. E quindi no ti preoccupa questo genere di cose perche'
ci metti 30 minuti a ricompilartelo su linux
Ma se pensi di essere un tecnico di un ufficio che deve fare un lavoro ,
che il tuo qgis non funziona piu' come ti aspettavi , e non puoi
riprendere la vecchia versione perche' e' mancante di alcune
funzionalit'a che ti servono pure esse, mica puoi aspettare 3 mesi per
riavere una vesione funzionante per benino.
Per quanto riguarda la visione strategica, entra in gioco la capacita'
del proponente di convincere i maintainer della validita' di un approccio.
Mi viene in mente il caso di Pierre Racine con i PostGIS Raster.
Non solo Pierre non era nel PSC, ma non era neanche uno sviluppatore.
Da utilizzatore ha lavorato su un piano strategico cosi' dettagliato
e convincente da far digerire perfino a Paul Ramsey l'idea di
supportare i raster nel db (lui ne era notoriamente contrario).
Va da se che se Pierre non si fosse anche occupato di trovare i fondi
per finanziarne lo sviluppo difficilmente la cosa sarebbe andata
avanti (nel senso che non basta convincere a parole, ma bisogna pure
offrire la nuova funzionalita' ...)
L'approccio bazar , alla lunga finisce per far nascere anche lui i
forks , perche' costringendo gli stakeholders a difendrsi dalla
inevitabilita'del rischio del cambio "bottone <-> zip" li spinge a
ricercare la sicurezza nella tranquilla oasi di un fork
"istituzionale".
A me sembra un problema generale legato ai cambiamenti.
Non e' specifico del software libero, ma ben presente anche con quello
proprietario. Nel software libero semmai e' attenuato proprio perche'
avendo il diritto legale di distribuire il software non si pone mai il
problema di non trovare piu' disponibile una versione vecchia di un
programma (avendo l'accortezza di tenerne copia).
Se poi parliamo di "funzionalita' scomparse" e' un altro paio di
maniche, e rinnovo il mio invito a segnalare tali casi come bug.
Si certo, ma vale il discroso sopra detto.
Se rilevi questo problema su una versione rilasciata , nel caso peggiore
hai 3 mesi per riavere le cose a posto.
Una era geologica , in certe situazioni.
Come avere una visione strategica comune.
Partecipando alle liste di discussione.
Due problemi:
il prim piu' terreno e' il seguente:
Te immagina di essere il boss diuna ditta che lavora nei GIS, e hai i
tuoi dipendenti , da cui dipende il tuo business. Devi fre una consegna
importantissima, entro le porissime 4 settimane.
Te vai a dire ai tuoi dipendneti, di destinare parte del loor tempo per
partecipare alle discussioni nelle Mailing List perche' devono
presidiare il software da cui dipende il tuo business ?
I dipendenti, o lavorano e producono o presidiano le ML.
Entrambe le cose in orario di ufficio non si possono fare.
Il secondo piu' virtuale e' che se anche presidi una ML, il tuo parere
conta 1 come quelo degli altri.
Se decino di fare una certa cosa perche' ce qualcuno che paga, e magari
piace ad altri , viene fatto.
A che serve presidiare ?
A prepararti mentalmente al casino che ti succedera' appena aggiornerai
qgis ?
Il problema e' che molti di queli che lavorano su QGIS, non credono loro
per primi in quelloche e' qgis.
Credono che sia niente di piu' che un programma di paint piu' complicato.
E pensano che rompere la compatibilit'a con il passato sia una cosa che
si puo' fre perche' tanto chi lo usa si mette li' con pazienza e se
vuole rifa' il progetto qgis daccapo, oppure non lo rifa' e lo abbandona
passando a farne altri.
E' una visione molto miope e dimostra una scarsa percezione del lavoro
che si sviluppa su un software gis.
Te pensa che noi abbiamo dei progetti con parecchie decine di strati
vettoriali con vestizioni moto complicate fatte da gente che ci ha
lavorato per mesi per farle , questa gente , erano studenti
universitari, che hanno realizzato queste vestizioni enl'ambito di un
progetot molto importante e i risultati di queste stampe sono divenuti
prodotti importanti.
In futuro qualcuno potrebbe aver bisogno di riprendere quei progetti e
riaprirli e poter rivedere quei risultati a video.
Ma se quei progetti sono stati fatti su qgis 2.2 e se quando li vado a
aprire con qgis 2.8 vedo risultati differenti, trasparenze che non
tornano piu' simbolismi che non compaiono , retinature con spaziature
difformi.
Etichette che tornano in posti differenti o non compaiono affatto,
Per noi e' una cosa che non va bene.
Te mi dici di restare alla versione 2.2 per avere certezza di poter
sempre riaprire quel progetto.
Puo' darsi che hai ragione, ma allora , capisci anche che quando mi si
viene a chiedere se si puo' evolvere qgis per avere una qualche
funzionalit'a differente, non posso che rispondere
NO, non e' possibile evolverlo ( al pari di un software commerciale).
Questo perche' l'evoluzione andrebbe in un nuovo qgis che non
funzionerebbe piu' bene con altri progetti che abbiamo.
Mica si puo' pretendere che un utente abbia sul suo pc 10 versioni
differenti di qgis una per ogni specifico progetto che deve riaprire.
A.
> --strk; () Free GIS & Flash consultant/developer /\
http://strk.keybit.net/services.html
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
