\chapter{Los prototipos: comunidades y artefactos entretegiéndose en el quehacer}\label{prototipos}

Los siguientes artefactos fueron creados en el contexto de Grafoscopio, 
pero habitan y dieron origen a un paquete complementario llamado {\ttfamily Dataviz}.
Además se usan para ilustrar lo que se puede crear con él durante los Data Week, pero
no todos son parte de los problemas abordados durante el mismo.
Las motivaciones y su funcionamiento ha sido ampliamente documentado en dos entradas
al blog (luna-med, luna-pp), bajo la premisa de una investigación doctoral interconectada, que excede los
límites y tiempos confinado dentro de la tesis doctotal y se comunica de maneras más
fluidas hacia afuera, en tiempos más cortos y lenguages menos formales.
Los textos acá son maneras complementarias de referirse a lo descrito en aquellos
documentos y para otros detalles una lectura de las entradas al blog.

\section{Visualizaciones de dominio específico para información sobre medicamentos}\label{infomed}

La primera visualización servía para apreciar ausencias o presencias de información,
en particular en medicamentos.
Precisamente se trataba de lidiar con un problema metodológico (no encontrar información)
convirtiéndolo en uno investigativo: ¿cómo comparar las ausencias y presencias de información
respecto a medicamentos?


\begin{figure*}[tbp]
	\centering
	\subfloat[Visualización de derechos de los homosexuales, en \emph{The Guardian}.]{
		\includegraphics[width=0.5\linewidth]{./Parte2/gay-rights-infography.png}
		\label{subfig:derechos-homosexuales}
	}
	\subfloat[Omeoprazol, datos administrativos por país.]{
		\includegraphics[width=0.5\linewidth]{./Parte2/omeprazol-admin-by-country.png}
		\label{subfig:omeoprazol-country}
	}
	\\
	\subfloat[Omeoprazol, datos de propiedades por país.]{
		\includegraphics[width=0.5\linewidth]{./Parte2/omeprazol-by-property.png}
		\label{subfig:omeoprazol-admin}
	}
	\subfloat[Omeoprazol, datos de prescripción y uso por país.]{
		\includegraphics[width=0.5\linewidth]{./Parte2/omeprazol-pu-by-country.png}
		\label{subfig:omeoprazol-pu-country}
	}
	\caption[Gráfica de ausencia de información sobre medicamentos]
	{\ref{subfig:derechos-homosexuales} Visualización de los derechos homosexuales por \emph{The Guardian}, 
		que sirvió como modelo para las visualizaciones sobre ausencia de información sobre
		medicamentos del paquete Dataviz en Grafoscopio y las 3 visualizaciones a la medida, 
		a partir de dicha gráfica mostradas en la figuras \ref{subfig:omeoprazol-country},
		\ref{subfig:omeoprazol-admin} y \ref{subfig:omeoprazol-pu-country}.
		Los detalles sobre las mismas y cómo interpretarlas están en Gil-2015.
		La historia de como surgieron se detalla en Luna-2016-Infomed.}
	\label{fig:infomed-visuals}
\end{figure*}

Acá el enfasis no estuvo en la documentación interactiva, sino en la visualización de Datos,
por tanto se colocó lo desarrollado en un paquete independiente que tuviera una galería de problemas 
que pueden ser abordados con Grafoscopio, llamado {\ttfamily Dataviz}.
Esto fortaleció la necesidad de dicho paquete y mejoró la modularidad del software.
Algunas veces estaríamos enfocados en la documentación y otras veces el énfasis sería la
visualización, aunque se esperaba que, en la medida en que Grafoscopio, y sus paquetes asociados
madurarán, las prácticas comunitarias vincularan documentación con visualización de maneras más
continuas y fluidas.

\begin{figure*}[tbh]
	\centering
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/roassal-sunburst-examples-2.png}
		\label{subfig:roassal-sunburst}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/matriz-a-arbol.png}
		\label{subfig:matriz-arbol}}
	\caption[Adaptando Roassal]
	{Dos adaptaciones hechas al software de visualización, incluidas con
		Grafoscopio y su paquete Dataviz, para crear las imágenes en la figura \ref{fig:infomed-visuals}.
		A la izquierda visualización base para información jerárquica en lugar de matricial.
		A la derecha, ilustración de la transformación de información matricial en jerárquica
		para adaptarla a la nueva visualización. 
		Tomadas de Luna-2016-infomed.}
	\label{fig:roassal-infomed}
