[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-it
Subject:    Re: Anarchia
From:       Daniele Medri <madrid () linuxmeeting ! net>
Date:       2003-09-29 9:29:59
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alle 16:44, venerdì 26 settembre 2003, Andrea RIZZI ha scritto:
> > Per chi lavora in locale: non siamo in freeze, quindi con
> > file da tradurre
> > fortemente mutabili, mi chiedo come si possa lavorare
> > senza tempi "rapidi"
> > tra checkout-commit o senza giornalieri "cvs update" che
> > aggiornino i file
> > con label nuove o altre modifiche.
>
> Purtroppo i tempi "rapidi" del CVS non sono accessibili a
> tutti visto che non tutti hanno l'account CVS e la
> procedura per mettere il file sul CVS tipicamente e
> spedirlo a me che poi lo metto sul CVS il che può portare
> attese anche di qualche giorno. Questo sistema non è quindi
> utilizzabile dalla maggior parte dei traduttori e si
> preferisce da sempre il seguente schema:
> -il traduttore traduce la sua copia, quando è a buon punto
> la manda a me che la metto sul CVS e si aspetta qualche
> giorno in modo che gli script facciano il loro lavoro e i
> CVS anonimi si aggiornino (forse sora sono sempre
> aggiornati ma un tempo non era cosi)

quantifica: 2 / 3 giorni tra spedizione del traduttore e commit?
consideriamo tempo "rapido" questo.. e anche se servirebbero più di 5 giorni 
parecchi file sono già cambiati dalla versione CVS (ora in freeze).

se questo è un limite nei tempi operativi, aggiungiamo più account CVS o 
distribuiamo il carico sugli attuali commit-ers (5 persone?). Ci sono persone 
che lavorano su molti pacchetti da molto tempo e per questi credo ci sia la 
fiducia e l'agevolazione nel dare loro un account. Sui restanti traduttori, 
che magari si occupano di pochi file e partecipazione/attività sporadica, si 
può migliorare l'organizzazione distribuendo il carico.

In questo modo possiamo ridurre i tempi tra checkout-commit e guadagnarci.

> > Aggiornare dal CVS è
> > anche una delle
> > raccomandazioni da seguire prima di qualsiasi commit.
>
> Solo per chi ha l'accesso al CVS.

indipendentemente da chi ha accesso o meno, un update è sempre consigliato e 
questo Andrea lo sai pure tu. Se non si fa in locale verrà fatto in remoto 
sul server automaticamente: ridurre il carico della "nostra" risorsa centrale 
potrebbe essere cosa utile.

> > IL SISTEMA DI GESTIONE
> >
> > il sistema di gestione presenta NOTEVOLI problemi e non
> > mi stupisco che non
> > sia stato ancora adottato da i18n.kde.org.
>
> Non ci è stato messo perché io non ho mai chiesto di
> mettere quello chifo scritto da uno che vedeva il php per
> la prima volta sul sito ufficiale.

se il problema era "delineare le caratteristiche di un progetto", se ne poteva 
parlare anche in lista per delineare le caratteristiche ritenuti utili.

se il problema era "non conosco molto PHP e ci provo", se ne poteva parlare 
ugualmente in lista visto che, come mi sembra di aver capito, ci sono persone 
con maggiore esperienza in merito (Ale.Astarita, io stesso).

> Io avevo chiesto a claudiu di fare qualcosa di simile ma
> non credo avesse tempo per farlo.

lo avevi chiesto in lista o direttamente?
Se era una richiesta pubblica, mi dispiace ma non l'ho vista o non la ricordo.

> > a) Togliere la responsabilità su un pacchetto se il
> > numero di "fuzzy" o voci
> > non tradotte è superiore a un dato valore di percentuale.
> > Segnalare la cosa
> > con una mail automatica in lista, richiamando nuovi
> > traduttori.
>
> Questa di per se come regola non funziona visto che il
> nuovo traduttore sarebbe subito rimosso dall'incarico in
> quanto il file sarebbe ancora troppo fuzzy (al momento
> della nuova assegnazione) quindi bisognerebbe dare un tempo
> minimo per migliorarne lo stato...quanto? dipende dal file,
> dal traduttore e dai suoi tempi liberi, dalla distanza
> della release.

