Yo y uno o más coautores, a veces distribuidos geográficamente, estamos trabajando en un conjunto de documentos relacionados. A veces haré un cambio en mi parte que afectará la parte de otra persona; esto podría ser cualquier cosa, desde cambiar un nombre hasta agregar un nuevo concepto (que las partes posteriores deberían usar o hacer referencia) a cambiar el escenario para un ejemplo en ejecución. Para cambios grandes, uno espera que todos hablemos primero, pero a veces surgen cambios más pequeños por los que no vale la pena convocar una reunión. ¿Cómo rastrea esas dependencias para no perderlas?
Las cosas que hemos probado incluyen:
Enviar correo electrónico. Fácil pero se puede perder.
Tenga un lugar central para dejar notas (documento compartido, página wiki, etc.). Esto funciona bastante bien si puede clasificarlo por quién/qué se ve afectado, de modo que cada persona tenga un solo lugar para buscar, pero puede ser un poco difícil de manejar si las dependencias son vagas o numerosas.
Use un sistema de seguimiento de errores: funciona si todos usan las mismas herramientas y a la gente que supervisa la base de datos de errores no les importa, pero no siempre es así.
¿Cuáles son mejores formas de gestionar el trabajo interconectado con los coautores?
Aclaración: estoy hablando de casos en los que realizo un cambio y luego otros tendrán que actualizar su trabajo, no de casos en los que yo mismo realizo todos los cambios relevantes.
Pueden trabajar juntos en el mismo documento con herramientas como Google docs, pero eso puede complicarse un poco con el tiempo si desea realizar un seguimiento de todos los cambios.
Para hacer que los cambios sean visibles (no estoy seguro de si eso es lo que quiere decir con "dependencias", pero supongo que sí) mi mejor apuesta es un sistema de control de fuente como lo están usando los programadores. Pero para aprovechar sus beneficios, debe almacenar su trabajo en un formato comparable.
Qué significa eso: herramientas como Subversion o Git almacenan su documento en una base de datos (central). Todo el mundo necesita acceso a esta base de datos (el acceso lo proporcionan las herramientas de control de código fuente). Si alguien cambia algo, el cambio se almacena (etiquetado con su nombre) en la base de datos/sistema de control de código fuente. También se puede comentar.
Si el formato del documento es legible por humanos (como txt o xml), entonces un programa diff (que muestra las diferencias entre dos archivos) puede mostrar los cambios entre las diferentes versiones del archivo. Sé que Subversion también puede hacer esto con el formato de documento de Word (que es un formato binario, es decir, no legible por humanos).
Entonces los cambios son directamente visibles. Información adicional (por qué hizo el cambio, por ejemplo) entre en el comentario.
TeX, los principios principales aún se aplican. Creo que el control de versiones junto con una herramienta de gestión de proyectos es lo que necesita.En orden descendente de utilidad, en mi opinión:
Software de seguimiento de proyectos/características/errores, para cambios de productos bien definidos. Imprescindible
Notificación por correo electrónico a otros escritores (transmisión) que hace referencia a las entradas en el n. ° 1 o a una entrada de wiki que describe el cambio de documento. El correo electrónico resume el contexto y cambia lo suficiente como para que otros escritores puedan saber si les afecta. La entrada wiki proporciona detalles. Las etiquetas wiki proporcionan organización/clasificación y facilitan la búsqueda/búsqueda. Las etiquetas pueden incluir nombres/números de proyectos, números de errores y otras cosas en el n.º 1.
Los comentarios incrustados en el documento pueden ayudar a señalar detalles y ubicaciones de algunos cambios en el documento. Los registros de cambios de control de fuente también pueden ayudar para esto, pero son de grano grueso.
El #1 es preferible, cuando se puede usar. Muchos cambios en la documentación reflejan cambios en el producto, incluidas correcciones de errores y nuevas funciones. Los cambios en la documentación para estos pueden/deben administrarse junto con los cambios en el resto del producto (la documentación es, por supuesto, parte del producto).
El n.º 2 complementa al n.º 1: es para cualquier cosa que no encaje en el n.º 1 y no es necesario que esté en el documento. Pero a menudo es posible que el n.° 2 haga referencia a cosas del n.° 1. Un ejemplo de contenido para el n.º 2 podría ser una reorganización de documentos, pero incluso entonces suele ser mejor crear un proyecto de producto para la reorganización, es decir, un proyecto de documentos, y realizar un seguimiento en el n.º 1.
# 3 puede ayudar a un escritor que visita el resultado de sus cambios más adelante. Puede señalar cosas que no son obvias y que son específicas de un contenido en particular, como buenos comentarios de código.
Los desarrolladores de software se ocupan de proyectos con millones de líneas de código y los proyectos de escritura colaborativa se ocupan de contenido del orden de miles o cientos de miles de líneas de texto. Creo que el enfoque de control de versiones utilizado para el desarrollo de software es increíblemente aplicable al proceso de escritura.
Como desarrollador de software, uso software de control de versiones de código fuente (SVN, GIT, etc.) para realizar un seguimiento de los cambios entre un gran conjunto de código en varios desarrolladores. He empezado a escribir un libro (en solitario) y he abordado el problema de gestionar miles de líneas narrativas con la misma técnica.
Estoy escribiendo mi manuscrito en un editor de texto glorificado (Bloc de notas ++) y esta solución solo puede aplicarse a este tipo de enfoque (en otras palabras, los documentos de Word serán desordenados).
Yo uso Unfuddle.com que tiene un "seguimiento de problemas" que puede ser útil para la comunicación entre colaboradores.
Creo que el componente más importante es que los contribuyentes proporcionen constantemente un número de referencia para un "problema" cuando guardan sus cambios. De esta manera, cuando observe el problema que está tratando, podrá ver todos los cambios relacionados en todo el documento.
Puede haber una curva de aprendizaje para que los colaboradores adopten algunas habilidades técnicas, pero dependiendo del tamaño del proyecto, creo que valdría la pena en la facilidad de administrar el trabajo.
Mónica Celio
Montag451
Mónica Celio