\end{figure*}

La descripción detallada de este problema y su análisis están en Gil 2015.
Acá se mencionarán los hitos de este abordaje, que complementan el texto del blog:

\begin{itemize}
	\item Pasar de \emph{tener la información} como lugar de inicio, a \emph{usar su ausencia} 
		como lugar problémico e investigativo.
	\item Se partió de una visualización base de \emph{The Guardian}, respecto a ausencias
		y presencias, en este caso de derechos en la población homosexual, como modelo del tipo
		de visualización que se quería (veáse figuras tales y pascuales).
	\item Se adaptó una visualización preexistente, que era para información jerárquica, 
		de modo que permitiera trabajar con la información recolectada, que era de naturaleza
		tabular.
		Se hizo un algoritmo de conversión de formato tabular a jerárquico y se creó un Lenguaje
		de Dominio Específico (DSL, por sus siglas en inglés) para hablar del problema en cuestión.
	\item Yaneth Gil participó de la visualización como experta de dominio, indicando qué quería ver,
		qué formatos tenían los datos, parámetros estéticos de las visualizaciones e incluso haciendo
		comentarios sobre los algoritmos implementados en Smalltalk, si bien no programaba este lenguaje.
		Yo comentaba qué se podía implementar, forzaba el entorno y mi conocimiento para lograr algunas
		de sus visualizaciones, y establecimos un sistema de convenciones \emph{ad-hoc} para poder 
		hacerle consultas a los datos.
		Se produjo, así, una negociación entre mi rol como visualizador/programador y el de ella como 
		experta de dominio.
	\item La solución fue implementada de manera ágil aunque poco elegante. 
		Habían muchos parámetros en los mensajes del DSL y no se usaba la infraestructura de
		\emph{builders}, que permitía abstraer el problema y generar visualizaciones sin
		transformaciones de datos y el uso de convenciones \emph{ad-hoc}, que facilitaran su visualización
		y consulta.
		Aún así fue funcional y dio cuenta de los tiempos estrechos para la implementación.	
	\item En las distintas implementaciones, tanto de la solución rápida, como de las más elegante, 
		se contó con la ayuda de la comunidad de Pharo, particularmente de Miltón Mamani, primero
		en un encuentro en Argentina, de la comunidad de Smalltalk, luego de manera remota por chat
		y finalmente durante mi pasantía doctoral en Chile.
		El uso de soluciones cada vez más formales tuvo que ver con mi comprensión progresiva
		del problema, el motor de visualización y sus constructos y maneras más acertivas de 
		participar en la comunidad, pues desde el comienzo Miltón estaba ofreciéndome soluciones
		formales (construyendo \emph{builders}), pero yo no tenía los preconceptos adecuados para
		aprenderlos y quería continuar con lo que ya tenía y sacar un prototipo funcional desde
		lo que ya entendía.
		Esto a su vez fortaleció la motivación para crear en los \emph{Data Weeks} caminos de
		aprendizaje que facilitaran los recorridos para otros novatos, a partir de mis errores y rutas,
		pero sin tener que repetirlas.
		Algunos \emph{builders} y problemas pre-tratados ayudarían a futuros aprendices, 
		a enfocarse en lo conceptual y crear código más suscinto, comprensible y elegante.
\end{itemize}

\section{Panamá Papers: investigación reproducible y activismo de datos incluyente}\label{panama-papers}



Otro proyecto realizado durante la pasantía doctoral en Chile fue el de los \emph{Panama Papers}.
(luna 2016-pp).
En este periodo, además se mejoraron las visualizaciones de de medicamentos vía \emph{builders}
y también la interfaz gráfica de Grafoscopio empleando el puente entre el \emph{framework} de 
Spec y las herramientas adaptables \emph{GT Tools} del proyecto Moose, desarrollado por
Johan Fabri y con su acompañamiento.

\begin{figure*}[tbh]
	\centering
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/Countries_implicated_in_the_Panama_Papers.png}
		\label{subfig:pp-wikipedia}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/choropleth.png}
		\label{subfig:pp-choropleth}}
	\caption[Historia de dos mapas sobre los \emph{Panama Papers}]
	{Dos mapas sobre los paraisos fiscales. 
		La de la izquierda, tomada de la Wikipedia, es irreproducible a partir de los datos publicados. 
		La de la derecha, hecha por el autor, es reproducible y el entorno que la crea y contiene,
		incluido el micrositio web, cabe en una memoria USB y se puede ejecutar en un computador modesto.}
	\label{fig:pp-dos-mapas}