un valore percentuale, come ho indicato, una COSTANTE presente in un file 
centrale che possiamo cambiare rapidamente secondo le nostre esigenze. I 
tempi prima che la responsabilità decada sul file sono anche dipendenti dalla 
COSTANTE di stato traduzione (freeze, non-freeze, ecc).

> > b) Togliere la responsabilità su un pacchetto se l'ultima
> > modifica è superiore
> > a una COSTANTE che indica i giorni di inattività.
> > Segnalare la cosa con una
> > mail automatica in lista, richiamando nuovi traduttori.
>
> Non ci importa di avere i file aggiornati in mezzo alle
> relase anzi io trovo inutile portare tutto al 100% a due
> mesi dalla release rischiando di vedere il mio lavoro
> buttato da un cambio di stringhe.
> L'unica cosa rilevante è riuscire ad avere completate le
> cose per il giorno della release.

leggi prima sulla COSTANTE di stato.
Durante un "non-freeze" possiamo allungare i tempi.. (es. 3 settimane)
Durante un "freeze" ridurli.. (es. 7 giorni)

Il decadimento della responsabilità è sempre poi relativo ai file che 
presentano un numero percentuale inferiore alla nostra COSTANTE.

Se il livello è troppo alto.. si abbassa facilmente, se troppo basso alziamo.

> > c) Segnalare in lista, con una mail, l'apparsa di nuovi
> > templates liberi e
> > disponibili per la traduzione richiamando nuovi
> > traduttori.
>
> L'automatizzazione della disponibiltà dei nuovi file è un
> argomento di cui stavamo già discutendo..
> Per ora comunque io ho segnalato 15 giorni fa all'apertura
> dell'HEAD
> che c'erano nuovi file (sono facilmente riconoscibili dallo
> status "no translation" nel sistema di assegnazione) e ho
> anche detto ai nuovi traduttori che era il momento buono
> per chiederli (dicendo anche che era presto per iniziare a
> tradurre l'HEAD visto che siamo ben lontani dal freeze)...
> peccato che molti di questi file te li sei presi tu senza
> neanche degnarti di usare il sistema di assegnazione.

molto spesso non esistono nemmeno sul sistema di assegnazione, e come ho già 
indicato, gli aggiornamenti da me fatti erano in gran parte di modeste 
dimensioni. Io non ho "preso" un bel niente.. ho cercato di tradurli e il 
beneficio è comune, un lavoro in meno per altri.. che ora eviterò di compiere 
vista la polemica.

> > d) Inviare una mail diretta che solleciti ogni singolo
> > traduttore a terminare
> > il proprio lavoro su [la lista dei file non completamente
> > tradotti]: sulla
> > mail dovrà essere riportato un collegamento web dove è
> > possibile:
> >
> >        "Declinare" la responsabiità su singoli file e la
> > possibilità di aggiungere
> > una motivazione (es. "non ho tempo", "ho altro da fare")
> > che sarà prontamente
> > riassuna in lista con una mail e rimetterà in gioco i
> > file senza
> > responsabile.
>
> Con questa tua politica (unita al punto b di questo elenco)
> io non dovrei avere neanche un file visto che li faccio
> tutti nelle ultime settimane eppure i miei file nel momento
> in cui conta (alla release) sono sempre tradotti al 100%.

non è una mia politica, è una proposta che desidero discutere apertamente e 
non solo con te per sentire altri pareri, critiche e suggerimenti. Siamo qui 
per capire se il sistema di assegnazioni è migliorabile e può ricevere 
ulteriori utili caratteristiche per la gestione.

ribadisco poi un punto sul quale credo non hai capito o non mi sono spiegato 
bene io. La presenza di COSTANTI ci permette di adeguare il sistema alle 
nostre esigenze come vogliamo, cambiando lo stato (freeze, non-freeze), la 
percentuale limite (es. 75% della traduzione), i giorni di inattività (es. 7 
giorni).

