Ciao a tutti.
Dalle poche (pur generose) risposte che ho avuto qualche tempo fa alla notizia dell'upgrade del wiki, mi è sembrato di capire che non sia uno strumento particolarmente sentito dalla maggioranza delle persone in lista. Questo è in parte confermato anche dal fatto che il wiki viene usato di rado (una volta al mese, o qualcosa del genere) per inserire contenuti. Nell'ultima settimana abbiamo avuto nuovamente inserimento di spam. Non è molto, ci sono voluti 5 minuti per cancellare le pagine e bloccare gli utenti, ma è comunque un impegno costante di cui evidentemente sono l'unico a farsi carico. Quando visito un wiki e vedo che le ultime modifiche sono tutte costituite da spam mi faccio l'idea che quel wiki sia abbandonato. Secondo me è quello che sta succedendo al wiki di GFOSS. Quindi vi domando: - dobbiamo limitare la creazione di nuovi account? - dobbiamo ripensare a cosa ci serve, e se il wiki ci serve davvero? Ciao steko -- Stefano Costa http://www.iosa.it/ Open Archaeology _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
Il 23/02/2012 11:30, Stefano Costa ha scritto:
> - dobbiamo ripensare a cosa ci serve, e se il wiki ci serve davvero? IMHO e' insostituibile, anche se concordo con i problemi che esponi. Abbiamo statistiche di quanto venga consultato? Grazie. -- Paolo Cavallini See: http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
In reply to this post by Stefano Costa
2012/2/23 Stefano Costa <[hidden email]>:
> Ciao a tutti. > > Dalle poche (pur generose) risposte che ho avuto qualche tempo fa alla notizia > dell'upgrade del wiki, mi è sembrato di capire che non sia uno strumento > particolarmente sentito dalla maggioranza delle persone in lista. Magari non ancora... Dal mio punto di visto (ho iniziato mantenere Wiki tanti anni fa) deve esserci contenuto a sufficienza per stimulare l'interesse. La cosa deve evolvere... Un esempio: http://grass.osgeo.org/wiki/Special:Statistics --> Views total: 4.4 milioni --> Page edits since GRASS-Wiki was set up: 14.989 Mi sembrano numeri impressionanti per i pochi anni che il GRASS Wiki è sul dominio osgeo.org. > Questo è in parte confermato anche dal fatto che il wiki viene usato di rado > (una volta al mese, o qualcosa del genere) per inserire contenuti. Magari va rivista un po' l'organizazzione del contenuti per renderlo più facile (p.e., l'uso di "categorie" è fondamentale) ecc. > Nell'ultima settimana abbiamo avuto nuovamente inserimento di spam. Non è molto, > ci sono voluti 5 minuti per cancellare le pagine e bloccare gli utenti, ma è > comunque un impegno costante di cui evidentemente sono l'unico a farsi carico. Quale misure anti-spam ci sono? Esempi - wiki.osgeo.org: manca da anni il collegamento con LDAP di OSGeo, non ci sono tante misure anti-spam, allora spam a manetta (ho preso la badge di spam fighter :) - grass.osgeo.org: captcha + math-captcha: spam quasi mai > Quando visito un wiki e vedo che le ultime modifiche sono tutte costituite da > spam mi faccio l'idea che quel wiki sia abbandonato. L'impressione sì ma non + neccessariamente così. Perché? Perché (troppe) poche persone hanno il diritto di cancellare pagine e bloccare persone. > Secondo me è quello che sta succedendo al wiki di GFOSS. > > Quindi vi domando: > - dobbiamo limitare la creazione di nuovi account? Sì, con captcha. E il contenuto con math-captcha. > - dobbiamo ripensare a cosa ci serve, e se il wiki ci serve davvero? Per fortuna no. "Basta" rendere il Wiki (ancora) più interessante. My 0.02 eurocents, Markus _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
In reply to this post by Stefano Costa
Il 23 febbraio 2012 11:30, Stefano Costa <[hidden email]> ha scritto:
> Ciao a tutti. > ciao ste > > Quindi vi domando: > - dobbiamo limitare la creazione di nuovi account? non sono un esperto wiki perciò non so dirti... > - dobbiamo ripensare a cosa ci serve, e se il wiki ci serve davvero? secondo me si, ma dovremmo usarlo di più soprattutto dopo una bella ripulita. Non ci sono soci disponibili a fare ciò? Non è possibile che siano sempre gli stessi a doversi sobbarcare di fare tutto, sviluppo traduzione documentazione ecc ecc... > > Ciao > steko > -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
On Sat, Feb 25, 2012 at 8:59 AM, Luca Delucchi <[hidden email]> wrote:
Heh :-) Una realtà comune per i progetti open source è che meno di 10 persone (spesso 4-5) fanno l'80% del lavoro, altri 10-20
fanno il restante 20%, altri 50 parlano di fare qualcosa (ma in realtà non fanno nulla o quasi), e i restanti 1000 guardano e usufruiscono senza fare o dire nulla :-p (ovviamente i numeri sono inventati, ma danno un'idea delle proporzioni)
Ciao Andrea PS: per lavoro intendo anche documentazione o supporto su ml, non solo codice -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
In reply to this post by Stefano Costa
>Heh :-) >Una realtà comune per i progetti open source è che >meno di 10 persone (spesso 4-5) fanno l'80% del lavoro, altri 10-20 >fanno il restante 20%, altri 50 parlano di fare qualcosa (ma in realtà non >fanno nulla o quasi), e >i restanti 1000 guardano e usufruiscono senza fare o dire nulla :-p >(ovviamente i numeri sono inventati, ma danno un'idea delle proporzioni) > >Ciao >Andrea > >PS: per lavoro intendo anche documentazione o supporto su ml, non solo >codice Io non sarei cosi' pessimista. La tua statistica trascura un punto fondamentale. Lo sviluppo del codice non pesa nei termini che dici te. Il costo dello sviluppo del codice , levando di mezzo lo sviluppo della documentazione e' per il 20% effettiva sviluppo di codice sorgente . Per il restante 80% e' sbacatura di errori e reporting su casi di uso. In questa fase gli utenti che "sfruttano il lavoro di altri", in realta sono utenti che impiegano i prodotti e cosi' facendo segnalano i difetti riscontrati e le looro segnalazioni aiutano a migliorare il prodotto. Io questo lo considero il vero valore aggiunto di un progetto OpenSource GFoss. Ovvero hai una platea di testers smisurata, tanta gente che usa il tuo codice e ti segnala i difetti su un bel sistema a tickets. Chiaro che per la ditta che sviluppa questa non e' una bella prospettiva, ma per il cliente si' :)) Qui entra anche un altro aspetto che differenzia lo sviluppo GFoss rispetto ad altri modelli. Spesso, infatti chi sviluppa tende a voler rilasciare il codice solo al momento finale accompagnandolo da emissione di fattura. Magari in fasi intermedia spedisce il sorgente al cliente per i controlli intermedi, ma solo a lui. Invece il modello di sviluppo dovrebbe prevedere che fin da subito il codice progressivamente sia messo a disposizione della comunita per chi lo vuole testare. Questo permette di affrontare e far emergere fin da subito i problemi. Invece l'approccio tradizionale, in cui il cliente "poverino" solo soletto deve sbacarsi il codice , che spesso non ha neanche il tempo di analizzare per bene, ha poche speranze di evidenziare i bachi piu' reconditi. Questo e' un fattore che gioca a favore della ditta. Infatti il cliente non rileva i problemi, poi quando emergono alla fine, dopo il rilascio sulla community, ormai e' tardi per le correzioni. Questo e' il punto caldo della vicenda. Il punto dove si gioca la differenza tra uno sviluppo riuscito e uno fallito. E qui i contributi possono arrivare da chiunque, anche da quelli che "sfruttano" il lavoro di altri. Se nello sfruttarlo si lamentano di eventuali problemi che il codice sviluppato palesa, gia' quello e' un ritorno ottimo. FAccio un esempio: a me serviva una funzionalita', mi faceva molto comodo e allora ho partecipato al suo finanziamento. Poi, pero' , usandola non potevo certo metterim a sbacarla in ogni dettaglio sarebbe stato semplicemente impossibile. Ecco pero' che messa in circolo fin da subito in giro per il mondo hanno cominciato a fioccare altre persone che si sono messe subito a usarla, e sono arrivate segnalazioni e suggerimenti, che hanno portato chi la ha sviluppata a migliorarla . Di questo io , che ho partecipato al suo finanziamento, non posso che essere contento. E mi rende sicuro che il mio investimento non e' andato perso, ne' vedo queste persone come "scrocconi" che usano senza dare niente in cambio. Uno dei motivi che a mio parere frena chi potrebbe investire e' proprio la mancanza di certezza della qualita' del risultato. Mentre un software commerciale ha una qualita' (piu' o meno sicura) ma dettata dal suo stesso costo e dalla sua diffusione. Quando vaiu a finanziare una cosa nuova, non ti accontenti delle assicurazioni che ti da' una ditta. Io per lo meno non mi posso accontentare di cio'. E sapere che ci sara' a giro per il mondo un esercito di potenziali utilizzatorei che metteranno alla prova la nuova funzionalita' stirandola e stressandola in ogni modo, per me' e' una garanzia che niente e nessun altro puo' darmi. Tutta gente che mi fa' questo lavoro gratis per giunta, senza pretende alcun compenso per l'impiego di tale funzionalita'. Non ci penso proprio a considerarli scrocconi. Andrea. -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
On Sun, Feb 26, 2012 at 10:27 AM, Andrea Peri <[hidden email]> wrote:
La separazione 20/80 fra sviluppo iniziale e manutenzione del software è un
dato ben noto dal punto di vista industriale. Gli utenti che riportano problemi offrono un servizio fondamentale, ma da come la metti tu sembra che l'utenza faccia l'80% del lavoro totale, dimenticando che
la segnalazione del problema è solo una parte: discutere il bug con l'utente, verificare che il problema ci sia davvero, correggere il software/documentazione è qualcosa che di nuovo viene fatto di nuovo dagli sviluppatori/scrittori di documentazione
o dalle persone attive in mailing list.. che spesso, come dice Stefano, son sempre gli stessi (mentre chi riporta i problemi spesso va e viene, riporta il problema che gli preme al momento e poi sparisce).
Piaccia o no c'e' un gruppo relativamente piccolo di persone che ha sulle spalle un carico elevato, e poi un gruppo molto ampio che si impegna molto meno. Chi fa parte del gruppo piccolo e caricato secondo me se ne deve fare una ragione,
si contribuisce al progetto perchè piace, perchè lo si ritiene importante, e si fa quanto si può/vuole senza prendersela più di tanto se altri potrebbero aiutare, ma non lo fanno. C'est la vie!
Ciao Andrea ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 339 8844549 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
Il 26/02/2012 11:06, Andrea Aime ha scritto:
> Gli utenti che riportano problemi offrono un servizio fondamentale, ma > da come > la metti tu sembra che l'utenza faccia l'80% del lavoro totale, > dimenticando che > la segnalazione del problema è solo una parte: discutere il bug con > l'utente, Un utente che segnala un probleme sparisce non serve ovviamente. Ma se segnala un problema e non fornisce elementi per riscontrarlo, in realta' e un fantasma. Sparendo lui, il problema sparisce con lui. Il problema diventa vero e concreto nel momento in cui viene fornito un case test per replicarlo. Fino a quel momento il presunto problema e' nello stato di "favoletta". > verificare che il problema ci sia davvero, correggere il > software/documentazione è qualcosa > che di nuovo viene fatto di nuovo dagli sviluppatori/scrittori di > documentazione Qui non concordo. Non ci credo assolutamente che chi sviluppa si metta lui a cercare il problema. Mai vista una ditta che gli segnali un difetto e si mette lei a cercarlo. Piuttosto ti chiede di produrre un esempio di dati minimo che riproduca l'errore. Una sorta di case-test minimo. Produrre questo pacchetto richiede tempo e impegno. Se lo fai fare alla ditta, il piu' delle volte ti rispondono che a loro il problema non risulta e la chiudono li'. Ho una statistica amplissima di casi con ditte anche serissime. Per cui questa convinzione è ben radicata. Ma capiamoci subito: Non sto' parlando di cosette "bischere" come una stringa sbagliata su una pagina oppure "cliccko' li' e appare errore". Ovviamente parlo di bachi seri, importanti. Se ad esmempio stai eseguendo una elaborazione con qualche Gbyte di dati e il sistema a un certo punto ti va in crash. E' ovvio che se anche segnali il problema, ti chiedono un set di dati, tra indentificare il problema, selezionare il pacchetto minimo e produrre una serie di operazioni che porti al crash , ci vuole tempo. Tutto questo tempo va a carico del cliente, la ditta non ci mette neanche un unghia del suo tempo, ma se ne sta' bella grassa e paciocca ad attendere. E del resto basta guardare i tempi. Due giorni di tempo per produrre il pacchetto con un set minimale e mezza giornata per risolverlo. La ditta ci mette mezza giornata di lavoro , il cliente 2 giorni. Per cui se questo lavoro me lo fa' qualcun'altro su Internet perche' anche a lui preme avere risolto il problema ben venga. Se lo scotto di avere questo e' avere un sacco di scrocconi che lo usano senza rendere niente in cambio a me non sembra cosi' rilevante. Chi segnala un problema e non aiuta a individuarlo vuol dire che realmente non gli interessa risolverlo e quindi e' un utilizzatore che non ha reale interesse a usarlo, amsi e' solo imbattuto casualmente in un problema o forse non e' neanche un problema, ma solo un equivoco e il giorno dopo riaccendendo il pc e' scomparso. Chi ha invece interesse a vedere risolti i problemi perche' usa tale prodotto per lavoro partecipa ben volentieri a fornire informazioni per la sua risoluzione. > o dalle persone attive in mailing list.. che spesso, come dice Stefano, > son sempre gli stessi (mentre chi riporta i problemi spesso va e viene, > riporta > il problema che gli preme al momento e poi sparisce). > Mettere in discussione il principio che uno possa usare un software senza dare niente in cambio è mettere in discussione il principio stesso del software Open a codice libero. Perche' chiedere dei soldi oppure del lavoro in cambio dell'uso di un certo software e' la medesima cosa. Lo so' che non e' questo che si dice, ma non riesco veramente a comprendere quale sia il problema reale. Io ho occasione ongi tanto di mettere documenti , informazioni e pezzi di codice a dispiosizione, e ho sempre il dubbio di quale sia il posto piu' adeguato dove metterli. Ma sempre mi pare che il sito di GFoss non sia ilposto piu' adeguato. Mi sbagliero' ma questa e' la mia impressione. Ti faccio un esempio: Quando ho voluto condividere una routine per i caricamenti batch di shapefiles su postgis ho anche valutato se metterla su gfoss. Pero' ho scartato la cosa, perche' sarebbe stata utile solo a chi legge l'italiano. Ed ho preferito metterla sul sito di postgis perche' ho ritenuto piu' attinente che stesse li' e perche' era in inglese. Questo avrebbe allargatola platea. Il risultato e' che ho avuto diverse ringraziamenti da persone sparse per il mondo , che mi hanno dato anche soddisfazione e questo mi basta. D'altronde era ovvio che in un sito di postgis ci potessero essere persone interessate a procedure di caricamento batch su postgres. http://trac.osgeo.org/postgis/wiki/UsersWikiBatchLoadShapefilesForWindowsUsingShp2pgsql se avessi messo la procedura su gfoss, nessuno di quelli che la hanno usata, avrebbe avuto tale occasione per due sole ragioni: se e' in italiano e' ristretta solo a chi comprende questa lingua. E poi chi cerca procedure per postgis le cerca sul sito di postgis. In seguito ho ragionato in maniera analoga quando si è trattato di usare la medesima tecnica per alcuni lavori con gdal, il sito ovvio di destinazione era necessariamente gdal. http://trac.osgeo.org/gdal/wiki/BatchCreationIndexesForShapefilesOnDOS oppure http://trac.osgeo.org/gdal/wiki/BatchConversionOfRasterFormatsOnDOS E' questo il problema ? Che nessuno alimenta il sito di gfoss con procedure di qualsiasi natura ? davvero si ambisce ad avere una babele di procedure per qualsiasi software ci sia ? scritte in Italiano ? Non mi 'e per niente chiaro.... _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
In reply to this post by Markus Neteler
2012/2/23 Markus Neteler <[hidden email]>:
> 2012/2/23 Stefano Costa <[hidden email]>: ... >> Nell'ultima settimana abbiamo avuto nuovamente inserimento di spam. Non è molto, >> ci sono voluti 5 minuti per cancellare le pagine e bloccare gli utenti, ma è >> comunque un impegno costante di cui evidentemente sono l'unico a farsi carico. > > Quale misure anti-spam ci sono? Ripeto la domanda :) > Esempi ... > - grass.osgeo.org: captcha + math-captcha: spam quasi mai Secondo me bisogna mettere qualcosa anche sul GFOSS-Wiki. Se serve aiuto, posso dare info + chiedere che cosa aveva fatto Martin Landa per il GRASS Wiki. Guardavo la lista: http://wiki.gfoss.it/index.php?title=Speciale:Registri/newusers&limit=250&type=newusers&month=&year= e direi che è ora di intervenire. Nel GRASS Wiki c'è blocco automatico del subrange del spammer, funziona molto bene. Suggerisco di implementare la stessa cosa anche nell GFOSS Wiki. ciao Markus _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
Il 29/02/2012 21:55, Markus Neteler ha scritto:
> Ripeto la domanda:) Ciao Markus, pensavo di aver già risposto ma mi sono perso qualche pezzo per strada forse. Ho aggiunto un captcha testuale, basato su una domanda a cui un qualunque utente italiano può rispondere facilmente, mentre sarà difficile per spammer stranieri e bot. La risposta è una città molto importante per la storia del GFOSS in generale e per quello italiano in particolare :) Per ora sta funzionando (da una settimana niente spam). > e direi che è ora di intervenire. Nel GRASS Wiki c'è blocco automatico > del subrange del spammer, funziona molto bene. Suggerisco di implementare > la stessa cosa anche nell GFOSS Wiki. Questo sarebbe molto utile. Se puoi mandarmi (in privato) indicazioni su come attivarlo te ne saremmo tutti molto grati. Grazie, steko _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 569 iscritti al 4.1.2012 |
Free forum by Nabble | Edit this page |