\end{figure*}

Se iniciaba con dos mapas referidos a los \emph{Panamá Papers} y se mostraba que uno de ellos 
(el de la Wikipedia) era irreproducible y el otro, desarrollado en Grafoscopio y el Dataviz,
si lo era.
A partir de ello se introducía un micrositio y un entorno portable para explorar el segundo mapa 
y sus los datos, aproximándose críticamente a la idea de \emph{Big Data},
mostrando que los datos curados y el entorno para trabajar con ellos podía ejecutarse en
una memoria USB y computadores modestos, de modo que las argumentaciones e historias basadas 
en tales datos fueran más participativas e incluyentes.

\begin{figure*}[tbp]
	\centering
	\includegraphics[width=\linewidth]{./Parte2/minisite.png}%
	\caption{Minisitio desarrollado para el proyecto de los \emph{Panamá Papers}.}%
	\label{fig:pp-minisitio}%
\end{figure*}

Los hitos más importantes para el desarollo del proyecto de los \emph{Panama Papers} fueron:

\begin{itemize}
	\item 
	Se hizo un viraje de la idea de \emph{Big Data} a \emph{Frictionless Data} e
	\emph{infraestructuras de bolsillo}, en aras de alentar la puralidad y la participación
	de lectures y ciudadanos en fenómenos complejos mediados por datos y de escala global, 
	como los paraisos fiscales.
	La elección del tema no sólo tenía que ver con su popularidad, sino con el abordaje
	crítico tanto de los datos como de las temáticas: hacer accesible la manera en que los
	poderosos guardan su capital, es una manera de pensar el caracter no neutral de los
	datos y la información.
	
	Se trataba de mirar, entonces, si se podía abordar la filtración noticiosa con el conjunto 
	de datos (\emph{dataset}) más grande de la historia con infraestructuras sencillas y
	al alcance de más personas, una vez los datos han sido curados y liberados.
	\item
	La visualización que se quería hacer era sencilla y si los territorios estuvieran completos, 
	hubiera salido en minutos, literalmente, pero fue el completar la información y curarla lo que
	tomó más tiempo.
	Enfrentado a esta dificultad, un programador me sugirió que colocara en la gráfica 
	"los paises más importantes", para resolver rápidamente el problema.
	Cuando se detectó el problema con los SVG, antes mencionado, el proyecto cobró un nuevo
	interés desde el punto de vista de lo algorítmico y el desarrollo de software. 
	Esto reveló una tensión del activismo de datos al estar entre dos mundos: los periodistas
	quieren veracidad y no se preocupan por errores (o \emph{bugs}, como son llamados en la jerga
	computacional) como el de los importadores del SVG. 
	Los programadores consideran que curar la información es un trabajo al que no debería 
	dedicársele mucho tiempo.
	La necesidad de un grupo de personas en la mitad, que pueda hacer puente entre estas
	dos preocupaciones y dedicarse a ellas es, por tanto, más importante.
	\item
	El aspecto más dispendioso fue completar y curar la información.
	El mapa mundi provisto por el motor de visualización Roassal, no incluía tantos territorios
	como los mencionados en los \emph{Panama Papers} (faltaba cerca de un tercio de ellos),
	por lo cual algunos datos fueron completados a mano al comienzo y cuando la estrategia mostró
	sus limitaciones, al generar errores de integración con los territorios pre-existentes, 
	pues las coordenadas no coincidían (véase figura tal),
	se implementó un algoritmo que resolvía el inconveniente haciendo importaciones de mapa mundis
	más completos y con sistemas de coordenadas consistentes.
	Esto a su vez permitió detectar y corregir un error el algoritmo de importación de gráficos
	vectoriales escalables (SVG, por sus siglas en inglés) y hacer un aporte al núcleo de Roassal.
	
	\begin{figure*}[h]
		\includegraphics[width=3.5in]{./Parte2/pp-intro-notebook.png}%
		\includegraphics[width=2.5in]{./Parte2/pp-query-data-environment.png} %
		\caption[Panama Papers: Libreta interactiva y código]
		{Izquierda: Libreta interactiva en Grafoscopio de los \emph{Panama Papers}.
			Derecha: Consulta a la base de datos y lenguaje de dominio específico integrados 
			dentro del entorno.
		}
		\label{fig:pp-libreta-y-consulta}%
	\end{figure*}
	
	\item
	Uno de los aspectos claves fue la trazabilidad de la información y se desarrollo la idea
	de un \emph{entorno vivo continuo de datos} (\emph{Data continuum [live] environment})
	\footnote{Si bien en el texto original no se hablaba del caracter vivo del entorno,
		este fue clave en la exploración de los datos, no sólo en este ejercicio/prototipo,
		sino en los demás de los que se habla en esta investigación, como fue resaltado en
		la entrada al blog sobre la visualización de medicamentos.}, 
	que establecía puentes entre los datos, las consultas, las visualizaciones y los documentos,
	permitiendo pasar de los unos a los otros 
	(véanse figuras \ref{fig:pp-libreta-y-consulta} y \ref{fig:pp-workflow}).
	La premisa era que, una vez se publicaban estas narrativas y visualizaciones de datos,
	\begin{quote}
		El lector podía convertirse en explorador/co-autor en el \emph{mismo entorno continuo completo}
		que el autor había usado para crear la visualización de datos publicada, con un sencillo
		click de arranque.
	\end{quote}
	
	\begin{figure*}[tbp]
		\includegraphics[width=\linewidth]{./Parte2/process.png}%
		\caption[Flujo de trabajo para el proyecto de los \emph{Panama Papers}]
		{Flujo de trabajo para la creación de la visualización de los \emph{Panama Papers} 
			y sus publicaciones de soporte (minisitio y entrada al blog). 
			Los círculos representan los entornos donde se realizan actividades asociadas a los datos, 
			representadas por rectángulos. 
			Se puede apreciar como Grafoscopio, a través de la documentación interactiva,
			es el puente entre la exploración y visualización de los datos y su publicación.
			Este flujo de trabajo con entornos y actividades fue prototipado como parte de la
			pasantía doctoral.
			Tomado de Luna-2016-pp. }%
		\label{fig:pp-workflow}%
	\end{figure*}		 
	\item
	Se proveyeron imágenes descargables para Windows y Mac que permitían probar el prototipo y 
	reportar errores, aunque las únicas pruebas y reportes provinieron de colaboradores cercanos
	al proyecto y otras personas contactadas vía Twitter y la lista de la \emph{Open Knowledge Fundation}
	no manifestaron mayor interés en el proyecto (salvo uno de ellos).
	\item
	Al final de la pasantía, con la ayuda de Alejandro XX, logró empaquetarse Grafoscopio,
	usando el sistema de gestión de paquetes y dependencias, Monticello, lo cual mejoraría
	el proceso de instalación en las versiones venideras del \emph{Data Week} y la facilitaría
	para otros autores/exploradores de datos, que lo usaran a futuro.