> >       "Accettare", per proseguire la traduzione.
> >
> > L'invio dovrà essere ripetuto "n" volte (una costante) e
> > inviato in
> > corrispondenza di date predetermiante (es. freeze o
> > prossime scadenze per
> > l'invio). Se latita una scelta tra declinare/accettare il
> > sistema dovrà
> > inviare in lista una mail e richiamare un nuovo
> > traduttore.
>
> Cosi floodiamo sia la lista che le mailbox dei traduttori,
> non solo li opprimiamo fino a quando non si stufano e ci
> dicono va be allora declino tutto pur che non mi rompiate
> le scatole.

tutto qua il problema?

soluzione "semplice": aggiungiamo all'oggetto un "[FILE]" e con un filtro 
sulla posta tutti possono spostare le mail su una cartella differente.

soluzione "banale": si crea una mailing lista aggiuntiva per il nostro gruppo 
su kde.gulp.linux.it


> Ci sono un po' di cose inoltre che mi lasciano perplesso:
> 1-Perché fai queste proposte di riforma adesso e non hai
> detto prima che il sistema non ti piaceva

stai scherzando? se c'è una persona che attivamente critica e cerca di 
migliorare il nostro modo di lavorare quella sono io, sia in lista che via 
mail a te direttamente (es. la gestione delle statistiche di qualche giorno 
fa)

> 2-Perché proponi di aumentare l'automatizzazione del
> processo ma già allo stato attuale ignori il sistema di
> assegnazione... cosa mi dovrebbe far pensare che
> utilizzeresti il tuo nuovo sistema di assegnazione visto
> che già ora te ne freghi e lavori senza dir niente a
> nessuno su file che potresti tranquillamente richiederecon
> tre click.

perché il sistema così come è ora non è efficiente.

se su un file non c'è miglioramento nella traduzione entro un certo periodo di 
tempo, è bene che la traduzioni rientri disponibile per altri 
volontari/traduttori.

un esempio: i file della documentazione assegnati e non seguiti, perché 
dovrebbero essere assegnati a qualcuno.. quando magari non c'è attività o 
nemmeno intenzione? Meglio renderli "disponibili" a chi vuole lavorarci 
sopra.

> Io credo che il sistema di assegnazione sia una cosa utile
> per ricordarsi chi fa cosa non per farci da cane da guardia
> o da poliziotto, il rispettare quelle assegnazioni, le
> discussioni su "a chi assegnare cosa" ecc.. sono lasciate a
> noi come persone non ad uno script PHP nel pieno spirito
> della comunità di KDE (non ci sono ACL sul CVS di KDE). Si
> tratta di essere persone che si rispettano tra di loro, che
> hanno fiducia le une nelle altre e che hanno un certo senso
> di responsabilità. Credo che siamo riusciti, nel corso
> degli anni, ad avere sempre queste condizioni soddisfatte e
> non abbiamo mai problemi come quelli sorti ultimamente.

il sistema di assegnazione è utile, ma così come è non è efficiente.
le modifiche suggerite potrebbero essere la risposta e, senza clima di 
terrore, riporterebbero i file da tradurre disponibili a chi può farlo.

hai citato prima kxconfig: era "mio" perché era stato spostato su kdeadmin, ma 
ho cercato di lavorarci sopra come potevo. Se le modifiche da me suggerite 
fossero state attive il file sarebbe ritornato disponibile per la traduzione 
a chiunque. Idem per la documentazione.

Comunque.. per chiudere, se queste caratteristiche possono risultare difficili 
da implementare o richiedere troppo tempo per - , l'assegnazione di maggiori 
account e una equa distribuzione dei commit-file sul CVS risolverebbe molti 
problemi e ridurrebbe i tempi IMHO.

Suggerimenti da parte delle altre persone in lista?


Saluti
- -- 
Daniele Medri <daniele.medri @ libero.it>
homepage: http://www.linux.it/~madrid/

"Statistics are like bikinis. What they reveal is suggestive,
	but what they conceal is vital" - Aaron Levenstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/d/uXIQMOQEPV3KYRAtRyAJ9MPqRYVsHGfv+p5HzkPHcboLyXKACgj8TC
uJPK6s4LczCahSrdeX0gy/Y=
=9Nld
-----END PGP SIGNATURE-----

_______________________________________________
Traduzioni di KDE in italiano: http://i18n.kde.org/teams/it
http://mail.kde.org/mailman/listinfo/kde-i18n-it

[prev in list] [next in list] [prev in thread] [next in thread]