[Kde-l10n-es] Reflexiones sobre la liberación de asignaciones desatendidas

[Eloy Cuadra]

Hola:

El domingo, 31 de marzo de 2013, miguel navarrete, escribió:
> El Dom 24 Mar 2013 12:16:30 Eloy Cuadra escribió:
> > Por otro lado, el plazo de dos meses me parece muy largo. Casi excesivo.
> > Esa regla data de hace muchos años, cuando había pocos lanzamientos de
> > KDE. En la actualidad, tenemos revisiones de KDE cada mes, por lo que me
> > parece que lo adecuado sería dar un plazo de un mes en lugar de dos.
> 
> Podría considerarse una tabla de plazos de acuerdo a determinado tipo de
> colaborador. Por ejemplo, los nuevos y los que empiezan con una traducción
> nueva, envían su avance «en el estado que se encuentre» al final de cada
> mes. Si el avance de los «no nuevos» que han empezado con una nueva
> traducción es satisfactorio en relación al tamaño del paquete asignado y el
> plazo que deben cumplir (habría que definir un porcentaje de avance para
> cada paquete) podrían ampliar su plazo de entrega a dos meses. Mientras que
> los más avezados (que hayan demostrado a lo largo de su colaboración un
> ritmo adecuado, sus traducciones tienen pocos errores, etc) podrían tener
> un plazo mayor de entrega (suponiendo que entregarán el paquete traducido
> completamente, podría ser hasta una semana antes de cada lanzamiento).

Esa no es la idea :-) Pero, como bien dices, hay (básicamente) dos tipos de 
traductores: el recién llegado (normalmente inexperto y con muchas cosas por 
aprender, independientemente de su nivel de inglés) y el experimentado (a 
veces con un nivel no tan bueno de inglés).

El problema con los recién llegados es que tienen que superar muchos 
obstáculos antes de hacerse cargo de algo realmente importante (un paquete de 
kdeX o de extragear-X). Es de agradecer el interés que tiene mucha gente por 
colaborar con la traducción de KDE. En realidad, es algo digno de elogio. Pero 
antes de lanzarse de lleno a esta labor tienen que aprender muchas cosas. Por 
eso se les pide a todos que lean atentamente y asimilen las directrices que se 
dan en nuestra web, que se familiaricen con nuestro glosario, que entiendan 
dónde y por qué se suelen cometer los errores típicos, que aprendan a resolver 
un conflicto, a usar svn, a comprender los ciclos de lanzamiento de KDE, etc. 
Se supone que todo esto se tiene que asimilar antes de empezar a traducir.

Pero la experiencia nos dice que casi la totalidad de los recién llegados leen 
nuestra web de pasada sin prestar demasiada atención a puntos importantes y 
que solicitan un paquete de playground sin saber muy bien lo que están 
haciendo. Muchos de ellos llegan a ese punto y se dan cuenta de que no saben 
cómo descargar sus traducciones, por ejemplo. Otros intentan traducir y 
cometen los típicos errores que se detallan en nuestra web. Otros se desaniman 
cuando se enfrentan a svn, a Lokalize o a las mismas traducciones, y van 
aplazando el trabajo hasta que lo abandonan definitivamente sin decir nada.

Otros, los que se toman su trabajo con interés, superan todas esas barreras y 
traducen, pero caen en el error de no enviar periódicamente su trabajo. 
Supongo que entienden que tienen que enviarlo cuando está terminado, aunque 
esto no es cierto. Lo importante es que envíen traducciones cuanto antes, ya 
que su trabajo se tiene que revisar concienzudamente para detectar los 
posibles errores que cometan. Es relativamente fácil detectar un error y 
notificar a su encargado cuando se revisa un archivo con pocas modificaciones. 
Pero es muy difícil hacerlo cuando se envía una veintena de archivos con cerca 
de mil modificaciones ;-)

Por eso es importante que los recién llegados traduzcan y envíen su trabajo 
cuanto antes, independientemente del estado en que se encuentre. Para estos 
traductores, un plazo de un mes es más que razonable (yo diría que es 
excesivo).