\end{itemize}

%NOTE: Twitter Data Selfies

La necesidad de una comunidad particular de personas interesadas en la visualización 
y narrativas de datos, con preocupaciones tanto por la técnica y como por la historia,
había sido detectada previamente.
\footnote{Para mi pasantía en Chile, ya llevaba 3 ediciones del \emph{Data Week} realizadas 
	y haría 5 ediciones más a mi regreso}.
Esta nueva comunidad de práctica, no surgiría en el grueso de los miembros de la 
comunidad nuclear de HackBo, pues los intereses por otras apuestas, tecnologías y miradas ya se 
había hecho claro en los primeros años, viendo los artefactos y prototipos construidos.
Los caminos de aprendizaje que habían recorrido los miembros del espacio y que los habían llevado
a sus experticias particulares eran muy específicos y extra curriculares y las charlas y talleres
eran esporádicos y suponían públicos relativamente expertos en programación o con intereses
por desarrollarse en temas como la electrónica y la computación física, pero principalmente niños 
y jóvenes, sin la edad suficiente para un compromiso crítico y sostenido, como lo muestra la programación
de actividades en el \emph{hackerspace}.
A su vez la \emph{Gobernatón} había mostrado el interés por estos temas críticos y de activismo, 
pero también la necesidad de crear capacidad entre los asistentes de manera que un
número mayor pudiera expresar sus ideas a través de la técnica y los artefactos digitales,
sin entrar en las lógicas instrumentales y de "cadena de montaje" en la cual los programadores
eran vistos como aquellos que podían implementar las ideas de otros pero sin preocupaciones 
propias que expresar a través de la técnica.
El diseño de un espacio, que recibiera a novatos y donde los lugares comunes y del quehacer 
fueran ensanchados, se empezó a hacer evidente, como resultado de la Gobernatón la participación
en otras hackatones (como la de Chicas Poderosas y en la Universidad de los Andes) (véase Luna XY).
El código sería el material para explicitar, negociar, construir y catalizar esos saberes comunes,
desde los cuales podrían ponerse a conversar otros saberes y miradas.
Allí surgió el \emph{Data Week} (capítulo \ref{dataweek}).

