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

List:       kde-i18n-it
Subject:    Re: Storie d'amore e d'anarchia
From:       Daniele Medri <madrid () linuxmeeting ! net>
Date:       2003-09-30 9:06:13
[Download RAW message or body]

Alle 22:52, lunedì 29 settembre 2003, Andrea Celli ha scritto:
> Anarchia, perché era il titolo del messaggio che ha innestato il discorso
> e descrive abbastanza bene lo scombussolamento che Daniele ha
> causato. D'altra parte un mio vecchio amico anarchico mi dice sempre
> che il modello di sviluppo del Free Software assomiglia dannatamente
> ai loro ideali utopistici.

Caro Andrea,

non c'è stato scombussolamento ne anarchia, ma un contributo lavorativo 
organizzato verso un obiettivo comune surclassando un'organizzazione forse 
non particolarmente efficiente e migliorabile in una fase di lavoro 
"non-freeze", quindi altamente instabile e mutabile.

(buoni, leggete fino alla fine prima di rispondere calorosamente)

C'è stato un peccato di comunicazione dove l'azione è stata più veloce della 
parola (per le ridotte modifiche apportate in alcuni casi) Riconosco di aver 
sbagliato su questo punto e l'ho già pubblicamente riconosciuto.

> Daniele ha messo una bomba, ha fatto il botto poi però non ha
> saputo spiegare bene le ragioni del malessere che lo ha spinto
> a comportarsi così. Si è limitato a proporre delle nuove
> "tavole della legge" che, come tutte le norme rigide, sono
> state subito subissate da critiche e rischiano di essere
> peggiori del "male".

non c'è bomba e di conseguenza alcun botto; ho già spiegato in molteplici mail 
che questa polemica è montata oltre ogni limite perché c'è stato solo impegno 
e lavoro in favore del nostro comune progetto e relativo beneficio per le 
parti interessate. Per il resto non ho in alcun modo proposto nuove "tavole 
della legge", ma semplici proposte da valutare congiuntamente in lista.

Le critiche provengono da una base troppo stretta e non rappresentativa delle 
persone (1? 2?) che collaborano a questo progetto e di conseguenza non si 
possono annulare prima di uno scambio collettivo.

E' anche necessario da parte tua indicare a quali proposte fai riferimento 
perché ne ho fatte diverse. La prima riguardava il sistema di gestione delle 
responsabilità, la seconda il bilanciamento del carico.

> Per esempio, non si è mai verificato un caso di abbandono "repentino"
> di un PO alla sua sorte. La chiamata alle armi che Andrea fa prima di
> ogni release ha sempre permesso i dare un traduttore attivo
> e confermato recentemente nel momento di effettivo bisogno.
> A nessuno importa che in questo momento ci siano 84 "buchi"
> in libkdegames.po. Quindi non ha nessun senso imporre
> alla gente di togliere un fuzzy alla settimana per non perdere
> il pacchetto. Poi, come la si mette con i doc? Non possono
> andare in CVS finché non sono completati.

La tua osservazione accentua la diversità tra stato "freeze" e "non-freeze". 
In uno stato freeze non ci sono cambiamenti per le etichette da tradurre o 
per la documentazione, nel non-freeze le cose cambiano ed è proprio quello 
dove c'è stato il mio contributo, una fase dove la maggior parte dei 
traduttori soliti non lavora o apporta minimi aggiornamenti.

Per quel che riguarda la documentazione la tua osservazione è assolutamente 
giusta e la condivido. La doc può andare sul CVS nel solo periodo di freeze 
dove c'è già una traduzione abbastanza stabile della GUI alla quale fare 
riferimento in maniera completa. Resta inteso che possiamo strutturare il 
sistema di gestione con le nuove caratteristiche in maniera che agisca 
localmente sulle singole aree (traduzioni) e sia disabilitata in altre (la 
documentazione). L'osservazione ha comunque offerto uno spunto aggiuntivo e 
per questo te ne sono grato.

Con le modifiche da me suggerite basterebbe una etichetta tradotta entro il 
periodo di "decadimento della propria responsabilità" (freeze, non-freeze) 
per mantenere la posizione, ma è una etichetta aggiuntiva rispetto a uno 
stato di inattività (monotona crescente?). Nel caso di inattività non è 
giustificabile trattenere un potenziale file da tradurre quando possono farlo 
gli altri. Resta inteso che si può sempre agire sulla costante GG_INATTIVO 
per allungare o ridurre i tempi di decadimento.

