OrderedCollection [
GrafoscopioNode {
#header : 'Dedicatoria',
#key : '',
#body : 'A mi mamá, Hilda Cárdenas y mi hermana, Divian Luna, sin cuyo apoyo incondicional
durante los años que duró mi doctorado (y los años en los que hice pausa) este texto no sería
posible.',
#children : OrderedCollection [ ],
#parent : GrafoscopioNode {
#header : 'Arbol principal',
#key : '',
#body : '',
#children : @1,
#level : 0,
#nodesInPreorder : OrderedCollection [
@4,
@2,
GrafoscopioNode {
#header : 'Agradecimientos',
#key : '',
#body : 'A mi familia y amigos.',
#children : OrderedCollection [ ],
#parent : @4,
#level : 1
},
GrafoscopioNode {
#header : 'Introducción',
#key : '',
#body : '*¿Cómo cambiamos los artefactos digitales que nos cambian?*
Esta es la pregunta que inspiró la investigación que este escrito presenta y para abordarla
se creó y jalonó una dinámica de modifcación recíproca entre una jóven
comunidad de práctica, en el *hackerspace* HackBo, en Bogotá Colombia, y un artefacto digital
amoldable para escritura interactiva, investigación reproducible, visualización y activismo de
datos, llamado Grafoscopio (en el cual fue escrito el presente texto).
La investigación da cuenta de esta dinámica de modificación recíproca entre artefacto y comunidad,
de los enfoques teóricos para apreciarla (investigación desde el diseño, sistemas autopoiéticos),
del hábitat de dicho problema y su contexto (la contracultura hacker y sus recontextualizaciones
en un lugar del Sur Global) y de cómo se llegó a dicha dinámica en una aproximación informada
etnográficamente, que rastrea en las huellas dejadas en por la comunidad, las primeras intuiciones
y los diálogos entre tradiciones y practicas computaciones en dicho contexto (software libre y de
código abierto, el *dynabook* y sus encarnaciones en Smalltalk y *Pharo*, la investigación abierta y
reproducible, la escritura interactiva, la visualización y el activismo de datos).
Para lo anterior el texto está dividido en 3 partes: la primera que presenta el enfoque teórico/metodológico desde el que se aborda la investigación.
La segunda parte ya tiene que ver con la indagación dentro del hackerspace.
Usa una dinámica de zoom, descrita en la primera parte, definiendo el fenómeno hacker desde tres autores principales:
Coleman, Maxigas y Clark, para luego acercarse (*zoom in*) a HackBo en particular y contar la experiencia que llevó a la construcción de Grafoscopio y el taller-hackatón llamado
Data Week, donde aprendemos a usarlo y modificarlo, así y las huellas de ese proceso comunitario en los artefactos co-construidos.
La tercera cierra el texto con hallazgos, conclusiones y recomendaciones.
Este texto, y los artefactos digitales y prácticas asociadas constituyen así de un lugar ecléctico,
que se configura como nodo, nudo y puente, con importantes consecuencias prácticas:
Si podemos cambiar los artefactos que nos cambian, podemos decidir sobre nuestros cambios
futuros, agenciando autonomía y autodeterminación y posibilitando la construcción más plural
de un mundo compartido.
Espero que el lector encuentre múltiples lugares de ingreso y diálogo para construir juntos. ',
#children : OrderedCollection [ ],
#parent : @4,
#level : 1
},
GrafoscopioNode {
#header : 'Primera parte',
#key : '',
#body : 'Esta parte presente los objetivos de la investigación y brinda una mirada al lugar epistemológico
del diseño desde el cual se aborda la misma.',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Justificación',
#key : '',
#body : '',
#children : OrderedCollection [ ],
#parent : @10,
#level : 2
},
GrafoscopioNode {
#header : 'Objetivos',
#key : '',
#body : ' - Alentar y caracterizar la transición de usuarios a hacedores de artefactos digitales en el
el *hackerspace* HackBo, en Bogotá Colombia.',
#children : OrderedCollection [ ],
#parent : @10,
#level : 2
},
GrafoscopioNode {
#header : 'Ecología de saberes en diseño: Un ejemplo desde los discursos autopoiéticos',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Extractos',
#key : '',
#body : 'Al tiempo, este texto y las herramientas para construirlo se convierten en
artefacto-prototipo inacabado e impuro, para ser criticado y extendido a propósito
de otras posibilidades de interconexión de saberes en diseño.',
#children : OrderedCollection [ ],
#parent : @16,
#level : 3
}
],
#parent : @10,
#level : 2
}
],
#parent : @4,
#level : 1
},
@12,
@14,
@16,
@18,
GrafoscopioNode {
#header : 'Segunda parte: Jalonando la modificación recíproca de artefactos digitales y comunidades',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'El contexto',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'La diversa cultura hacker',
#key : '',
#body : 'Genealogías múltiples de la cultura hacker desde Biella Coleman, Maxigas, Kelty y Tania Robledo.',
#children : OrderedCollection [ ],
#parent : @22,
#level : 2
},
GrafoscopioNode {
#header : 'HackBo, un hackerspace en Bogotá',
#key : '',
#body : 'Rastrear la historia de HackBo desde su origen, a finales de 2010 hasta el presente, con los
hitos más importantes de dicha historia.
Enunciar el hecho de que está formada principalmente por activistas del software libre
que se conocen de tiempo atrás (2002), entre los cuales yo me encuentro.
%NOTA[ hacer alución en lo metodológico de que se trata más de una participación
\tobservante en lugar de una \"observación participativa\"].
Hablar de las dos comunidades:
- Nuclear
- Extendida
',
#children : OrderedCollection [ ],
#parent : @22,
#level : 2
}
],
#parent : @20,
#level : 2
},
GrafoscopioNode {
#header : 'Habitar el problema',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Prehistoria: Indie Web Science',
#key : '',
#body : 'Un intento de hacer las cosas desde la cultura Unix:
- La herramienta debe hacer una sóla cosa bien.
- La herramienta debe poderse conectar con otras herramientas.
- PERO: la carga cognitiva y de experiencia asociada a dichas conexiones depende de cada cual.
Por ello al final terminamos con muchas piezas móviles: web2py, python, IPython, Fossil, editores
de código (geany, Kate y jEdit, que era el más fácil de instalar), con la dificultad de ser integrada
sobre diversas plataformas de modos diferentes: Windows, Mac, Gnu/Linux, este último con
distintas distribuciones (o distros) con diferentes gestores de paquetes (apt-get, pacman) y un
flujo de trabajo que no permitía compartir los cambios entre los asistentes de manera
fluida, sino que apelábamos a comandos de los diversos repositorios de código para ciertas
sincronizaciones (unas usando fossil para lo que desarrollábamos internamente, otras usando
git para lo que se desarrollaba afuera, pero usábamos desde la comunidad de práctica).
Con tal cantidad de piezas pasabamos casi de la diversidad a la fractura y mucho del tiempo
lo usábamos en lidiar con el ensamblaje de las piezas más que con los aprendizajes propios
del taller.
',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'On deepness',
#key : '',
#body : '
think that complex (scientific) interactive documents which \"emerge\" from exploration need a tree interface for progressive structuration, for the reasons already mentioned in the case of Leo. In fact I would argue that Leo and IPython share the profound interest for introspection and having this feature implement in the tree would make IPython notebook really powerful. You could think of an IPython notebook as cells organized/chunked in subtrees which enable another level of aggregation to cells and I think that trees and cells are almost all of what users would need to organize IPython documents of the complexity of a thesis. Even with this metaphor of interaction, users could build complex web applications made on IPython using internal subtrees for internals of the apps and the external part of the trees for what the web user can interact with, in a similar way of hiding internals of my writings to my thesis reader (but from now this goes beyond what this post want to propose).',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Cita 1: Explorative computing',
#key : '',
#body : 'Fernando Perez, first author and project co-leader of IPython, has told about the explorative nature of scientific computing and how this holds also for a lot of computer users. I agree. Most of time, (scientific) users doesn\'t have a strict set of predefined rules to guide/constraint their interaction with computers. A question then is how this explorative nature of computer interaction will start to show progressive structure when complexity of exploration and writing increases. This is a problem that any writer confront and is even more important/visible if you have interactive documents.
Fernando Péres, primer autor y co-lider de proyecto de IPython, ha hablado acerca de la naturaleza explorativa
de la computación científica y cómo esto se mantiene también para muchos usuarios de computador.
Estoy de acuerdo. La mayoría de las veces, los usuarios (científicos) no tienen un estricto conjunto de reglas
predefinidas para orientar o restringir su interacción con los computadores.
Una pregunta entonces, es cómo esta naturaleza explorativa de la interacción con el computador,
empezará a mostrar estructura progresiva cuando la complejidad de la exploración y la escritura se incrementen.
Este es un problema que todo escritor confronta y es incluso más importante/visible
si se tienen documentos interactivos',
#children : OrderedCollection [ ],
#parent : @32,
#level : 5
},
GrafoscopioNode {
#header : 'Cita 2: emergent structure',
#key : '',
#body : 'I think that complex (scientific) interactive documents which \"emerge\" from exploration need a tree interface for progressive structuration, for the reasons already mentioned in the case of Leo. In fact I would argue that Leo and IPython share the profound interest for introspection and having this feature implement in the tree would make IPython notebook really powerful. You could think of an IPython notebook as cells organized/chunked in subtrees which enable another level of aggregation to cells and I think that trees and cells are almost all of what users would need to organize IPython documents of the complexity of a thesis. Even with this metaphor of interaction, users could build complex web applications made on IPython using internal subtrees for internals of the apps and the external part of the trees for what the web user can interact with, in a similar way of hiding internals of my writings to my thesis reader (but from now this goes beyond what this post want to propose).
Pienso que complejos documentos interactivos (científicos) que \"emergen\" de la exploración,
necesitan una interface arbórea para la estructuración progresiva, por las razones ya mencionadas
en el caso de Leo.
De hecho argumentaría que Leo e IPython comparten un profundo interés por la introspección y tener
esta característica implementa en un [documento arbóreo] haría las libretas de IPyhon realmente poderosas.
Podría pensarse incluso en un notebook de IPython como celdas organizadas/partdias en subárboles, que
habilitarían otro nivel de agregación a las celdas y pienso que los árboles y las celdas son casi todo lo que
los usuarios necesitarían para organizar documentos de IPython de la complejidad de una tesis.
Incluso con esta metáfora de interacción, los usuarios podrían construir complejas aplicaciones web
hechas sobre IPython, usando subárboles internos para las partes internas de las aplicaciones y las
partes externas para aquello con lo que el usuario web puede interactuar, de una manera similar a
ocultar las partes internas de la escritura al lector de mi tesis
(pero, por ahora, esto va más allá de lo que este escrito quiere proponer) .',
#children : OrderedCollection [ ],
#parent : @32,
#level : 5
},
GrafoscopioNode {
#header : 'Cita 3: No implemetarlo por mí mismo.',
#key : '',
#body : 'I hope the IPython community think that a proper metaphor for writing progressively structured complex and deep documents is needed if we want IPython to be the tool for a continuous writing experience in this context and trees are the way to go in that sense. Of course experimentation would be needed and hopefully I will not be writing the code alone to probe my thesis and this idea would be sound and interesting, even coming from a non-programmer ;-).
Espero que la comunidad de IPython piense que una metáfora adecuada para escribir progresivamente documentos complejos
y profundos es necesaria si queremos que IPython sea la herramienta para una experiencia de
escritura continua en este contexto, y que los árboles son la vía en ese sentido.
Por supuesto la experimentación sería necesaria y con optimismo, no estaré escribiendo el código sólo
para probar my tesis y esta idea sería sonora e interasante, incluso viniendo de un no programador.
',
#children : OrderedCollection [ ],
#parent : @32,
#level : 5
}
],
#parent : @30,
#level : 4
}
],
#parent : @28,
#level : 3
},
GrafoscopioNode {
#header : 'De las apps y los portales a las narrativas computacionales',
#key : '',
#body : 'Durante la primera gobernatón se hizo claro para mi, que una estrategia
alternativa a la de crear un app o un porta web era la de contar una historia
soportada por datos, pues nuestros argumentos sobre lo irregular de la
llamado del Ministerio de las TIC a \"participar\" de la hackatón de gobierno
en línea, era sustentada por los datos de la convocatoria colocados en
la web y los cambios que ocurrían en los mismos mientras la crítica circulaba
en redes sociales.
%NOTA[ vincular capturas del hashtag y copias del wiki]
Tecnología como los códigos de integridad criptográfica para auditar cambios
en archivos, usadas ahora para auditar cambio en la convocatoria, o los
cuadernos interactivos de IPython, usados ahora para sustentar la narrativa
integrando datos, prosa y publicándo nuestos avances en Internet
nos permitían participar de la conversación de nuevos modos y con nuevas
potencias.
Si bien las apps y portales podrían ser pasajeras (como el tiempo demostró),
las técnicas para contar historias e interlocutar con los poderes hegemónicos,
particularmente del gobierno, basados en datos y técnicas computacionales
podrían sobrevivir al evento específico de la gobernatón.
Era la historia que se desplegaba sobre estas nuevas formas de participación
ciudaana y las técnicas para contarla lo fundamental.
Encontré que este tipo de iniciativas también estaban tomando cuerpo en otras
latitudes bajo el nombre de periodismo de datos.
%NOTA[Captura de pantalla de dokuwiki con las referencias respectivas]
La combinación de estas tecnologías para argumentar e interlocutar con el
estado recogía lo que habíamos hecho en los talleres de indie web science
referidos a crear y publicar libretas de notas/argumentos computacionales,
y también se convertiría en un puente con lo que vendría después, intentando
transpasar los límites de tales tecnologías complicadas y encuentros intensivos, pero sin
continuidad: El Data Week y Grafoscopio',
#children : OrderedCollection [ ],
#parent : @28,
#level : 3
},
GrafoscopioNode {
#header : 'La Gobernatón: La hackatón como acto de resistencia y crítica desde la sociedad cívil',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Cita: sesgo hacia la acción',
#key : '',
#body : 'The phrase ‘‘bias to/for/toward action’’ was routinely used to
describe the figure of an entrepreneurial doer who cut through bureaucratic red tape and lengthy deliberations in pursuit of efficient, inspired progress. Progress, in this professional discourse, often amounted to visible outcomes—services, infrastructures, businesses, and public order—rather than procedural justice or distributions of rights.
La frase \"sesgo a/por/hacia la acción\" era empleada rutinariamente
para describir la figura de un hacedor emprededor que usaba atajos a la
cinta roja burocrática y las largas deliberaciones en busca del eficiente, progreso inspirado.
Progreso, in este discurso profesional, con frecuentes soluciones visibles
—servicios, infraestructuras, negocios y orden público—
en lugar de justicia procedimental o redistribución de los derechos.',
#children : OrderedCollection [ ],
#parent : @42,
#level : 4
},
GrafoscopioNode {
#header : 'Cita: Footwork <-> codework:',
#key : '',
#body : '
Prem warned us, it would require ‘‘some REAL footwork’’ to get ‘‘on the street’’ and work with existing organizations already thinking in terms of political mobilization.
For that week, however, we weren’t on the street. We were in the studio. The time, tools, and skills in the room were geared toward ‘‘code work,’’ not ‘‘footwork.’’
[El sociologo en la hackatón] nos advirtio, que requería \"cierto trabajo REAL de a pie\" para ir \"a la calle\"
y trabajar con organizaciones existentes actuamente pensando en términos de movilización política.
Para aquella semana, sin embargo, no estábamos en la calle. Estávamos en el estudio.
El tiempo, las herramientas y las habilidades en el cuarto estaban orientadas hacia el \"trabajo con código\"
no hacia el \"trabajo de a pie\".',
#children : OrderedCollection [ ],
#parent : @42,
#level : 4
},
GrafoscopioNode {
#header : 'Cruzar la distancia, sin caminarla',
#key : '',
#body : 'this actually existing site of design practice revealed that its politics were in its forms and norms—in its manufactured urgency, in the distance between the studio and the world, and the media ecologies that made it possible to promise to cross that distance without walking it.
Este sitio realmente existente de prácticas de diseño reveló que sus políticas estaban en sus formas
y sus normas — en su manufacturada urgencia, en la distancia entre el estudio y el mundo,
y en la ecología de medios que hacia posible prometer cruzar la distancia sin caminarla.',
#children : OrderedCollection [ ],
#parent : @42,
#level : 4
}
],
#parent : @28,
#level : 3
},
GrafoscopioNode {
#header : 'Grafoscopio',
#key : '',
#body : 'Recuento de lo que es, lo que pretende y para que sirve, haciendo alusión a los primeros textos y
a algunos escritos individuales.',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Technologies behind',
#key : '',
#body : 'Grafoscopio tries to become an simple, understandable, moldable, versatile and flexible tool thanks to the power of Pharo Smalltalk ecosystem and the combination with mature internal and external frameworks and tools. It uses:
GT Tools and Spec embeddable Moose playgrounds for GUI and interactive nodes.
Roassal for data visualization.
Pandoc for exporting to pdf/printing and html/web formats.
STON for notebooks format.
Fuel for data storage and objects serialization
Fossil SCM for collaboration and traceability of the documents history.
Grafoscopio trata de ser una herramienta simple, comprensible, amoldable, versátil y flexible,
gracias al poder el ecosistema de Pharo Smalltalk y la combinación con frameworks y herramientas maduras externas e internas.
Usa:
Internas:
GT Tools y Spec para los playgrounds embebibles, los nodos interactivos y la Interface Gráfica de Usuario (GUI).
Roassal para visualización de datos.
STON para un ligero almacenamiento de datos y formato de documentos.
Fuel: para almacenamiento medio y serialización de objetos.
Externas:
Fossil SCM para colaboración y trazabilibildad de los documentos
Pandoc para exportación a formatos pdf/impreso y html/web.
SQLite para almacenamiento y manipulación de datos tabulares.',
#children : OrderedCollection [ ],
#parent : @50,
#level : 4
}
],
#parent : @28,
#level : 3
},
GrafoscopioNode {
#header : 'El Data Week',
#key : '',
#body : 'El *data week* surgió como respuesta a la necesidad de crear una comunidad de práctica alrededor de
las herramientas amoldables, pues en la comunidad nuclear de HackBo dicho interés no era fuerte,
lo cual, creo, se debe a una fuerte inversión de tales miembros en las tecnologías y problemáticas
ya elegidas: aplicaciones móviles, hardware, derechos en contextos digitales centrados principalmente
en la legislación, producción audiovisual, como las más notorias, que no están relacionados de manera
directa a las herramientas amoldables.
A esto se sumaba el hecho de que tales herramientas amoldables propuestas estaban hechas con una
familia de tecnologías del ecosistema Pharo, una variante de Smalltalk, que no es muy popular entre los desarrolladores,
tanto internacionalmente [citar cifras] como localmente (algunos de los miembros de HackBo reportaron
que lo habían escuchado mencionar en su pregrado o que lo habían ojeado brevemente, pero la
mayoría elegió y usaba otras tecnologías: python, php, java, c y c++).
Dichas ideas y prácticas sobre herramientas amoldables encontraban un apoyo que se limitaba al \"apoyo moral\",
como recalcaba reiteradamente uno de los miembros de la comunidad nuclear, e incluso resistencia, en las constantes
conversaciones acaloradas (*flame wars*) y burlas, que si bien podían juzgarse dentro de lo amistoso, no permitían
que esas ideas y prácticas alternativas florecieran.
Se requería entonces una nueva comunidad en la que las ideas y prácticas de herramientas amoldables encontraran una mejor
acogida y el *data week* fue la manera de empezar a consolidarla.
La convocatoria fue abierta, y en las sucesivas ediciones del data week (7 en total entre julio de 2015 y
noviembre de 2016) la invitación y el evento fueron tomando forma (ver imágenes)
invitando a personas interesadas en visualización y activismo de datos, herramientas amoldables,
desde un enfoque basado en problemas y ofreciendo continuidad entre las diferentes ediciones,
trabajando versiones más avanzadas del mismo problema.
%NOTA[ gráfica de las ediciones del data week y línea de tiempo de la página principal] ',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Datos crudos',
#key : '',
#body : '\t\\footnote{El
\t\tsólo elegir qué datos coleccionar, para resolver qué tipo de
\t\tproblema y de qué manera tiene implicita una serie de
\t\tsubjetividades, como lo explica Luisa Gitelman en \\emph{``Raw Data\'\'
\t\t\tIs an Oxymoron}\\cite{Gitelman2013-raw-data},
\t\tKrippendorff\\cite{Krippendorff_design_oxymoron}
\t\tlo dice de modo elocuente cuando afirma:
\t\t
\t\t\\quote{
\t\t\tPrivilegiar las propiedades de los datos a expensas del rol de los investigadores como
\t\t\tcreadores de hipotesis, proponentes de teorías y diseñadores de sistemas de análisis
\t\t\tniega la agencia humana en los productos de la ciencia. El habilidoso diseño de la
\t\t\tinvestigación por los científicas se convierte así en la víctima del compromiso
\t\t\tepistemológico con la objetividad, la ilusión de ser capaz de observar sin observador o
\t\t\tde investigar sin las historias cognitivas y lingüísticas de los investigadores
\t\t\t
\t\t}}
',
#children : OrderedCollection [ ],
#parent : @54,
#level : 4
},
GrafoscopioNode {
#header : 'Sobre los ritmos, intensidades, temáticas y productos',
#key : '',
#body : 'Debido a su caracter simultáneo de taller y hackatón, el *data week* buscaba lograr
un balance entre el aprendizaje guiado que permitiría asumir los conceptos necesarios
para la exploración autónoma luego.
Cada una de las ediciones suscesivas del evento fue una exploración de dinámicas
e infraestruturas que se acercaran a este balance, durante el periodo entre junio de
2016 y noviembre de 2016, en el cual se desarrollaron 7 ediciones del mismo, probando
diferentes esquemas.
El propósito era lograr una experiencia intensiva, que contrastara con los esporádicos
tallerdes de *indie web science* (los nombres en inglés de dichos eventos ayudaban a
comunicarlos a comunidades internacionales y posicionarlos en motores de búsqueda).
Tener un taller de cerca de 30 horas, en poco tiempo que se pudiera incorporar al resto de la vida
y no requiriera de demasiados esfuerzos extra.
La primera edición (junio 22 al 27 de 2015) ocurrió todas las noches de 5 pm a 9 pm y el
sábado todo el día, pero debido a que era parte de una semana laboral habitual, los ritmos
eran extremadamente desgastantes para los participantes, en particular para mí en mi rol de organizador.
La temática acá fue *los mapas del silecio*, que buscaban mostrar qué tanto contestan o no
los políticos en Twitter.
Si bien el código era desordenado, se lograron avances, pasado de prototipos en papel a gráficas computacionales,
(véase gráfica tal y detalles en (luna mapas).
que empezaron a mostrar que efectivamente el entorno de visualización ágil, ingrado en Pharo y accesible desde
Grafoscopio, permitía rápidos avances con respecto a los talleres de Indie Web Science e incluso con respecto a
otras hackatones de periodismo de datos y visualización, que sólo se quedaban en la maqueta (*mockup*), sin
apelar a datos o resultados algorítmicos tomados de fuentes reales de información (cfg César Arias).
La segunda edición (septiembre 21 al 26 de 2015) se hizo dentro de una semana de descanso de la Universidad
Javeriana, en el marco de una investigación conjunta llamada Ciudad de Datos, en la que participé como co-investigador,
pues se pensó que mucha de la población interesada, sería estudiantes universitarios.
La intensidad horaria aumento a 6 horas diarias, que entre semana estaban repartidas en
un par de horas (10:30 AM a 12:30 PM) en la mañana, un receso para el almuerzo y 4 horas en la tarde (2:30 PM a 6:30 PM, aprox.)
y el sábado iban de 2:30 pm a 8:30 pm.
La asistencia no muy masiva y los estudiantes universitarios prefirieron invertir su semana de
receso en otros lados.
Sin embargo esta intensidad horaria por sesión mostró ser adecuada para la consecución de mejores resultados,
pues si bien era más demandante, se beneficiaba de mayores tiempos de concentración de los participantes
el mismo sitio (en el anterior horario, con sesiones más cortas y viajes en la noche, los participantes se empezaban a
alistar y se marchaban desde antes).
El principal avance en esta edición fue la mejora del tutorial interactivo de Smalltalk, hecho en Grafoscopio y la consolidación
de algunas visualizaciones de los *mapas del silencio* en el paquete ``Dataviz``, lo que a su vez permitió iniciar una didáctica
particular, en la que se mostraba cómo los algoritmos prototipados colectivamente con los asistentes se incorporaban al
conocimiento cristalizado en el sistema a través de paquetes y cómo se podía empezar a navegar y deconstruir dicho conocimiento.
Esto constituyó un avance respecto a lo anterior, pero no había un paquete de visualizacipon totalmente usable por un participante
al final del evento, ni mucho menos por alquien externo.
Quedó más claro que la intensión del *data week* en parte era iterar sobre esos prototipos imperfectos e irlos mejorando
con sucesivas ediciones.
La tercera edición se probó partir el Data Week en dos sesiones, ambas de jueves a sábado, de 2:30 PM a 6:30 PM
(occuridas en febrero 25 al 27 y marzo 3 al 5 de 2016).
Si bien estas sesiones implicaban que algunas personas deberían contar con dos tardes dentro del horario laboral habitual,
o bien los asistentes contaban con flexibilidad del tiempo, o bien era un permiso que se podía solicitar en caso de que no.
Lo cierto es que esta forma de organización generó la asistencia más regular, con jornadas suficientemente intensivas para
avanzar el el problema.
Una particularidad acá fue el cambio del problema, para adecuarlo a las necesidades percibidas en la investigación Ciudad
de Datos, según uno de los coinvestigadores.
Esto trajo la ventaja de triangular información: ya no estábamos más centrados en los temas de redes sociales, sino que podíamos
poner a circular en ellas información extraida de otros lados, en este caso del portal de contratación pública, en aras de articularnos
con la naciente comunidad *Open Data Colombia* (OpenDataCo) y el *scrapper* de contratos del portal gubernamental colombiano
``contratos.gov.co`` (prizbilla-xxx).
Esto a su vez nos alineaba con otras comunidades como [OpenBugets](http://openbudgets.eu/), [OpenSpending](https://openspending.org/)
y algunos proyectos y temáticas de la [Open Knowledge Foundation](https://discuss.okfn.org/).
También mostraba el potencial del trabajo desde individuos y pequeños colectivos: por ejemplo, el proyecto OpenSpending
mostraba como 76 países habían liberado 1105 datasets conteniendo 28\'369.534 registros [@OpenSpending, index].
El scrapper de un sólo individuo, y la organización y limpieza posterior en la comunidad OpenDataCo y el Data Week 3ra edición,
logró liberar (XXX) registros para 15 años de contratación.
Sin embargo, tenía un riesgo, como se señaló antes de la ejecución del taller al coinvestigador, y es que familiarizarse con los datos
y sus visualizaciones y lograr continuidad y resultados con el problema era algo difícil para un problema de una semana,
si nadie se iba a ocupar de dichos datos después.
Liberar los datos no bastaba, había que comprometerse con encontrar las estructuras e historias dentro de dichos datos y contarlas.
A esto se sumaron dificultades con la conexión entre Pharo y SQLite, el motor de datos para trabajar el dataset de contratos, que,
si bien fueron temporales debido a la transición a la siguiente versión de Pharo, en un evento intensivo como el Data Week, cobraron
su tiempo y causaron descontento entre los participantes, un par de ellos reportó que no concebián como una cosa que el los demás
lenguajes de programación está resuelta, en este termina siendo un impedimento tan grande para el tratamiento de datos.
Finalmente logramos rodear el problema, no sin una considerable pérdida de tiempo y fluidez durante la realización del taller/hackatón.
Aún así los asistentes mantuvieron el interés y hubo 3 sesiones de un día, posteriores al evento, para continuar con el problema y la
solicitud de crear una lista de correo para los asistentes al Data Week.
Si bien dicha solicitud no fue implementada inmediatamente, e invité a la gente a la comunidad de OpenDataCo, con el ánimo de
dinamizarla, la implementé con el tiempo, al ver el interés sostenido de los participantes y la necesidad de tratar temas específicos
a los interesados en Grafoscopio y los asistentes al Data Week.
Desde la edición 4 del data week se consolidó el esquema, de la anterior, de dividir el encuentro en dos sesiones.
Esta se realizó en el colaboratorio de Medellín (ver fotos), también en alianza con el proyecto Ciudad de Datos,
pero se volvió al problema de visibilizar la comunicación en Twitter, ya no desde los mapas del silencio, sino desde un
proyecto llamado *data selfies*, que se basaba en la información provista por cada usuario de Twitter, en lugar de la
información desde el scrapper.',
#children : OrderedCollection [ ],
#parent : @54,
#level : 4
}
],
#parent : @28,
#level : 3
},
GrafoscopioNode {
#header : 'Conclusiones',
#key : '',
#body : 'Por el contrario, cuando nos pasamos a Pharo, una vez montado en entorno sobre cada
sistema operativo (Windows, Gnu/Linux o Mac), contabamos con un lugar similar, que usaba
metáforas y procedimientos consistentes , independientemente del sistema operativo
base y si bien tuvimos que lidiar con algunas diferencias entre plataformas, como la instalación
de motores de bases de datos (SQLite en el Data Week 3) o librerías (Cairo de 32 bits para Linux),
en su integración con Pharo, esta era una diversidad manejable, que nos permitía concentrarnos
en desarrollar el taller, lo cual se muestra en los progresivos avances que se tuvieron entre
las ediciones de los distintos data weeks, comparados con los talleres previos de Indie Web Science,
pero también en los comentarios de los asistentes a los dos tipos de experiencias
%NOTA [ colocar comentarios de R, C e I] .
Esto fue particularmente claro en la manera como compartíamos código *durante* la ejecución
de los talleres.
Por ejemplo, los notebooks que no podían ejecutarse, pues apelaban a funcionalidades
que aún no estaban actualizadas en los entornos de todos los asistentes, estaban a sólo
un par de clicks de estar disponibles para todos.
%NOTA[? | insertar capturas de pantalla de códigos \"rojos\" y aceptados en los cuadernos
\tantes y después de una instalación]
De modo que los más expertos ponían a circular artefactos más terminados sin que
esto también implicara que los novatos debían ir al mismo ritmo, entender todos los detalles o
disciparse con la sintaxis (cometí un error con el punto?, puse bien los punto y coma?) .
Se aclaraba a los asistentes que dicha comprensión y manejo de los detalles corresponde más
a una relación prolongada con el código como lenguaje simbólico y va más allá de lo que se puede
desarrollar en un taller de una semana.',
#children : OrderedCollection [ ],
#parent : @28,
#level : 3
}
],
#parent : @20,
#level : 2
}
],
#parent : @4,
#level : 1
},
@22,
@24,
@26,
@28,
@30,
@32,
@34,
@36,
@38,
@40,
@42,
@44,
@46,
@48,
@50,
@52,
@54,
@56,
@58,
@60,
GrafoscopioNode {
#header : 'Bibliografía',
#key : '',
#body : '',
#children : OrderedCollection [
GrafoscopioNode {
#header : 'Buchanan-1',
#key : '',
#body : '@article{Buchanan-1,
\tauthor = {Richard Buchanan},
\ttitle = { \"Children of the Moving Present\" The Ecology of Culture and the Search for Causes in
\tDesign.\" },
\tjournaltitle = {Design Issues},
\tdate = {date},
\tissue = {17},
\tpages = {67-84},
}',
#children : OrderedCollection [ ],
#parent : @62,
#level : 2
}
],
#parent : @4,
#level : 1
},
@64,
GrafoscopioNode {
#header : 'Gráficas',
#key : '',
#body : '',
#children : OrderedCollection [ ],
#parent : @4,
#level : 1
},
GrafoscopioNode {
#header : 'newNode',
#key : '',
#body : '',
#children : OrderedCollection [ ],
#parent : @4,
#level : 1
}
]
},
#level : 1
},
@6,
@8,
@10,
@20,
@62,
@66,
@68
]