\section{Abriendo el Manual de Periodismo de Datos}\label{mapeda}

El Manual de Periodismo de Datos, la versión de código abierto fue el resultado de sucesivas 
Data Rodas.
Surgió como una respuesta a una convocatoria lanzada por los autores de la primera versión,
por renovar sus contenidos.
Dicha convocatoria tenía unos plazos y un formulario de preinscripción en el cual se seleccionaba
a quienes serían finalmente los participantes del proyecto.
La llamada, al interior de la comunidad de Grafoscopio, fue a realizar un proyecto, en el marco
de la convocatoria y dentro de sus plazos, que abriera de manera definitiva las formas
de participación aprovechando las dinámicas de co-creación de contenidos y software propia de
las comunidades hacker y de cultura libre.
Para ello, necesitaríamos transformar de formato la versión publicada del Manual, que ya
estaba en formato HTML, a un documento de Grafoscopio.
Dicha transformación pasaría por una serie de automatismos, que serían incorporados a Grafoscopio
de manera que tareas similares fueran mucho más sencillas.
La intensión crear un árbol con la misma tabla de contenido del Manual (que de por sí ya tiene una
estructura arbórea, como la mayoria de los libros) e indicar a través de los enlaces en los
nodos de dicho árbol, qué dirección web contenía la versión HTML del contenido correspondiente
a dicho capítulo.
Luego se haría que los contenidos fuera importados desde la web hacia la libreta interactiva
y transformados de HTML a Markdown de Pandoc, con lo cual contaríamos con la representación
del Manual en un formato que permitiese múltiples representaciones concentrándonos originalmente
en la versión en PDF (por la cual había que pagar hasta el momento) y luego, por solicitud de
uno de los miembros de la comunidad, en la versión EPUB, para ser leída desde dispositivos
móviles, como celulares y tabletas.

\begin{figure*}[tbh]
	\centering
	\subfloat[]{
		\includegraphics[width=0.4\linewidth]{./Parte2/mapeda-original.png}
		\label{subfig:mapeda-original}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.5\linewidth]{./Parte2/mapeda-ston.png}
		\label{subfig:mapeda-ston}}
	\caption[Dos versiones del Manual de Periodismo de Datos]
	{Dos versiones del Manual de Periodismo de Datos.
		A la izquierda, la publicada originalmente en la web.
		A la derecha, la misma estructura arbórea, expresada como un documento de Grafoscopio.
		Cada nodo del árbol apunta al lugar donde estaba originalmente el documento web y la
		importación y transformación de contneidos se hace automáticamente des HTML hacia el
		Markdown de Pandoc, de modo que luego pueda ser transformada a múltiples formatos.}
	\label{fig:mapeda}
\end{figure*}


Se trataba de pasar de una versión cuyo código fuente y maneras de participación eran cerradas,
y sometidas a plazos, formularios y fuentes cerrados a unos más abiertos y permanentes.
Como se dijo en la introducción a la versión abierta del Manual (Luna XYZ):