Con los traductores experimentados, el problema es otro. Por lo general, no 
suelen cometer fallos importantes y sus asignaciones suelen estar bastante 
avanzadas, aunque tienen que hacerse cargo de la traducción de dos ramas 
(branches/stable y trunk). Excepto algunos miembros de nuestro equipo muy 
activos que procuran tener su trabajo revisado y al día (y cuyas traducciones 
no necesitan apenas revisión), tenemos otros traductores que envían su trabajo 
de forma muy irregular y tras largos periodos de inactividad (que a veces 
superan varios meses). El problema es que no suelen completar su trabajo a 
tiempo para los lanzamientos de KDE; o que lo hacen los últimos días, con 
prisas y cometiendo errores que no da tiempo de detectar y corregir.

En este caso, el plazo de un mes de inactividad viene marcado por los ciclos 
de lanzamiento de KDE. Más de un mes sería excesivo, aunque sería deseable que 
completaran su trabajo al menos 15 días antes de los lanzamientos de KDE. En 
branches/stable no suele haber problema, porque está permanentemente en estado 
de «congelación de mensajes»; aquí suelen aparecer muy pocos mensajes nuevos 
que se pueden liquidar en un momento; lo deseable sería avanzar en la 
traducción de la documentación, muy retrasada en varios paquetes. En la rama 
trunk estamos libres de presión durante, aproximadamente, cinco meses; pero es 
necesario avanzar en las traducciones o el trabajo nos desbordará el mes 
anterior al lanzamiento de una nueva versión de KDE.


> >  Estoy
> > trabajando en un /script/ que detecte de forma correcta esa falta de
> > atención en  los archivos PO para poder avisar a sus encargados de que
> > están a punto de perder la asignación.
> 
> Sería interesante contar con una página en que se pudiera ver gráficamente
> el avance de las traducciones, una especie de carta grantt o algo por el
> estilo. Los traductores informarían de su avance (quizás a través de
> KSvnUpdater) una vez a la semana, se marcaría la fecha de recepción y envío
> de la traducción y dicho avance declarado se contrastaría con la revisión
> que hagan los encargados de subir las traducciones al repositorio y los
> resultados de las validaciones para calcular una especie de reputación del
> traductor y con eso podrían definirse sus plazos de entrega. Una idea para
> el futuro, claro :-)

Esto ya existe, más o menos. Son las estadísticas oficiales de KDE que se 
actualizan cada día, aproximadamente a medianoche. Se puede acceder a ellas en 
la página de localización de KDE. Para nuestro equipo son:

http://l10n.kde.org/stats/gui/trunk-kde4/team/es/
http://l10n.kde.org/stats/doc/trunk-kde4/team/es/
http://l10n.kde.org/stats/gui/stable-kde4/team/es/
http://l10n.kde.org/stats/doc/stable-kde4/team/es/

Si pulsas en un paquete puedes ver sus detalles.

Al final de cada lista hay un gráfico con la evolución de su traducción en el 
tiempo (los últimos diez días, más o menos).

También se puede acceder a esta información desde nuestra web 
(http://es.l10n.kde.org/estadisticas.php).


> En cualquier caso, no veo impedimento a reducir el plazo de envío (podrían
> ser hasta cada quince días), siempre y cuando no suponga una sobrecarga
> adicional para el/los coordinadores ni sea lo suficientemente inflexible
> como para producir el alejamiento de voluntarios por no alcanzar a cumplir
> los plazos.

Es que cumplir el plazo es tan fácil como decir «hoy traduzco», actualizo mi 
copia local del repositorio, dedico 15 o 20 minutos a traducir mis 
asignaciones, envío los cambios al coordinador y ya está. Repetir esto una vez 
a la semana es extremadamente sencillo, y así voy avanzando en la traducción 
de mis asignaciones.

Cuando se le asigna playground-X a un recién llegado, no se espera que tenga 
traducido el paquete en el plazo de un mes, sino que avance algo durante ese 
mes, que envíe su trabajo cada pocos días para que se puedan detectar y 
corregir sus fallos.

Para mí, como coordinador, la sobrecarga de trabajo viene cuando, tres o 
cuatro días antes de un lanzamiento de KDE, me llega una remesa de cientos de 
archivos con miles de modificaciones de última hora. Una vez más, la 
experiencia nos dice que no todos disponemos del tiempo libre necesario para 
llevar a cabo nuestro trabajo cuando quisiéramos ;-)

Un saludo,
-- 
Eloy Cuadra