> Il punto essenziale dello sviluppo a "bazar" di Linux è la
> capacità di collaborare ad un livello sostanzialmente paritetico
> tra molte persone. Quando si sviluppa un software ci si incontra su
> una ML. Qualcuno propone una patch o qualcos'altro.
> Tutti ne discutono, tutti la compilano e la testano, decidono
> se vada implementa o elaborano nuove soluzioni ...
>
> Da  noi, invece, ognuno è responsabile di uno o più PO,
> se lo coltiva come un orticello privato. È  molto raro che si apra
> una discussione in lista su come tradurre qualcosa. La mia
> impressione è che la collaborazione, sia a livello di produzione
> che di verifica, sia molto scarsa.

dal modello "bazaar" all'orticello privato del nostro caso ci sono alcune 
osservazioni da fare. Quando Raymond ha scritto il articolo:
 
http://www.unimo.it/corsi/linux/presentazione/cattedrale/cathedral-bazaar.html

fa riferimento a collaborazione congiunta per lo sviluppo di software e, in 
particolar modo, librerie condivise. La chiave sembra essere la "dipendenza" 
di una soluzione rispetto ad altre e nel caso specifico è essenziale 
collaborare affinchè tutti possano beneficiare della risorsa.

Il modello bazaar ha, come dimostrano vari paper presenti nella biblioteca 
"open" del MIT, dei limiti di gestione quando i collaboratori crescono di 
numero. L'esempio lampante è il kernel di Linux: non esiste bazaar ma una 
struttura con un maintainer (Torvalds) e una ventina di sotto-responsabili 
per ogni singola area per distribuire il carico di valutazione-test che prima 
stava tutto sul maintainer unico.

Nelle traduzioni non abbiamo vincoli di dipendenza comune se non di carattere 
estetico e di uniformità del nostro lavoro congiunto. Se le modifiche al 
sistema di gestione da me proposte sono ancora da valutare per una migliore 
definizione, appare tremendamente semplice pensare a una differente 
distribuzione del carico che attualmente appartiene a Andrea (Rizzi) e che 
lui stesso ha presentato.

Ci sono molti collaboratori per la localizzazione italiana di kde e tra questi 
vi sono persone attive da diverso tempo e impegnate su un ampio numero di 
traduzioni.

Se Rizzi può rivestire per carattere storico il ruolo di maintainer, i 
responsabili di pacchetti con il loro proprio account CVS possono occuparsi 
di fare il commit delle traduzioni di altre persone e delle proprie. 
L'esempio che si era fatto era per kdepim/kdenetwork e le persone al quale 
autorizzerei l'accesso CVS sono Astarita, Pasotti e altri. Senza nulla 
togliere a Luciano o Giovanni, non si capisce quale sia stata la logica di 
assegnazione dell'accesso cvs seguita fino a ora.

> Però non dobbiamo dimenticarci che siamo un gruppo di
> "individui" che lavorano ad un progetto comune e dobbiamo
> evitare i rischi di scarsa omogeneità o qualità che sono insiti
> in un lavoro troppo individuale.

K A I Z E N (il miglioramento continuo)

1. criticare in maniera costruttiva;
2. accettare le critiche;
3. applicare le modifiche per migliorare (GOTO 1)

> Una proposta potrebbe essere quella di effettuare una correzione
> pubblica nei tempi "morti" tra una release e l'altra. Si potrebbero porre
> in discussione ogni settimana dei blocchi "ragionevoli". Ci vorranno
> sicuramente parecchie release prima di "finire" il lavoro. Che dovrebbe
> ripartire immediatamente. Pero, sono convito che una discussione sui
> un pacchetto porterebbe benefici anche su tutti gli altri. Quello che
> ciascuno di noi imparerebbe dal confronto reciproco, sarebbe
> ben presto riversato anche sulle proprie traduzioni.

Lavorare su una release è un salto nel vuoto perché si lavora su applicazioni 
che difficilmente tutti hanno e provano e non c'è alcun feedback esterno.

Le cose cambiano tra le minor.release dove quasi tutti possono verificare 
direttamente come appare la propria traduzione e utenti esterni possono 
contribuire loro stessi a segnalazioni di errori o migliorie.

Considerando che tra le minor.release c'è tempo e etichette piuttosto stabili, 
penso sia questa la fase migliore per discutere pubblicamente delle 
traduzioni fatte e compiere relative scelte a riguardo.

Che ne pensate?

-- 
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

_______________________________________________
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]