\begin{quote}
	Existen interesantes obras culturales libres, que lo son de manera nominal, en la teoría,
	pero que no lo son en la práctica. Esto quiere decir que, a pesar de tener una licencia
	bastante liberal, que permite su remezcla, modificación e incluso venta, las infraestructuras 
	que soportan la creación y publicación de dichas obras, no permiten amplia
	participación, ni tampoco la trazabilidad de la historia respecto a dichos procesos participativos 
	y colaborativos. Dicho de una manera más técnica: su código fuente no está
	abierto, las herramientas con las que se hicieron no son de software libre y no cuentan
	con repositorios públicos para gestionar dicho código.

	Esta no es una paradoja mejor: al licenciar las obras de manera que se aliente su tránsito
	y modificación, se está haciendo una invitación abierta. Pero al dejar invisibles las
	infraestructuras que efectivamente permiten a otros participar, se dificulta a todos
	aceptar dicha invitación. Esto pasa de manera generalizada con muchas fundaciones y
	colectivos que abren sus obras, pero no nos muestran el código fuente de las mismas,
	ni los lugares y formas donde apropiarnos del mismo y aportar a ellas. Es como si
	dijéramos que hemos organizado una fiesta en la playa y que todo el mundo puede
	ir, que habrá una dotación inicial de la música, bebidas y alimentos, y que estamos
	esperando hacer algo mucho mejor con los aportes de los demás. La fiesta será una
	creación colectiva potente. El único problema es que olvidamos decirle a la gente cómo
	llegar y es más, no pensamos en los que irían en bicicleta o a pie, sólo se puede llegar
	en vehículo motorizado. A la generosidad inicial, que sin duda agradecemos, la afecta
	la invisible infraestructura. Así que, aprovechando las libertades que ofrece la obra,
	hemos tomado una postura proactiva y abierto la creación a muchas más personas,
	ocupándonos de la infraestructura.

	La nuestra es propuesta sobre una manera alternativa de crear colectivamente dichas
	obras libres, abordando el problema de la partipación y para ello hemos usando, como
	ejemplo, el Manual de Periodismo de Datos acá presente. Considerar a los de bicicleta
	y los de a pie, con hardware modesto y conectividad intermitente, como ocurre en
	el llamado Sur Global y la amplia latinoamérica, ha implicado optar por lo que yo
	llamo \emph{infraestructuras de bolsillo}, que se caracterizan por ser sencillas, auto-contenidas, 
	y funcionar bien en o fuera de línea, tales como \href{http://mutabit.com/grafoscopio/}{Grafoscopio} 
	y \href{http://fossil-scm.org/}{Fossil}.
\end{quote}

Fue así como se dispuso un repositorio de código en Fossil, que hospedaría el código fuente
del Manual, así como sus versiones terminadas en PDF y EPUB.
Fue acá cuando empezamos a experimentar más abiertamente con permisos en los repositorios de código, 
de manera que pudiéramos trabajar colaborativamente sobre documentos más durables y explorar
las transiciones de usuarios de Grafoscopio a autores de obras colectivas creadas en este,
lo cual marcó un interesante contraste con los proyectos de Data Weeks y Data Rodas previas,
pues en este se tenía un objetivo menos explorativo y más claro (la apertura del manual),
así como un conjunto de tiempos definidos y cerrados (antes de que terminara la convocatoria).
En las lecturas posteriores sobre este cambio en la dinámica se dijo que acá había un claro
``llamado a la acción'', configurado a través de estas dos condiciones.
Además, estábamos enfrentándonos a una mediación cultural más conocida, un libro, en lugar de
una visualización de datos, que requiere incorporar un conjunto de alfabetismos y experticias
nuevas, además de la del código, que siguió siendo parte de esta exploración, pues a través
del código se moficaban las funcionalidades de Grafoscopio para adaptarlo a la tarea de apertura
del Manual.

\begin{figure}[tbh]
	\centering
	\includegraphics[width=\linewidth]{./Parte2/mapeda-web.png}
	\caption[Repositorio del Manual de Periodismo de Datos: portada]
	{Portada del repositorio del Manual de Periodismo de Datos, disponible en \url{https://is.gd/mapeda}.}
	\label{fig:mapeda-portada}
\end{figure}

Las materialidades que mediaban esta experiencia también estaban en constante diálogo con las 
dinámicas comunitarias y eran mucho más plurares, comparadas con los dos proyectos anteriores,
que fueron hechos con una experta de dominio para los medicamentos (Yaneth Gil) o de manera 
relativamente solitaria en la pasantía, para el caso de los Panamá Papers (aunque con las ayudas 
antes mencionadas).
Por ejemplo, el uso de Fossil y la documentación sobre éste, se volvió una necesidad explícita 
para los aportes colectivos a la apertura del Manual.
La línea de tiempo en la figura \ref{subfig:mapeda-timeline} muestra el inicio de las dinámicas
de bifurcación y recombinación del trabajo, propia de esos quehaceres colectivos, que luego
sería extendidas en los talleres de información crítica, dictados en la Javeriana, así como los
Data Weeks y Data Rodas venideros.
A lo largo de dicha línea de tiempo\footnote{\url{https://is.gd/mapeda_timeline1}} es posible ver 
diferentes autores que contribuyen a las mismas, particularmente al inicio, que se van disipando 
hacia el final, constituyéndose en más pocos autores, Gloria y yo, que depuramos la parte referida 
al manejo de imágenes hasta quedar sólo yo, con las partes referidas al maquetado del texto, la redacción 
del prólogo y las correcciones menores.
(Dinámicas como éstas son estudiadas en mayor detalle en el capítulo \ref{dataviz-infra}.)

\begin{figure}[tb]
	\centering
	\subfloat[]{
		\includegraphics[angle=90, width=\linewidth]{./Parte2/mapeda-timeline.png}
		\label{subfig:mapeda-timeline}}
	\\
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/mapeda-timeline-end.png}
		\label{subfig:mapeda-timeline-end}}
		\subfloat[]{
			\includegraphics[width=0.45\linewidth]{./Parte2/mapeda-timeline-detail.png}
			\label{subfig:mapeda-timeline-begin}}
	\caption[Repositorio del Manual de Periodismo de Datos: línea de tiempo]
	{Línea de tiempo del repositorio del Manual de Periodismo de Datos, disponible en
		 \url{https://is.gd/mapeda_timeline1}.
		 Arriba,\ref{subfig:mapeda-timeline} rotado para verla en su totalidad, la línea completa.
		 Abajo izquierda \ref{subfig:mapeda-timeline-end}, el final de la línea de tiempo, caracterizada
		 por un trabajo en solitario.
		 Abajo derecha  \ref{subfig:mapeda-timeline-begin}, el comienzo de la línea de tiempo, donde se
		 aprecian varios autores, bifurcaciones y recombinaciones.}
	\label{fig:mapeda-repo}
\end{figure}

Si bien no se abordó el tema de los lenguajes de etiquetamiento ligero en detalle, a pesar
de usar Markdown para el proyecto, el hecho de que trabajáramos con un libro permitió
un mejor reparto de actividades al comienzo, usando la consola de comandos y conversiones entre
formatos manuales, y luego limpiando el resultado, que progresivamente se fue especializando 
hasta tratar con asuntos referidos a la automatización de tareas sobre cómo se importarían
los contenidos de Internet y se convertirían entre formatos, incorporando así la sugerencia
de dos participantes con mayor conocimiento sobre código.
Para tales temas avanzados, de nuevo recurrimos a la forma de programación en multitud
(\emph{mob programming}) que habíamos empleado en previos Data Weeks, de modo que los
novatos y no programadores pudieran apreciar cómo ocurría la escritura de código por los
más expertos e incluso aportar ideas entre todos sobre las ideas encarnadas en éste.

El espíritu crítico se evidenció de nuevo a lo largo de la sesión, particularmente
en las charlas que teníamos después de los encuentros, mientras caminábamos acompañando
a quienes vivían cerca, sobre quiénes eran los beneficiaros de este esfuerzo, (mencionados
en las lecturas sobre la lista de correo), pero también en la idea de automatizar labores
repetitivas manuales vía código y extendiendo Grafoscopio, así como tiempo despúes, cuando
se compartía a través de la lista otro conjunto de esfuerzos conexos sobre edición 
ramificada\footnote{\url{https://is.gd/ramificada}}, que también consideraban el mundo editorial 
desde una perspectiva política y cuyas búsquedas y técnicas ocurrían desde otros lugares de 
Latinoamérica (específicament México) con similitudes sorprendentes, a pesar de que consideraban 
el activismo en el mundo editoral y no el de los datos, entre ellas: el uso de los mismos 
lenguajes de etiquetamiento ligeros (Markdown y Pandoc), la crítica al procesador de palabras 
y otros software comerciales, el hecho de que la lectura y escritura ahora se hace desde 
y para dispositivos multi-pantalla (computadores, tabletas).
Con aprendizajes que perdurarían y se consolidarían en esta práctica de escritura y otras
venideras (váse sección \ref{bidibog}).

La automatización para las tareas de apertura del Manual implicó el uso de lenguajes externos
a Pharo, particularmente Lua\footnote{\url{https://www.lua.org/}}, que ya viene incluido en Pandoc, 
de modo que las ideas de los participantes se pudieran implementar de maneras más elegantes.
También fuimos asignando permisos en el repositorio de código de Grafoscopio, (no sólo en el 
de documentación del Manual), de modo que los ejercicios de programación en multitud antes
referidos fueran registrados en dicho repositorio por múltiples participantes, reconociendo
sus aportes y mejorando las contribuciones hechas por ellos.
Sin embargo, tanto en los repositorios de software, como en los de documentación, los
aportes fueron realizados durante los eventos y se volvieron individuales luego de los mismos.
Otras formas de contribución se sostuvieron luego del evento, por un grupo pequeño de participantes,
(comparado con el total de inscritos en la lista de correo o la de telegram, pero consecuente con el
número de personas que asistían a las Data Rodas) además de las conversaciones sobre edición ramificada, 
como entradas a blog\footnote{\url{https://is.gd/mapeda_blog}}, conversaciones en Telegram 
o por la lista al respecto de dicha actividad.
Otros miembro de la comunidad de Grafoscopio sugirió e implementó la propuesta de un Club de 
Lectura para el Manual\footnote{\url{https://is.gd/mapeda_club}} usando el sistema de lectura 
anota vía Hypothesis, al que ya se ha hecho mención.
Sin embargo, dicha lectura anotada en el club es aún un asunto pendiente en la comunidad,
para esta y otras iniciativas.



Se dispuso una página de portada para el repositorio, que mostraba las diferentes variantes
del Manual (PDF, EPUB, código fuente en Grafoscopio y Markdown) y la inspiración detrás del proyecto, 
las entradas a blog de un miembros de la comunidad y se dispuso esta información en inglés y en
español

A su vez se socializaron los resultados con personas vinculadas a la edición original del Manual,
refiriéndonos a los usuarios de Twitter (autores y periódicos) que aparecían en las páginas originales
de la obra, pero ninguno contestó.
También conversamos de ello en otras listas de correo de Big Data from the South y HackBo,
y en el cana de Telegram del laboratorio de Datos de Medialab El Prado, obteniendo algunas
felicitaciones.
Esto nos lleva a la conversación sobre los públicos y beneficiarios de este tipo de ejercicios
antes mencionada\footnote{\url{https://is.gd/mapeda_beneficiarios}}: Los primeros beneficiarios
éramos nosotros como comunidad, luego otros expertos en temas de periodismo de datos y finalmente
el público con interés, pero sin experticia.
Las reacciones a los mensajes de socialización de los resultados son consecuentes con esa lectura,
presentando mayor actividad en la comunidad de Grafoscopio y menor entre más general es el público.
Quizás sea el hecho de que el resultado es el Manual en español, y los monólogos son habituales
en las redes sociales, pero la indiferencia de los autores originales y medios como La Nación
de Argentina, ante los contactos establecidos por Twitter, no deja de ser inquietante, a pesar
de la utilidad propia de este esfuerzo al interior de la comunidad.
En otros eventos presenciales, como Datos y Guaros, los asistentes también manifestaron interés
en tales publicaciones, pero la dinámica de tales eventos es más la de lograr una mirada panorámica
sobre lo que hacen los ``dateros'' más que entrar en una participación directa en tales proyectos.

%PEND: páginas del Manual en Telegram

Las tensiones y dinámicas de participación siguen estando presentes, como se ve, pero también
existe un valor intrínsico en estos proyectos que cobra fuerza en la manera en como afectan
a la comunidad y potencian sus infraestructuras y dinámicas, más allá de las reacciones externas
y como estas consolidan llamamientos y cierres (\cite{isin_being_2015}) que hacen parte de
prototipos y dinámicas futuras, como veremos en otros ejemplos de este capítulo.


\section{Portal de Software Libre}

\section{Pasos para una Biblioteca Digital de Bogotá}\label{bidibog}

\section{Twitter Data Selfies}\label{twitter-data-selfies}

\section{Brea y Etico}\label{brea}

\section{Otros constructos comunitarios}\label{comunidad-artefactos}

A lo largo de las distintas ediciones del Data Week, las Data Rodas y otros encuentros,
se fueron creando otro tipo de constructos comunitarios.
El primero de ellos, y de uso más evidente durante los mismos fueron las libretas
de 

