2009/4/18 Francesco Tombolini <tombo@adamantio.net>:
> Le revisioni di un pacchetto terminato secondo le nostre procedure
> possono essere effettuate anche dopo che il pacchetto è stato inviato su
> transifex.
>
> Le revisioni di un pacchetto terminato sono equivalenti ad una nuova
> traduzione, per cui chi prende l'incarico dovrà cercare a sua volta un
> revisore al fine di assicurare la qualità.
>
> Comunque in tempo di rilascio di versione, il team concentra gli sforzi
> sui pacchetti non tradotti, al fine di fornire la massima copertura
> possibile, mantenendo al lavoro almeno due persone per modulo.
Fin qui, tutto ok...
>
> Una volta garantito l'obbiettivo minimo (aver tradotto se possibile
> tutti i pacchetti) il team può concedersi alle revisioni di quei
> pacchetti che notoriamente (per il team) possono essere più imprecisi.
Ma bisogna sapere quali sono (vedi sotto)
>
> Comunque il presupposto per considerare il lavoro terminato, è il
> completamento della traduzione del modulo, che una volta sottoposto alla
> procedura di traduzione/revisione è considerato qualitativamente
> accettabile.
>
> Sarebbe interessante che una seconda revisione scaturisse da qualcosa
> di più sistematico e tracciabile che da una lettura casuale o da una
> mail indovinello, come ad esempio un errore in bugzilla od un esperienza
> diretta.
Il fatto è che se un modulo è al 100% di copertura (e abbiamo detto
che questo è l'obiettivo numero uno) difficilmente viene riaperto per
farne una seconda revisione. Quindi l'unico modo per accorgersi di una
traduzione farlocca è inciamparci come utilizzatore (credo sia questo
a cui ti riferisci con "esperienza diretta") come è successo a me per
i cross compilatori. Nel mio caso, so dove guardare/come contribuire
per risolvere, ma ho paura che un utente scrolli le spalle e passi ad
altro, rimanendo con una impressione di scarsa competenza.
>
> Le segnalazioni in bugzilla ci consentono di ricevere contributi anche
> da non appartenenti al team.
>
> Le segnalazioni in bugzilla creano quella precedentazione necessaria al
> team affinché si capisca quali sono i pacchetti completati che
> richiedano maggior attenzione.
Sono d'accordo (e se fosse necessario mi scuso ancora per la mail
indovinello, che però pare abbia sortito l'effetto che speravo, ovvero
parlare della qualità) sul migliorare la tracciabilità dei problemi.
Purtroppo bugzilla non è proprio il tool più facile da usare per il
neofita, quindi assumendo che il grosso degli utenti non sia troppo
tecnico, è difficile che riporteranno qualcosa con quel mezzo (quanti
bug ci sono aperti al momento?)
Inoltre, anche se avessimo qualche centinaio di bug report, non
sarebbe facile estrarre le statistiche necessarie, visto che il
componente non è fra i campi filtrabili del report, per cui anche se
l'idea è buona ci servirebbe qualche nuovo pezzo di "infrastruttura"
Riassumendo, la mia opinione è che bisognerebbe cercare di aumentare
la qualità della prima revisione, in modo che alle successive sia
sufficiente concentrarsi sulle stringhe nuove/fuzzy.
Ogni commento/proposta è benvenuto
--