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.
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 un título podría ser «Crítica de la razón pura».
Consulta a la lista LuCAS 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.
Necesariamente debe tener una cuenta cvs en cvs.hispalinux.es.
Elección del nombre código para LuCAS.
Ese código suele ser alguna clase de acrónimo del título y es necesario para crear los directorios de publicación, la url del proyecto, el módulo CVS y la lista de correo, si es que se precisa. Por ejemplo «doc-critica-razon-pura».
Los tres primeros pasos los realiza el propio equipo de trabajo. Esta información es necesaria para los pasos siguientes.
Abrir 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 convenio doc-NOMBRECODIGO.
Se procura mantener un fichero LEAME.txt para identificar al proyecto y al coordinador del trabajo.
Este trabajo deberá hacerlo necesariamente alguno de los coordinadores de LuCAS.
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 LuCAS.
Este trabajo deberá hacerlo necesariamente alguno de los coordinadores de LuCAS 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 la web cuelgue de http://lucas.hispalinux.es, para favorecer el crecimiento de la comunidad de desarrolladores de documentación electrónica.
Es muy sencillo integrar una página HTML sencilla a este web. A día de hoy se usa la tecnología WML en el web de LuCAS. Se contempla seriamente la posibilidad de que en el futuro se use un sistema todavía más sencillo pero por ahora los coordinadores de los trabajos no deben preocuparse.
Para el nombre de los ficheros se recomienda el convenio proy-NOMBRECODIGO.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. Si el encargado de la página no se atreve a integrarla en el web LuCAS, a pesar de lo fácil que es, se la hace llegar a alguno de los coordinadores de LuCAS y él se encargará de hacerlo. Puede usarse como ejemplo cualquiera de los ficheros wml ya creados. A partir de ese momento los miembros del proyecto con acceso al cvs (osea, cualquiera) podrán mantener directamente esa página sin más rodeos.
El web LuCAS se actualiza automática y directamente desde el cvs a las 07:00, hora española.
Registro en la web LuCAS
Registrar al proyecto en las diferentes partes de LuCAS, en función de las características del trabajo.
En la página de proyectos, si es un proyecto con desarrollo activo.
Categorización en el menú principal, encartándolo en la sección más adecuada, si ya hay disponible para publicar alguna versión.
Este debe ser hecho o, mejor, supervisado por uno de los coordinadores de LuCAS, 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.
Se recomienda encarecidamente abrir un producto bugzilla para gestionar las tareas pendientes del proyecto. 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.
Se explicará la metodología usada y su justificación en otro documento.
Dado que el servidor bugzilla contiene productos de otros esfuerzos que no están directamente relacionados con LuCAS creemos conveniente usar una nomenclatura para distinguir rápidamente los productos de documentación de los que no y para simplificar la creación de informes bugzilla con vistas conjuntas de todas las tareas en curso: doc-NOMBRECODIGO.wml
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 LuCAS de las versiones finales.
4.- Errata, erratas en el documento.
Puede ser necesario abrir un componente Otros el resto de cuestiones no categorizadas arriba.
Este trabajo deberá hacerlo necesariamente alguno de los coordinadores de LuCAS.
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.
Recomendaciones y consejos para el desarrollo de proyectos de documentación en LuCAS y mejor aprovechamiento de los recursos disponibles.
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.
Existen otras listas relacionadas en general con las actividades de LuCAS. A continuación presentamos las más interesantes.
http://listas.hispalinux.es/pipermail/lucas-anuncios, anuncios y novedades en LuCAS; de sólo lectura.
http://listas.hispalinux.es/pipermail/lucas-coord, lista interna de coordinación de LuCAS. 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 LuCAS 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.
Aunque ya se dieron varias indicaciones sobre la página web en 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. Esto 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.
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.
Uno de los problemas más comunes en LuCAS 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 (osea, jerga), por favor, no dejes de contribuir a ORCA con él.
Desde la coordinación de LuCAS 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.
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 LuCAS. Esto se hace eligiendo el «producto» LuCAS 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.
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.
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.