Nuevas herramientas, nuevas capacidades
Herramientas como Google Docs y wikis realizan estas tareas relativamente bien para los procesos distribuidos y sincrónicos en los que el objetivo es tener un único documento resultante. ¿Pero cómo se colabora y coordina un documento para enfatizar y resaltar diferentes alternativas? ¿Cómo se pueden incorporar cambios asíncronos de gran tamaño? Por supuesto, es posible usar “Supervisar cambios” en MS Word y dejar que varias personas añadan sus comentarios y ediciones, pero sería realmente MENOS engorroso?
En lugar de esto, estoy imaginando lo que sería usar una plataforma como GitHub para aplicar las capacidades y experiencia de codificación colaborativa a otros empeños como el desarrollo de propuestas, poesía, diseño gráfico o realmente cualquier documento de colaboración. Si ha visitado alguna vez un hackathon u observado un proyecto de programación de código abierto, probablemente se habrá encontrado con GitHub. Es una de las principales plataformas que admiten la informática colaborativa en todo el mundo. Se basa en Git, que se desarrolló para admitir el mantenimiento y desarrollo del kernel del SO Linux. Es un sistema de control que gestiona sutiles diferencias de información entre las versiones del documento, y aunque los programadores lo han adoptado para una serie de proyectos, no existe ninguna razón por la que no se pueda implementar con una buena interfaz gráfica de usuario y diseñar para admitir el control de versiones y necesidades de coordinación de creación de documentos de colaboración en otros dominios como la literatura comparada, desarrollo de manuscritos científicos o propuestas de subvenciones de fundaciones.
No soy el primero en ver la oportunidad. Julie Meloni en la columna ProfHacker de Chronicle of Higher Education ofrece esta agradable y amable introducción al control de versiones para académicos adecuadamente titulado, Una amable introducción al control de versiones.
Una visión de esta descripción es que la interfaz de línea de comandos definitivamente tiene que reemplazarse por un sistema de control de usuarios gráfico intuitivo para el documento, historiales de revisión, comunidad de autores y cambios. Yo casi no recuerdo mi número de teléfono; no sé porqué los habituales programadores informáticos piensan que todos los demás tienen tiempo para recordar todos esos comandos de tareas de unos pocos minutos.
También está este gran comentario sobre el artículo de Meloni de Sean Gillies:
“Tras leer ayer un tweet de Dan Cohen que afirmaba que la erudición podría emular el desarrollo de software, me pregunto si el control de versiones distribuido no apunta a un futuro de la erudición que sea menos de ediciones y más de “diffs” or modificaciones”.
El escritor de ciencia ficción y periodista Cory Doctorow analiza el proceso de archivado y control de versiones mediante Git en su libro, Contexto: Nuevos ensayos escogidos sobre productividad, creatividad, paternidad y política en el siglo XXI. Describe su deseo de una herramienta que pueda capturar lo que ocurre mientras escribe, cuáles son sus influencias y pueda enlazarlo al propio documento -todo ello mientras se gestionan las diferentes versiones de sus manuscritos.
Pero en la era digital, muchos autores trabajan con un único archivo, modificándolo incrementalmente para cada revisión. No existen borradores distintivos e individuales, solamente un desplazamiento de cambios con un flujo continuo. Cuando se acaba el libro, desaparecen todos los pasos intermedios por los que pasa el manuscrito.
Se me ocurre que no hay ningún motivo por lo que esto tenga que ser así. Los ordenadores pueden recordar una inmensa cantidad de information sobre el historial de modificaciones de los archivos -de hecho, esa es la norma en el desarrollo de software, en el que los repositorios de código se utilizan para el seguimiento de cada cambio, anotando quién realizó los cambios, que cambió y cualquier anotación sobre el motivo del cambio.
Así que escribí a un amigo programador, Thomas Gideon, que lleva el excelente podcast Command Line (http://thecommandline.net), y le pregunté qué sistema de control de versiones recomendaría para mis proyectos de ficción -cuál sería el más fácil de automatizar para que cada par de minutos, compruebe si se ha actualizado alguno de los archivos maestros de mis novelas y, a continuación, registre los actualizados.
A Thomas le encantó la idea y la puso en marcha, creando un guión que usara el sistema de control de código abierto y libre “Git” (el sistema utilizado para mantener el kernel Linux), comprobando mi prosa en intervalos de 15 minutos, anotando con cada chequeo, la zona horaria actual de mi reloj del sistema (¿dónde estoy?), el clima de allí, recogido de Google (¿qué tiempo hace?) y los titulares de mis últimas tres publicaciones Boing Boing (¿qué estoy pensando?). Las futuras versiones admitirán complementos para capturar metadatos aún más informativos -por ejemplo los últimos tres tweets que he twiteado y las tres últimas canciones que ha reproducido mi reproductor de música.
Existe una edición en GitHub de Flashbake, el código de la herramienta basada en Git, que se puede descargar, manipular y añadir. Lo que hace bien Flashbake es agregar metainformación al flujo de escritura, capturando una pequeña instantánea de lo que ocurre. [esta es la página del proyecto original]
Gina Trapani, tiene una fantástica guía de introducción a Flashbake en Lifehacker, junto con un montón de pequeños fragmentos para ayudarle a decidir si merece la pena la curva de aprendizaje. Como ella dice, debe ser un poco audaz y no importarle ejecutar uno o dos guiones.
Diseño organizativo 1.0
Puede esperar más herramientas como Flashbake -que faciliten el almacenamiento en caché de cambios detallados en documentos y seleccionen entre múltiples hilos de dicho trabajo. Mi previsión es que serán la base de unas plataformas de colaboración de creación de texto de más fácil manejo en un futuro próximo, una vez que la creación colaborativa y el trabajo distribuido empiecen a ser más ampliamente utilizados.
Lo importante de Git y herramientas similares es que admiten una amplia gama de estructuras organizativas para hacer el trabajo. Queda fuera de mi conocimiento -comprender cómo las especificaciones técnicas admiten diferentes estilos organizativos- pero es obvio que Git y algunas otras herramientas de versiones admiten las formas de coordinación centralizadas, descentralizadas, jerárquicas, heterárquicas y de cualquier otro tipo. Lo que importa es el documento, los cambios que se realizan y cómo dichos cambios se aplican o aceptan en la última versión. Tirar, la capacidad de extraer de un repositorio maestro, y empujar, la capacidad de añadir a un repositorio maestro, son los dos permisos más importantes.
No es difícil imaginar escenarios en los que un equipo trabaja en el mismo documento, empezando por el contenido, editando, revisando, modificando para el desarrollo y corrigiendo copias, todo en momentos diferentes y lugares diferentes. Obviamente, debe existir el contenido básico antes de que comiencen las últimas fases de edición. Pero admite la edición simultánea de varias personas en las que algunos cambios se pueden aceptar y otros rechazar, pero no ediciones o versiones completas. Estas ediciones detalladas son importantes porque pueden significar que un grupo de autores pueda contribuir y que ninguna contribución es despreciable. Lo bueno es que diferentes personas puedan añadir una frase, y a continuación, a la hora de combinar las versiones, una pueda seleccionar cuál de las versiones de dichas frases se acepta para la versión final.
Para resumir, a continuación se enumeran algunas de las características finales del sistema de control de versiones distribuido:
- Un sistema de control de fuentes distribuido (como Git) significa que es fácil acceder a un repositorio central.
- Es posible recrear un proyecto a partir de cualquier copia, y ramificar un repositorio significa que los duplicados del trabajo pueden basarse y modificarse sin que afecte al original. Un comando difference (diff) permite comparar los cambios realizados entre las versiones del archivo.
- Uno puede trabajar totalmente desconectado en su repositorio local y subir los cambios al repositorio central más tarde.
- Los permisos se adecúan a las tareas y pueden adaptarse para diferentes organizaciones, equipos y funciones.
- Las contribuciones de los individuos forman otra capa “social” -por ejemplo seguir personas o hacer un seguimiento de su historial.
- El historial de cambios realizados en el repositorio es una medida de productividad. Además, el uso de una organization de archivos centralizada tiende a aumentar la productividad minimizando los costes de transacción de intercambiar archivos y notificar los cambios a los demás. La transparencia (quién aplica los cambios) también es una gran motivación para la participación y la productividad.
Implica algún esfuerzo poner en marcha algo como esto. Empezar realmente la coordinación colaborativa de documentos conlleva implicar a los demás, y eso significa crear las herramientas culturales para apoyar la práctica continua. No me cabe duda que un pequeño grupo de individuales dedicados podría hacerlo; muchos probablemente ya lo han hecho. Mi esperanza es que al escribir este artículo, las personas compartan más ejemplos de cómo Git y otros sistemas de versiones se están desarrollando como modelos para reimaginar la autoría colaborativa, la coordinación y el trabajo en otros dominios diferentes a la informática.
De Gabriel Harp en Blog Future Now
@gharp
THE INSTITUTE FOR THE FUTURE
Fuente
Nuevas herramientas, nuevas capacidades
Herramientas como Google Docs y wikis realizan estas tareas relativamente bien para los procesos distribuidos y sincrónicos en los que el objetivo es tener un único documento resultante. ¿Pero cómo se colabora y coordina un documento para enfatizar y resaltar diferentes alternativas? ¿Cómo se pueden incorporar cambios asíncronos de gran tamaño? Por supuesto, es posible usar “Supervisar cambios” en MS Word y dejar que varias personas añadan sus comentarios y ediciones, pero sería realmente MENOS engorroso?
En lugar de esto, estoy imaginando lo que sería usar una plataforma como GitHub para aplicar las capacidades y experiencia de codificación colaborativa a otros empeños como el desarrollo de propuestas, poesía, diseño gráfico o realmente cualquier documento de colaboración. Si ha visitado alguna vez un hackathon u observado un proyecto de programación de código abierto, probablemente se habrá encontrado con GitHub. Es una de las principales plataformas que admiten la informática colaborativa en todo el mundo. Se basa en Git, que se desarrolló para admitir el mantenimiento y desarrollo del kernel del SO Linux. Es un sistema de control que gestiona sutiles diferencias de información entre las versiones del documento, y aunque los programadores lo han adoptado para una serie de proyectos, no existe ninguna razón por la que no se pueda implementar con una buena interfaz gráfica de usuario y diseñar para admitir el control de versiones y necesidades de coordinación de creación de documentos de colaboración en otros dominios como la literatura comparada, desarrollo de manuscritos científicos o propuestas de subvenciones de fundaciones.
No soy el primero en ver la oportunidad. Julie Meloni en la columna ProfHacker de Chronicle of Higher Education ofrece esta agradable y amable introducción al control de versiones para académicos adecuadamente titulado, Una amable introducción al control de versiones.
Una visión de esta descripción es que la interfaz de línea de comandos definitivamente tiene que reemplazarse por un sistema de control de usuarios gráfico intuitivo para el documento, historiales de revisión, comunidad de autores y cambios. Yo casi no recuerdo mi número de teléfono; no sé porqué los habituales programadores informáticos piensan que todos los demás tienen tiempo para recordar todos esos comandos de tareas de unos pocos minutos.
También está este gran comentario sobre el artículo de Meloni de Sean Gillies:
“Tras leer ayer un tweet de Dan Cohen que afirmaba que la erudición podría emular el desarrollo de software, me pregunto si el control de versiones distribuido no apunta a un futuro de la erudición que sea menos de ediciones y más de “diffs” or modificaciones”.
El escritor de ciencia ficción y periodista Cory Doctorow analiza el proceso de archivado y control de versiones mediante Git en su libro, Contexto: Nuevos ensayos escogidos sobre productividad, creatividad, paternidad y política en el siglo XXI. Describe su deseo de una herramienta que pueda capturar lo que ocurre mientras escribe, cuáles son sus influencias y pueda enlazarlo al propio documento -todo ello mientras se gestionan las diferentes versiones de sus manuscritos.
Pero en la era digital, muchos autores trabajan con un único archivo, modificándolo incrementalmente para cada revisión. No existen borradores distintivos e individuales, solamente un desplazamiento de cambios con un flujo continuo. Cuando se acaba el libro, desaparecen todos los pasos intermedios por los que pasa el manuscrito.
Se me ocurre que no hay ningún motivo por lo que esto tenga que ser así. Los ordenadores pueden recordar una inmensa cantidad de information sobre el historial de modificaciones de los archivos -de hecho, esa es la norma en el desarrollo de software, en el que los repositorios de código se utilizan para el seguimiento de cada cambio, anotando quién realizó los cambios, que cambió y cualquier anotación sobre el motivo del cambio.
Así que escribí a un amigo programador, Thomas Gideon, que lleva el excelente podcast Command Line (http://thecommandline.net), y le pregunté qué sistema de control de versiones recomendaría para mis proyectos de ficción -cuál sería el más fácil de automatizar para que cada par de minutos, compruebe si se ha actualizado alguno de los archivos maestros de mis novelas y, a continuación, registre los actualizados.
A Thomas le encantó la idea y la puso en marcha, creando un guión que usara el sistema de control de código abierto y libre “Git” (el sistema utilizado para mantener el kernel Linux), comprobando mi prosa en intervalos de 15 minutos, anotando con cada chequeo, la zona horaria actual de mi reloj del sistema (¿dónde estoy?), el clima de allí, recogido de Google (¿qué tiempo hace?) y los titulares de mis últimas tres publicaciones Boing Boing (¿qué estoy pensando?). Las futuras versiones admitirán complementos para capturar metadatos aún más informativos -por ejemplo los últimos tres tweets que he twiteado y las tres últimas canciones que ha reproducido mi reproductor de música.
Existe una edición en GitHub de Flashbake, el código de la herramienta basada en Git, que se puede descargar, manipular y añadir. Lo que hace bien Flashbake es agregar metainformación al flujo de escritura, capturando una pequeña instantánea de lo que ocurre. [esta es la página del proyecto original]
Gina Trapani, tiene una fantástica guía de introducción a Flashbake en Lifehacker, junto con un montón de pequeños fragmentos para ayudarle a decidir si merece la pena la curva de aprendizaje. Como ella dice, debe ser un poco audaz y no importarle ejecutar uno o dos guiones.
Diseño organizativo 1.0
Puede esperar más herramientas como Flashbake -que faciliten el almacenamiento en caché de cambios detallados en documentos y seleccionen entre múltiples hilos de dicho trabajo. Mi previsión es que serán la base de unas plataformas de colaboración de creación de texto de más fácil manejo en un futuro próximo, una vez que la creación colaborativa y el trabajo distribuido empiecen a ser más ampliamente utilizados.
Lo importante de Git y herramientas similares es que admiten una amplia gama de estructuras organizativas para hacer el trabajo. Queda fuera de mi conocimiento -comprender cómo las especificaciones técnicas admiten diferentes estilos organizativos- pero es obvio que Git y algunas otras herramientas de versiones admiten las formas de coordinación centralizadas, descentralizadas, jerárquicas, heterárquicas y de cualquier otro tipo. Lo que importa es el documento, los cambios que se realizan y cómo dichos cambios se aplican o aceptan en la última versión. Tirar, la capacidad de extraer de un repositorio maestro, y empujar, la capacidad de añadir a un repositorio maestro, son los dos permisos más importantes.
No es difícil imaginar escenarios en los que un equipo trabaja en el mismo documento, empezando por el contenido, editando, revisando, modificando para el desarrollo y corrigiendo copias, todo en momentos diferentes y lugares diferentes. Obviamente, debe existir el contenido básico antes de que comiencen las últimas fases de edición. Pero admite la edición simultánea de varias personas en las que algunos cambios se pueden aceptar y otros rechazar, pero no ediciones o versiones completas. Estas ediciones detalladas son importantes porque pueden significar que un grupo de autores pueda contribuir y que ninguna contribución es despreciable. Lo bueno es que diferentes personas puedan añadir una frase, y a continuación, a la hora de combinar las versiones, una pueda seleccionar cuál de las versiones de dichas frases se acepta para la versión final.
Para resumir, a continuación se enumeran algunas de las características finales del sistema de control de versiones distribuido:
Implica algún esfuerzo poner en marcha algo como esto. Empezar realmente la coordinación colaborativa de documentos conlleva implicar a los demás, y eso significa crear las herramientas culturales para apoyar la práctica continua. No me cabe duda que un pequeño grupo de individuales dedicados podría hacerlo; muchos probablemente ya lo han hecho. Mi esperanza es que al escribir este artículo, las personas compartan más ejemplos de cómo Git y otros sistemas de versiones se están desarrollando como modelos para reimaginar la autoría colaborativa, la coordinación y el trabajo en otros dominios diferentes a la informática.
De Gabriel Harp en Blog Future Now
@gharp
THE INSTITUTE FOR THE FUTURE
Fuente
Compartir esto: