On Wed, Oct 29, 2008 at 9:55 AM, Luca Delucchi <[EMAIL PROTECTED]> wrote: > 2008/10/29 Edoardo Marascalchi <[EMAIL PROTECTED]>: >> Rimane il problema di chi sceglie i 3.. >> perché se qualcuno si mette d'accordo per "danneggiare", creare 3 >> account ed auto-validarsi non è proprio così difficile. > sicuramente c'è questo problema, ma essendoci molte persone che > possono controllare l'operato dei 3 (che io credo possano essere solo > 2) se si nota che lavorano male si possono sospendere dalla carica
quindi si vogliono introdurre dei livelli di amministratore ed impedire al grosso del pubblico di modificare la maggior parte dei dati? perche' se fosse solo questione di controllo dal basso non si potrebbe impedire a nessuno di agire sulle parti "bloccate", anche se la lista avesse deciso di non condividere il loro lavoro secondo me e` una soluzione fortemente contraria allo spirito del progetto alla fine visto il confronto con wikipedia e` vero che ci sono problemi con utenti inesperti e ci saranno problemi di vandalismo, ma per i dati trattati credo che sara` una situazione piu` simile a quella degli articoli matematici e informatici che non a quella degli articoli sui candidati presidenziali, e quindi il controllo di molti dovrebbe essere piu` che sufficiente ad ottenere dati nell'insieme di qualita` almeno comparabile a quella dei fornitori commerciali >> Io continuo a sostenere che la validazione è possibile solo forkando una >> versione "stabile" del DB. > facendo un fork bisognerebbe lavorare su due progetti > contemporaneamente che secondo me peggiora la situazione piu` che un fork sarebbe semplicemente uno snapshot stabile, periodicamente aggiornato con i backport delle migliorire della versione di sviluppo, come avviene per i software > anche perchè > ogni volta che si dovrebbe aggiornare il db forkato bisognerebbe > ricontrollare tutto. basterebbe controllare i diff, esattamente come si dovrebbe fare per controllare le parti da slucchettare un metodo di lavoro potrebbe essere avere un team per lo sviluppo della mappa certificata che, una volta a regime e supponendo snapshot trimestrali ha lo snapshot stabile ad esempio di gennaio 2009 il primo aprile 2009 pubblica lo snapshot precedente e ricava lo snapshot corrente la prima settimana di aprile calcola il diff tra i due snapshot e assegna tutte la parti modificate a qualcuno del team nel corso dei mesi successivi il team visita tutte le parti modificate e le controlla * se la correzione e` giusta viene cherrypickata nello snapshot stabile * se la correzione e` sbagliata la elimina dallo snapshot stabile, e gia` che e` sul posto vede se e` il caso di migliorare il db di sviluppo (quindi le modifiche appariranno al trimestre successivo) al primo luglio 2009 si ha uno snapshot stabile e verificato da pubblicare, e si puo` lavorare su quello successivo ovviamente, o si ha un volontario nel team per ogni quartiere / piccolo comune, oppure tutto questo processo puo` essere svolto solo da un'azienda che poi rivenda la certificazione sui dati e altrettanto ovviamente, sarebbe interessante scoprire se un lavoro del genere produca mappe di qualita` o se produca solo un pezzo di carta con scritto sopra "certificazione" e delle mappe come quelle di teleatlas... > A me piace molto l'idea del lucchetto... secondo me invece fa perdere al progetto buona parte di cio` che lo caratterizza -- Elena of Valhalla homepage: http://www.trueelena.org email: [EMAIL PROTECTED] _______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
