Cómo iniciar un proyecto en TLDP-ES
Ismael Olea
$date: $
| Historial de revisiones | ||
|---|---|---|
| Revisión 0.1 | 6 de febrero de 2002 | |
| Publicación inicial. | ||
| Revisión 0.2 | 1 de julio de 2002 | |
| Revisión a cargo de juanrafael.fernandez[@]hispalinux.es. | ||
| Revisión 0.3 | 17 de marzo de 2003 | |
| Revisión a cargo de juanrafael.fernandez[@]hispalinux.es. | ||
- Tabla de contenidos
- 1. Introducción
- 2. Pasos
- 3. Recomendaciones
- 3.1. Lista LuCAS
- 3.2. Otras listas
- 3.3. Información de la página web
- 3.4. Anuncios y novedades
- 3.5. Glosario y consultas de terminología
- 3.6. Uso del CVS
- 3.7. Uso de bugzilla
- 3.7.1. Creando los primeros partes
- 3.8. Animación del proyecto
1. Introducción
Este breve artículo está especialmente dirigido a los editores/coordinadores de esfuerzos de documentación bien originales o bien de traducción. Tampoco está de más que los voluntarios lo lean para que conozcan cómo puede desarrollarse el trabajo y como implicarse al máximo de sus intereses y objetivos.
El documento está en plena fase de desarrollo, así que es probable que cambie de forma sensible en el futuro.
Si cree que alguna parte puede ser mejorada, por favor, no deje de indicárselo al autor. El objetivo es facilitar al máximo su comprensión y uso.
Recuerde que las herramientas que vamos a presentar están destinadas a facilitar el trabajo de traductores y redactores. Aunque en un primer momento la cantidad de información nueva pueda parecer abrumadora, comprobará lo fácil que es familiarizarse con ellas y cómo ayudan a llevar adelante su proyecto.
Estamos trabajando en la construcción de herramientas que mejoren el automatismo del proceso de publicación y gestión bibliotecaria de los documentos (imprenta-e, bibliotecario-e). También estamos ocupados construyendo Forja, un sistema que en el futuro lo hará todo todavía más sencillo, pero por ahora no es posible su uso (por cierto necesitamos la colaboración de voluntarios para escribir código, diseñar especificaciones y probar los prototipos de herramientas).
Una condición previa es importante: los documentos que se aporten a TLDP deben ser libres. Debe saberse también que las traducciones son documentos independientes con entidad legal propia, y son consideradas modificaciones del documento original. No importa que se traduzca un documento sobre alguna aplicación comercial o de fuente abierta, lo importante es la licencia del documento, si aparece algo como: “Queda prohibido cualquier cambio, almacenamiento, distribución…”, etc. dentro del documento original, no es documentación libre y no la podremos aceptar en TLDP, pero si la licencia permite modificarlo (su traducción en este caso), almacenarlo y reproducirlo, es de los nuestros.
Para saber más sobre el tema, puede consultar el artículo Licencias libres de documentación y aspectos de traducción escrito por Javier Fernández-Sanguino Peña.
Y recuerde: no hay proyecto pequeño. Cada contribución viene a sumarse al gran volumen de documentación que genera la comunidad del software libre, y su tamaño ya es gigantesco.
2. Pasos
Elección de la obra y de su título: plantear el objetivo de la obra y de su estructura y elegir un título que la identifique clara y concisamente.
Por ejemplo supongamos que hemos decido traducir los treinta tomos de la edición completa de las obras de Kant. El título de nuestro primer proyecto sería «Crítica de la razón pura».
Consulta a la lista TLDP-ES sobre el proyecto.
Es más que conveniente asegurarse de que no hay un trabajo previo en marcha o material disponible para ser reutilizado.
Elección del editor.
Es necesario que una persona se haga cargo de los trabajos de coordinación y seguimiento de las asignaciones de trabajos y de la supervisión general. Si hay más de uno, pues mejor que mejor.
Es el momento de que pida ayuda en lucas-voluntarios.
El editor enlazará directamente con los coordinadores de TLDP-ES y para poder hacer su tarea debe abrírsele una cuenta CVS en cvs.hispalinux.es.
Elección del nombre normalizado del proyecto.
Para conseguir un poco de orden en la masa de documentos que esperamos alojar y publicar, TLDP-ES sigue la política de normalizar los nombres de los proyectos. De esta manera los documentos comienzan por el prefijo «doc-», a su vez seguido de «curso-» si el documento pertenece a un curso, «informe-» si es un informe, etc. A este nombre le llamamos NOMBRECODIGO.
Este nombre codificado ha sido tradicionalmente alguna clase de acrónimo del título (quizás es más importante que sea explicativo) y es necesario para que haya coherencia a la hora de crear los directorios de publicación, la url del proyecto, el módulo CVS, los partes Bugzilla y la lista de correo, si es que se precisa. Un ejemplo sería «doc-kant-critica-razon-pura».
Es conveniente que se examine el listado de módulos de TLDP-ES (se puede examinar fácilmente ), por dos motivos principales: para crear un nombre que siga los convenios establecidos y para que cada módulo tenga un nombre suficientemente distinto de los demás (además de que de este modo puede comprobarse que el proyecto que pretende crearse no repite trabajo ya hecho).
Estos primeros pasos los realiza el propio equipo de trabajo. Esta información es necesaria para los pasos siguientes, que deben ser realizados por los coordinadores de TLDP-ES.
Crear módulo CVS.
CVS es una herramienta maravillosa para compartir y modificar código fuente en grupo. Su control de versiones puede ser un alivio incluso cuando lo usa una única persona. Además es el medio ideal para el intercambio de originales entre las diferentes etapas del ciclo de edición.
Como el uso del cvs se comparte con otros proyectos se recomienda también usar el nombre normalizado NOMBRECODIGO.
Se procura mantener un fichero LEAME.txt para identificar al proyecto y al coordinador del trabajo.
Este trabajo deberá hacerlo alguno de los coordinadores de TLDP-ES.
Creación de cuentas CVS.
Cada colaborador que use el CVS necesitará una cuenta para acceder a él. Si es sólo para lectura bastará el acceso anónimo pero si necesita escribir necesitará una cuenta propia. Ambas cuestiones se explican en nuestras páginas sobre cvs.
Este trabajo deberá hacerlo necesariamente alguno de los coordinadores de TLDP-ES a petición de los miembros del equipo de trabajo.
Si nunca ha trabajado con CVS es probable que necesite del documento de introducción que hemos preparado.
Creación de la página web de presentación del proyecto.
Creemos conveniente que las páginas del proyecto cuelguen de http://es.tldp.org, para favorecer el crecimiento de la comunidad de desarrolladores de documentación electrónica.
Es muy sencillo integrar una página HTML sencilla en las páginas de TLDP-ES. A día de hoy se usa la tecnología WML en las fuentes del sitio web de TLDP-ES.
Para el nombre de los ficheros se recomienda el convenio proy-NOMBRECODIGO.wml. Puede usarse como ejemplo cualquiera de los ficheros wml ya creados en el módulo web-lucas/wml/ .
El prototipo lo puede realizar cualquier colaborador. Basta con que sea una sencilla página que describa los detalles e informaciones importantes del proyecto. Puede ver el resultado en este ejemplo, la del proyecto garl.
Si el encargado de la página no se atreve a integrarla en el web TLDP-ES, a pesar de lo fácil que es utilizando cvs, se la hace llegar a alguno de los coordinadores de TLDP-ES y él se encargará de hacerlo. A partir de ese momento los miembros del proyecto con acceso de escritura al cvs podrán mantener directamente esa página.
El servidor principal de TLDP-ES se actualiza automática y directamente desde el cvs cada 15 minutos, y las réplicas cada 24 horas a horarios diferentes.
Registro en la web TLDP-ES.
Registrar el proyecto en TLDP-ES, en función de las características del trabajo.
En la página de proyectos (web-lucas/wml/proyectos.wml), si es un proyecto con desarrollo activo.
Categorización en el menú principal, encartándolo en la sección más adecuada (tutoriales, informes, cursos, conferencias…), si ya hay disponible para publicar alguna versión.
Este debe ser hecho o, mejor, supervisado por uno de los coordinadores de TLDP-ES, para asegurar la homogeneidad de la web. El mantenimiento de la información lo podrán hacer los propios miembros del equipo de trabajo.
Abrir producto Bugzilla.
Bugzilla es una utilidad para gestionar tareas pendientes que Hispalinux pone a nuestra disposición y que compartimos con otras campañas y proyectos. Es la forma más sencilla de saber en cada momento qué hay hecho, qué hay por hacer, quien hace cada cosa y disponer de un histórico completo de todo el proyecto.
Aunque sería altamente deseable, actualmente existen problemas para la apertura de nuevos productos Bugzilla. Por lo tanto es imprescindible el uso de los productos existentes (que siguen el convenio establecido: su nombre es doc-NOMBRECODIGO) y, en caso de no ser adecuados, utilizar los productos genéricos «TLDP-ES (LuCAS)» y «TLDP-ES I+D».
Se contemplan los siguientes componentes bugzilla para cada producto de desarrollo de documentación:
1.- Creación, asuntos relativos a la escritura o traducción y revisión de los textos.
2.- Reproducción, asuntos relacionados con la creación de los formatos de reproducción, la maquetación y el uso de filtros para obtener los formatos finales de publicación.
3.- Publicación, asuntos relacionados con la publicación en TLDP-ES de las versiones finales.
4.- Errata, erratas en el documento.
5.- Puede ser necesario abrir un componente Otros, para el resto de cuestiones no categorizadas arriba.
Este trabajo deberá hacerlo necesariamente alguno de los coordinadores de TLDP-ES.
Si nunca ha trabajado con Bugzilla es probable que necesite del documento de introducción que hemos preparado.
Lista de correo.
En la mayoría de los casos bastará el uso de las listas ya abiertas. Si durante el desarrollo del proyecto resultase obvio la necesidad de crear una nueva lista se realizará sin mayor problema. Se piden, mediante Bugzilla, al producto «Hispalinux», componente «mailman».
3. Recomendaciones
Recomendaciones y consejos para el desarrollo de proyectos de documentación en TLDP-ES y mejor aprovechamiento de los recursos disponibles.
3.1. Lista LuCAS
La lista LuCAS es nuestra principal herramienta de coordinación. Es el foro en el cual los activistas se presentan, se reclutan voluntarios, se pide consejo o se comentan las incidencias de cada proyecto.
La admisión es libre pero sólo acepta mensajes de personas suscritas. Esto elimina prácticamente todo el spam.
Recomendamos encarecidamente el uso de esta lista principal para los trabajos de traducción o escritura de manuales. En el caso de que sea obvio que el volumen de un proyecto exige una lista propia se habilitará una exclusiva a tal efecto.
La lista es archivada automáticamente y accesible por la web: http://listas.hispalinux.es/pipermail/lucas/. Para suscribirse basta usar este enlace mailto:lucas-request@listas.hispalinux.es?subject=subscribe.
3.2. Otras listas
Existen otras listas relacionadas en general con las actividades de TLDP-ES. A continuación presentamos las más interesantes.
http://listas.hispalinux.es/pipermail/lucas-anuncios , anuncios y novedades en TLDP-ES; de sólo lectura.
http://listas.hispalinux.es/pipermail/lucas-coord, lista interna de coordinación de TLDP-ES. Si necesitas un servicio de alguna clase o ayuda para un problema especialmente complicado escríbenos aquí.
http://listas.hispalinux.es/pipermail/lucas-desarrollo, el equivalente de TLDP-ES para la creación e integración de recursos lingüísticos: programas, bases de datos y demás herramientas software útil para perfeccionar el ciclo editorial.
http://listas.hispalinux.es/pipermail/lucas-voluntarios, es una lista donde se suscribe gente interesada en colaborar en trabajos y que se supone que está disponible para acudir a las llamadas a la participación de los editores/coordinadores.
http://listas.hispalinux.es/pipermail/lucas-actividad, de sólo lectura, donde se puede ver la actividad CVS de todos los proyectos contenidos en el repositorio.
3.3. Información de la página web
Aunque ya se dieron varias indicaciones sobre la página web en el punto 7 no está de más insistir en que esta página no tiene porqué incluir más información que:
Nombre y dirección-e del editor/coordinador;
Nombres de los colaboradores;
Estado de las asignaciones de los trabajos. Puede hacerse con una tabla tradicional o pueden aprovecharse las facilidades de Bugzilla. Esto es tan sencillo como hacer una búsqueda en bugzilla de los partes pendientes del proyecto y copiando la URL resultante como hipervínculo en nuestro documento. De esta forma cualquier visitante podrá saber qué trabajo está pendiente de realizar.
Además podemos añadir más enlaces que apunten a informes específicos de interés del proyecto.
Información sobre la licencia del documento e indicación de los permisos obtenidos, si es que eran necesarios.
3.4. Anuncios y novedades
Para dar a conocer la actividad y novedades de los proyectos tenemos configurado un sencillo pero interesante servicio automático que está integrado en nuestra web.
Por un lado tenemos el fichero novedades.conf en el que se añaden a mano las novedades. Es extremadamente fácil usarlo y al principio del mismo se explica completamente cómo usarlo.
Por otro lado tenemos los ficheros wml del índice y de la página de novedades. El primero publicará en la página principal del web los cinco últimos avisos y el segundo el fichero completo, a modo de histórico.
Finalmente tenemos un script automático que una vez a la semana examinará novedades.conf y creará una nota con las cinco noticias más recientes si y sólo si hay alguna novedad. Esta nota a su vez es enviada a varias listas de correo, entre ellas lucas y lucas-anuncios .
3.5. Glosario y consultas de terminología
Uno de los problemas más comunes en TLDP-ES es el resolver dudas sobre terminología y traducción. Se recomienda encarecidamente consultar estos recursos:
ORCA, el glosario de referencia usado por la mayoría de los proyectos de documentación libre en español.
diccionarios.com, un servicio web de consulta.
Ni qué decir tiene que tener en casa un buen diccionario nunca le hizo mal a nadie :-)
Ante una duda recomendamos consultar inmediatamente el DRAE u ORCA (según el caso). Si no encontramos una respuesta satisfactoria podemos consultar en la lista. Si se concluye una buena traducción a un término técnico (o sea, jerga), por favor, no deje de contribuir a ORCA con él.
3.6. Uso del CVS
Desde la coordinación de TLDP-ES insistimos mucho en el uso de esta herramienta. ¿Por qué es la panacea?:
porque su facilidad de control de versiones guarda un histórico completo de la evolución de los ficheros en el servidor, es decir, una copia de seguridad de cada versión de cada fichero durante todo el desarrollo del proyecto;
porque permite a todos los miembros de un equipo trabajar sobre un mismo conjuntos de ficheros y sobre los cambios de los demás con toda inmediatez;
porque si dos personas modifican un mismo fichero y se solapan los cambios, estos son detectados y puede resolverse el conflicto sin mayor problema;
porque permite acceder directamente a las configuraciones y ficheros relacionados con el proyecto en otras partes del cvs (como por ejemplo, su web);
porque permite a los coordinadores, revisores, tutores y demás voluntarios aportar mejoras y modificaciones inmediatamente, ofreciendo al coordinador control absoluto sobre quién, cuándo y cómo tuvieron lugar los cambios.
y finalmente porque desde el servidor cvs se hará la recompilación automática de las reproducciones y su publicación en la web así como la activación de otros automatismos que se planean para el futuro próximo;
Como también sabemos que hay que facilitar el aprendizaje, por muy corto que sea, hemos preparado un corto tutorial.
3.7. Uso de bugzilla
Bugzilla es otra de las panaceas que estamos incorporando al proyecto. Es una probadísima herramienta de gestión de partes (un subconjunto de las tareas de un «work-flow») que nos permite:
ahorrar tiempo al no tener que mantener el coordinador las tablas de asignaciones y estado de los trabajos y publicarlos en la web;
autoorganización del proyecto permitiendo que los voluntarios interesados se asignen a sí mismos trabajos pendientes o que ellos pueden resolver más rápidamente;
descubrir cuellos de botella en alguno de los voluntarios (debido a enfermedad, ausencia involuntaria, etc);
usarlo como archivo histórico del proyecto y conocer la evolución exacta del proyecto, etc.
En definitiva sirve para aliviar el trabajo de coordinación, favorecer el trabajo de los voluntarios y atraer a nuevos colaboradores.
Como no puede ser de otra forma, también hemos preparado la documentación que ayude a trabajar con esta herramienta en el menor tiempo posible.
Otro uso muy importante es para canalizar peticiones al equipo de coordinación sobre detalles o mejoras de los servicios de TLDP-ES. Esto se hace eligiendo el «producto» TLDP-ES y a continuación el «componente» relativo al asunto sobre el que formulamos la petición. Esta llegará hasta la persona más indicada que sabrá como atenderla.
3.7.1. Creando los primeros partes
Al empezar a usar Bugzilla en nuestro proyecto nos encontraremos con el muy probable problema de que no todos nuestros colaboradores tenga ya abierta su cuenta. Pero eso no es un obstáculo. Este es el procedimiento a seguir:
se crea un parte por cada capítulo y apéndice;
si en la lista de correo se han ofrecido voluntarios que no han creado aún su cuenta se las puede crear como si fueran la propia nuestra, solo que usando como datos su nombre y su dirección de correo-e; como ellos serán los que reciban la contraseña en su buzón no violaremos jamás su privacidad ni identidad;
se asignan los capítulos/partes a los traductores rellenando en la casilla de asignación con la dirección de correo-e del colaborador;
automáticamente bugzilla actualizará los listados e informará a cada voluntario de los trabajos que les han asignado.
A partir de ahí, cada autor debe aceptar el parte e indicar cuando se pone manos a la obra y todos los progresos que estime convenientes. Así estarán a vista los trabajos pendientes y alguno que acabe antes podrá empezar con trabajos que haya pendientes.
Igualmente el voluntario puede examinar los trabajos pendientes y asignarse a sí mismo los que le parezcan. En ese caso el coordinador, cuya identidad está asociada al «producto», recibirá los avisos correspondientes por correo-e.
3.8. Animación del proyecto
Esta parte es la menos técnica pero probablemente sea la más estratégica de todas. Si antes hemos hablado de orden, convenios y ahorro de tiempo y trabajo, ahora lo hacemos de calor humano, de «ingeniería social».
Recomendamos al coordinador que se relacione con su grupo como una fuente de cariño. Y no lo decimos en balde. El voluntario reacciona mucho mejor y se siente más feliz y realizado si el coordinador demuestra activamente su atención por él y por su trabajo y lo valora en su importancia, que lo es toda porque si no no tendríamos nada. Salvo excepciones enfermizas quien recibe cariño devuelve cariño y el grupo se siente más feliz, el trabajo se hace más llevadero y a veces ocurre que alguno de los colaboradores sobrepasa todas nuestras espectativas y se descubren como magníficos fichajes.
Otro punto importante es evitar la ocultación de la información. El hecho de que sugeramos tantas herramientas de trabajo en grupo es precisamente para evitar que ocurra esta ocultación de forma inconsciente. Si no se muestran todos los datos disponibles nos arriesgamos a perder oportunidades de que alguien, por el motivo que sea y cuando sea, pueda ayudar en el proyecto. Si se oculta información deliberadamente se perjudica siempre al grupo y al proyecto en último término.
Finalmente hay que decir que con frecuencia no todos los voluntarios tienen un dominio de todos los aspectos de la técnica necesarios, y estos van desde la informática más o menos avanzada hasta cuestiones de ortotipografía o lengua. El coordinador siempre será la primera persona que deberá ayudar en lo posible, pero debe contar con el resto de los miembros de la lista y del equipo de coordinación tan pronto como los necesite. Forma parte de nuestra estrategia de cariño el mimarnos y atendernos entre todos para pasarlo mejor y aprender más.