Atravesando turbulencias

Algunos aprendizajes a partir de fabricar y volar drones de código abierto

Co-escrito con Gustavo Pereyra Irujo

Con la ayuda de muchas manos y cerebros, y fondos de Numies, Mozilla Science Lab, y PROCISUR, desde junio de 2017 hasta enero de 2019, nosotros (los autores de este post) hemos co-liderado el Proyecto Vuela. Más de 40 talleres tuvieron lugar en Argentina, Brasil, Chile, Paraguay y Uruguay, con una “tripulación” de más de 150 personas, para primero replicar un dron de código abierto, luego modificarlo y por último usarlo.

En 2017 comenzamos a fabricar el Flone, un drone abierto de Aeracoop (flone.cc), y después del proceso de fabricación (ver aquí), decidimos intentar modificar ese diseño para hacerlo útil para fines científicos. Con una mini-subvención de Mozilla en 2018, comenzamos a crear un prototipo de kit de herramientas de código abierto para drones, que pudiera ser igualmente accesible para científicas de la academia, científicas/os comunitarios, activistas y casi cualquier persona que pudiese necesitar un dron para recopilar datos para sus exploraciones científicas. Este trabajo comenzó en nuestros países de origen, Chile y Argentina, y luego, a fines de 2018, PROCISUR nos dio la oportunidad de fabricar y probar el nuevo dron, llamado OVLI (objeto volador libre), con un grupo de investigadores en cinco países diferentes.

También formamos parte de una comunidad global (GOSH, Global Open Science Hardware) que intenta hacer un gran cambio: queremos que el hardware libre y de código abierto sea la opción predeterminada en ciencia. Esa tarea es muy parecida a navegar por un territorio inexplorado: no hay mapa, por lo tanto tenemos que ir dibujando el mapa a medida que nos movemos y cometemos errores.

En 2017, esta comunidad armó su “Hoja de ruta” (la siguiente imagen es una captura de pantalla), pero a pesar de su nombre, no es exactamente un mapa, sino también una especie de brújula. No está pensado como un documento estático (como lo es un mapa), sino como uno que puede ser revisado y adaptado a medida que avanzamos hacia nuestra meta. Una brújula nos permite hacer precisamente eso, ajustar nuestros pasos en función del contexto que nos encontramos. Esto se refleja en una de las 3 secciones principales del documento, llamada “Aprender”, que enfatiza la importancia del aprendizaje constante y la iteración.

Que para el 2025 el hardware científico abierto sea la regla y no la excepción. Resumen ejecutivo: La capacidad de usar, estudiar, replicar y mejorar la instrumentación científica es
un componente fundamental de la ciencia experimental, y juega un papel crucial en la vida pública, la investigación y el activismo. Sin embargo, actualmente estas actividades se encuentran restringidas por el uso de instrumental patentado o cerrado, el cual es caro y difícil de obtener y mantener, ya que no pueden ser completamente examinados, evaluados o personalizados. Este contexto, por su propia naturaleza, es perjudicial para la producción de conocimiento y para su potencial como fuente de soluciones equitativas y sostenibles. Por ello, la comunidad de Hardware Científico Abierto (OScH) busca reunir a desarrolladoras y usuarias de herramientas científicas e infraestructuras de investigación, con el fin de apoyar la búsqueda y el crecimiento del conocimiento, proporcionando acceso global al hardware científico.

Con Vuela hemos tenido el mismo propósito en mente. No queríamos simplemente ir a algún lugar, desempacar herramientas y componentes de drones y sentirnos satisfechos. Queríamos hacer, observar resultados, aprender, ajustar, y mejorar, no solo el dron en sí mismo, sino también el proceso de participación y colaboración entre aquellos que no suelen ser parte, que no son ‘los sospechosos de siempre’. Desafortunadamente, las limitaciones financieras y de tiempo nos han impedido realizar una evaluación detallada (que podría incluir, por ejemplo, entrevistas profundas e investigación etnográfica). Lo que hicimos fue discutir las impresiones después de cada taller, tomar notas, y probar cosas nuevas en función de las percepciones inmediatas. Aquí hemos recopilado algo de este aprendizaje.

Construir un instrumento de código abierto, tener la confianza necesaria para proponer mejoras y, en este caso específico, aprender a volar, requiere de mucho tiempo. Y esto se aplica a cualquiera, sin importar el conjunto de habilidades con que se cuente. Por lo tanto, como resultado de los talleres queríamos ver un cambio de percepción, pasar de un “la tecnología y la ciencia es algo que solo unos pocos pueden hacer, los expertos, los que trabajan en universidades o que trabajan en ciertos campos, no yo”, a “esto no es tan difícil como pensé, puedo hacerlo, es divertido y puedo aportar mi propio conocimiento”. Y que científicos de instituciones tradicionales pasen de “esto solo se puede hacer en un laboratorio profesional” a algo como “los laboratorios no son el único lugar” y “trabajar a la par de otros conocimientos es útil, ‘otras’ personas saben cosas que yo no”. Queríamos abogar por una postura más crítica. No queríamos al final del proceso tener a un grupo de personas entusiasmados por los drones porque sí, obsesionados con volar para tomarse selfies aéreas. En su lugar, queríamos que las personas se dieran cuenta de que podían hacer, usar y modificar la tecnología abierta si así lo querían, que podían encontrar otros instrumentos que pudieran servir a sus propósitos, adaptándolos si fuera necesario y redistribuyendo de alguna manera su propio aprendizaje.

Bueno, esos eran nuestros propósitos. Pero, ¿cómo anduvo todo?, ¿qué aprendimos? Por supuesto que sucedieron cosas buenas e inesperadas, pero por ahora, aquí les compartimos una lista de 10 barreras que encontramos, y algunos intentos de superarlas.

1. Idioma

El problema:

La documentación del Flone está en español y, por lo tanto, en 2017 pensamos que nos habíamos salvado, ¡no tendríamos que traducir nada! Pero entonces, ¿quién vino a nuestros talleres? Principalmente inmigrantes haitianos que habían llegado recientemente a Chile, entre los cuales pocos o ninguno hablaba español. Eran extremadamente curiosos, colaborativos/as y hábiles, pero la comunicación era difícil. El lenguaje se convirtió en un tema aún más apremiante en la segunda etapa, cuando comenzamos a modificar colectivamente el dron para hacerlo más apto para capturar imágenes de buena calidad y servir a fines de investigación, y documentar el proceso.

Cómo lo abordamos:

En 2017, comenzamos a ensamblar el Flone por adelantado y grabamos el proceso en una serie de videos. Usamos esos videos en los talleres y funcionaron muy bien para la construcción/réplica del Flone. Los miembros de la tripulación (así llamamos a los participantes) se ayudaron mutuamente sin que tuviéramos que presionarlos para que lo hicieran. El armado de este ‘rompecabezas’ se les hacía bastante natural. Sin embargo, los videos no nos ayudaron a tener conversaciones más profundas sobre tecnología, ciencia, conocimiento(s), poder. Fue difícil discutir detalles u obtener su retroalimentación. Nuestra solución fue parcial, y también lo fue el involucramiento en el proceso de los miembros de la tripulación.

Para la segunda etapa, Stevens, un colaborador haitiano, nos ayudó a hacer un video introductorio en Créole (Criollo Haitiano), que ayudó a los nuevos miembros a entrar en el proceso, y sentirse bienvenidos (suponemos). También utilizamos el traductor de google (la aplicación de teléfono). Pero no fue suficiente para el tipo de charla que esperábamos tener, o para obtener retroalimentación o documentar adecuadamente sus ideas. Y a un ritmo acelerado, en talleres de 3 a 5 horas, no era fácil hacer una pausa para usar una aplicación de traducción. GitHub (una plataforma online de colaboración) está en inglés y aunque la mayoría de nuestro contenido está tanto en inglés como en español, no todo lo está, así que pedirle a los que no hablan inglés o más aún a quienes no hablan español que chequeen/completen GitHub no era factible.

Ideas que nos llevamos:

Las aplicaciones de traducción y los videos en el idioma de los participantes no fueron suficientes para obtener un fuerte sentido de pertenencia, de significado y de propósito durante los talleres. Y creemos que esas cosas son importantes si queremos que las personas pongan sus aportes y opiniones sobre la mesa, a sabiendas y voluntariamente. Las soluciones aisladas resultaron más bien cosméticas en ausencia de un enfoque integral y con fundamento para enfrentar las barreras del idioma. Una buena narrativa es necesaria para transmitir mensajes complejos y para vincularse con las personas. No sabemos cómo abordar esto la próxima vez. Tal vez se necesita una gran dosis de creatividad. Creativos/as, ¡ayuda!

Siendo optimistas, podríamos esperar que plataformas colaborativas tales como GitHub lleguen a estar disponibles en los idiomas más hablados como el español, pero probablemente no sea así en el caso del criollo haitiano o en los idiomas de otros grupos/naciones pequeñas o tradicionalmente segregadas. ¿Qué hacer entonces? ¿ideas?

2. Documentación

El problema:

Una buena documentación es difícil de producir. Con ‘buena’ nos referimos a la documentación que permite a cualquier persona reproducir lo que hicimos, y también entender lo que implica adaptarlo a sus propias necesidades. Pero el nivel de detalle involucrado es enorme, y también es un proceso permanente. No puedes hacer un taller y no documentar lo que sucedió allí. Y esta tarea puede ser tediosa. Es muy común que solo una o unas pocas personas se encarguen de la documentación, en lugar de que un grupo distribuido lo haga. Y esto también se cruza con el tema del idioma, ya que es más fácil aprender y contribuir el propio conocimiento en nuestra lengua materna. La pregunta es cómo avanzar hacia un proceso de documentación más efectivo, colectivo e inclusivo.

Cómo lo abordamos:

Pensamos que una parte esencial de un proyecto abierto es contar con documentación que sea fácil de modificar, de acceder y de comprender para todos aquellos a quienes se pretende llegar con el proyecto. Utilizamos Google Docs para escribir la guía de construcción del OVLI y redactar muchos otros documentos del proyecto. Tratamos de involucrar a todos aquellos que contribuyeron al proyecto en el proceso de documentarlo, y de que vieran esto como algo esencial y no intimidante. Una cosa que hicimos fue tener una computadora portátil siempre abierta durante los talleres y pedir a las personas que escribieran alguna idea, pregunta o comentario sobre el hardware o el proceso. La falta de conexión a Internet confiable significaba que a veces escribían en un documento de Word, a veces en un Google Doc, a veces en GitHub, a veces en un papel. Otra cosa que hicimos fue dedicar los últimos 15 minutos del taller para documentación y comentarios, en una especie de ‘lluvia de ideas’. Sin embargo, a pesar de que la mayoría de los miembros de la tripulación contribuyeron con ideas o notas, pocos realmente se dieron cuenta de todo lo que implica la documentación, como por ejemplo la necesidad de que sea realmente accesible para otros.

Ideas que nos llevamos:

Tener un formato de documentación estándar, como un documento escrito en google docs, podría ayudar a que los participantes se acostumbren e involucrarse. Pero esto también podría ser contraproducente. Un formato estándar puede no tener en cuenta las diferencias culturales o de formación. Algunos se sienten más cómodos tomando notas escritas a mano, otros escribiendo en una computadora, otros dibujando, otros hablando. Deberíamos estar abiertos a diferentes formatos de documentación; las pautas escritas pueden ser complementadas o incluso reemplazadas por formatos visuales o de audio. También parece ser importante mantenerse alerta y, ojalá, evaluar lo que parece funcionar con los participantes más “inusuales” (niños, personas mayores, todos aquellos a quienes constantemente les dicen que “no pueden”). Pero al tener diferentes formatos, integrarlos se convierte en un problema.

Asegurarse de que la documentación sea entendida fácilmente por todos es clave. Una idea es entregar los documentos y guías a una amiga/o adolescente, a algún vecino, a otros miembros de la tripulación, y pedirles que lean y vean qué entienden y qué no. Tal vez hablar con alguien parcial o totalmente ciego y ver qué podría funcionar para él, qué tipo de ideas tiene. Este tipo de retroalimentación es necesaria.

3. Dependencia de herramientas cerradas

El problema:

Es más fácil seguir utilizando las herramientas de código cerrado que ya conocemos (como google docs) en lugar de tratar de encontrar herramientas de código abierto, alinear aquel uso con nuestros principios de acción, y darle fuerza a la narrativa de código abierto que queremos contar.

Cómo lo abordamos:

Nuestro primer intento fue comenzar a utilizar Open Science Framework, una plataforma de colaboración para proyectos de ciencia abierta, que parecía la solución perfecta para Vuela. Lamentablemente, no funcionó para nosotros. Subimos información allí, pero no nos sirvió para colaborar. En mayo de 2018, Vuela formó parte del Mozilla Global Sprint, y para eso creamos nuestro repositorio en GitHub, una plataforma de colaboración ampliamente utilizada por los desarrolladores de software de código abierto. Más tarde descubrimos que GitHub en sí no es de código abierto, y que además fue adquirido recientemente por Microsoft. Todavía usamos GitHub regularmente para nuestro proyecto, pero probablemente cambiaremos a la alternativa de código abierto GitLab. También creamos un foro en línea utilizando el software de código abierto Discourse, pero desafortunadamente, la mayoría de las comunicaciones del proyecto aún se canalizan a través de Whatsapp y correo electrónico (principalmente Gmail).

Ideas que nos llevamos:

¿Qué herramientas utilizar? Desafortunadamente, no existen muchas buenas herramientas de código abierto para cada uno de las facetas del trabajo colaborativo y la documentación. Y a pesar de que no queremos utilizar software propietario, debemos admitir que algunos son bastante útiles; Google Docs es una herramienta muy eficiente, ¡queremos ya una alternativa igual de buena y abierta!

Aquí enumeramos algunas herramientas de código abierto que podrían usarse como alternativas:

Etherpad en lugar de Google Docs (etherpads públicos de Mozilla, Wikimedia, Riseup y otros)

GitLab en lugar de GitHub

Jitsi en lugar de Skype

Riseup o ProtonMail en lugar de Gmail

Riot en lugar de WhatsApp

4. Tener un lugar propio

El/los problemas:

No tener nuestro propio espacio físico para reunirnos fue una limitante durante los talleres. Tuvimos la suerte de encontrar personas que nos ayudaron a conseguir lugares: en una sede del consejo vecinal y luego en una sala de eventos de la iglesia católica (en Chile), en el Club Social de Innovación Balcarce e INTA (en Argentina). Pero la falta de un espacio que pudiésemos sentir nuestro tuvo el inconveniente de que no podíamos, por ejemplo, hacer cumplir un código de conducta e invitar a quienes quisiéramos. Por ejemplo, ciertos grupos no han sido tradicionalmente bienvenidos por la iglesia católica, grupos que nos habría encantado tener como colaboradores (tal como la comunidad LGBT).

Cómo lo abordamos:

No lo abordamos.

Ideas que nos llevamos:

Al mismo tiempo que se trata de un problema, una parte esencial de involucrarse con personas que no viven cerca y con quienes no estás estrechamente relacionado es ir a “sus” espacios y jugar allí, en lugar de invitarlos a una pequeña burbuja que les es ajena.

Tal vez una combinación de lugares para los talleres podría ser una buena idea, tener nuestro propio espacio para poder invitar a los “intocables” a jugar con los poderosos (y no tan poderosos), pero también ir a lugares donde nos invitan y/o lugares que nos saquen de nuestra zona de confort.

5. Infraestructura básica

El problema:

El acceso a computadoras, a una conexión a internet, a infraestructura de construcción adecuada (con elementos básicos como inodoros) a menudo no está disponible en el tipo de áreas urbanas donde realizamos muchos de los talleres en 2017 y 2018. Estos servicios básicos, que se dan por sentado en tantos contextos donde se discute de “ciencia abierta” y hardware científico abierto, no son una realidad para muchos que necesitan o les encantaría involucrarse en la ciencia. Entonces, ¿qué tan abierto es lo que estamos haciendo realmente? Estamos publicando las guías de construcción en criollo haitiano y en español, pero eso no significa que sean accesibles para las personas que necesitan conocerlas. Fue frustrante ver a algunos de los miembros de nuestro equipo entusiasmados y dispuestos a investigar más sobre drones y construir uno propio, pero sin poder hacerlo debido a que no tienen computadoras, e incluso si lo hicieran, no hay lugar para sentarse, conectarse, e investigar de forma gratuita o asequible.

Debido a la naturaleza de nuestros talleres, el acceso a Internet era clave. Excepto en un par de lugares como la UFRGS en Brasil o el INIA en Uruguay, no tuvimos una buena conexión a Internet durante los talleres. En Chile, esto se debió en parte a que el acceso a Internet es un servicio caro para el consumidor, imposible de costear para un pequeño comité vecinal. Por ejemplo, alguien de nuestro equipo paga el equivalente a 41 USD mensuales por un enrutador wifi al que puede conectar hasta 10 dispositivos y tiene capacidad de navegación limitada. Utilizamos ese enrutador en los talleres, pero muchas veces la conexión fue muy lenta, ya que las empresas de telecomunicaciones no invierten en infraestructura en los barrios más pobres y/o periféricos. No hace falta decir que tener una conexión lenta pone ansiosos a todas/os y dificulta las cosas.

Cómo lo abordamos:

En gran medida no lo hicimos. Lo único con lo que pudimos lidiar fue con tener conexión a internet. Llevamos nuestro propio enrutador a algunos talleres y otras veces usamos Internet desde nuestros teléfonos móviles, lo cual sí ayudó, pero no fue ideal, ya que no se pudieron conectar muchos dispositivos y la conexión fue lenta.

Ideas que nos llevamos:

Debemos enfatizar en las conversaciones durante los talleres que el acceso a infraestructura y servicios básicos es fundamental, y que nuestra lucha por el hardware científico abierto también debería ser una lucha por un acceso verdaderamente abierto a lo fundamental. ¿Qué implica esto? ¿Centros comunitarios de ciencias en todos los barrios?, ¿en universidades?, ¿en ambos?, ¿centros de internet libre en cada barrio? Por supuesto, las soluciones universales no funcionan, pero debemos pensar en cómo vincular la comunidad de hardware científico abierto con otras comunidades que luchan por “lo básico”.

Durante los talleres, algunos de nosotros empezamos a soñar con proyectos de redes de internet comunitarias. Estas son redes de Internet creadas y gestionadas por las mismas comunidades, no por empresas. Después de los talleres, estamos más convencidos de que este tipo de redes no son solo una opción en entornos aislados o rurales, sino también en áreas urbanas.

Para lo que viene con Vuela, asegurar una mejor conexión a Internet es muy importante y si no hay una buena conexión, entonces es importante hablar abiertamente y deliberadamente al respecto con los miembros de la tripulación. No solo sentir su ausencia, sino también discutir cómo es que Internet no es algo omnipresente, como a menudo se nos dice.

6. Género

El problema:

Se pueden imaginar. Tuvimos muy pocas mujeres que asistieron a los talleres, y nadie definido como no binario. En 2018, en los talleres de Argentina a veces teníamos solo una mujer en grupos de 5 a 10 personas, y en muchos talleres no tuvimos ninguna. En Chile, a menudo teníamos solo una o dos mujeres en grupos de 10 a 12 en total. Durante los talleres financiados por PROCISUR observamos que había una mejor representación femenina cuando las que estaban a cargo del grupo eran mujeres.

Cómo lo abordamos:

Hicimos poco. En Chile, en 2017, siempre tuvimos alrededor del 20% de mujeres en nuestros talleres, a menudo invitadas por una sola mujer (bastante líder) que asistió a casi todos los talleres. Ella no asistió a los talleres en 2018 y tampoco asistieron sus amigas o conocidas. En los folletos de invitación usamos nombres femeninos, “invitadas” tanto como “invitados”. También pedimos a los miembros de la tripulación masculinos que trajeran a sus amigas, hermanas, esposas e hijas, a lo que muchos respondían cosas como “no vendrían… para qué?”, “ no, no van a querer venir”, o “están ocupadas”. En algunos casos, no pudimos profundizar en las razones o tratar de convencerlos debido a las barreras del idioma. Otras veces, cuando el idioma no era una barrera, simplemente no hicimos nada para tratar de convencer a los participantes de que trajeran a mujeres a los talleres; no nos involucramos activamente en esas conversaciones.

Durante los talleres de pruebas del OVLI, hablamos con las personas a cargo de reclutar a los participantes y les pedimos especialmente que convocaran la mayor cantidad de mujeres posible. Solo en uno de los talleres la mitad de las personas fueron mujeres, en los otros la mayoría fueron hombres. No sabemos, sin embargo, si intentaron cumplir con la solicitud trayendo a cualquier mujer que estuviera disponible esos días (tuvimos esa impresión en un taller) o si realmente buscaron a quienes estaban interesadas en drones o tecnologías similares.

Ideas que nos llevamos:

Sin duda podríamos haber sido más creativos y haber hecho más. Incluso algo simple como iniciar una breve conversación sobre el tema con las y los participantes. El hecho es que se necesita una estrategia más integral para las actividades futuras, incluso si es una estrategia simple. Dedicaremos el tiempo requerido a esto la próxima vez. Queremos que los talleres de Vuela sean ambientes seguros y feministas.

También debemos asegurarnos de saber cómo abordar la situación cuando los hombres o las mujeres dicen cosas como: “¡ cuidado, una mujer está manejando!”, que es algo que escuchamos más de una vez en los talleres. Utilizamos la guía de facilitación de AORTA, pero leer una guía no es suficiente para saber cómo abordar temas como este en persona. Por lo tanto, podríamos necesitar un entrenamiento apropiado de facilitación feminista. ¿Conocen alguna buena opción? ¡Hágannos saber!

Hubo un episodio en el que se violó nuestro código de conducta, aunque no sucedió durante los talleres, sino después, en un almuerzo de despedida. Así que tal vez no se pueda decir que se violó el código. Tal vez significa que el código funcionó, y esta persona sintió que tenía que esperar hasta el final del taller para decir lo que dijo. Todavía tenemos que reflexionar sobre el incidente y la forma en que presentamos el código de conducta al comienzo de los talleres. No dimos espacio para discutir aspectos o detalles del código, y quizás en contextos en los que las personas están de alguna forma obligadas a estar presentes, se necesita tiempo o determinadas dinámicas grupales para digerirlo.

7. Ensalada de frutas

El problema:

Una ensalada de frutas, con peras, manzanas y muchas otras frutas más, puede ser deliciosa. Bueno, no logramos ofrecer el equivalente a eso, en términos de taller de drones, es decir, el acto de mezclar personas con antecedentes muy diferentes. Queríamos que investigadores o académicos trabajaran codo con codo con personas de orígenes radicalmente diferentes, personas sin conocimientos o educación tradicionales en tecnología y ciencias. En 2017 logramos hacerlo en el último taller del año. Y en 2018, sólo conseguimos esa combinación en un taller. Tuvimos la participación de académicos y no académicos, pero en diferentes talleres, en diferentes lugares. En cierto modo, realizamos actividades segregadas. Los investigadores no querían asistir a los talleres “en la ciudad”, mientras que los “no investigadores” no tenían ganas de ir hasta el lugar de la investigación, que en Argentina estaba fuera de la ciudad, sin un transporte fácil.

Cómo lo abordamos:

Decidimos que, ante todo, queríamos que la gente asistiera y siguiera asistiendo a los talleres y trabajando en los cambios necesarios en el diseño del dron, contribuyendo con su conocimiento. También enfatizamos, en cada taller, que se estaban llevando a cabo otros talleres con diferentes personas y que todas las contribuciones eran igualmente valiosas. Para eso, primero comenzamos a usar la función de “issues” en GitHub (una especie de lista interactiva de tareas pendientes), para hacer un seguimiento de lo que se iba haciendo (y especialmente quién lo hacía), y tratar de brindarles a los participantes formas de de interactuar.

Ideas que nos llevamos:

Definitivamente hay maneras de incentivar a las personas para que se junten con “personas diferentes” en talleres como los nuestros. Lo que se necesita es una estrategia, y para crear una estrategia necesitamos tiempo para probar y volver a probar, probar diferentes formas de conectar con comunidades o grupos, y esto significa dinero. Por ejemplo, podríamos haber ofrecido un viaje gratis para que la gente de la ciudad fuera a INTA u ofrecer a los investigadores llevarlos todos juntos al Club Social de la ciudad, o contratar a personas locales para que sean nuestros conectores locales, y finalizar algunos talleres con comida y bebida para crear un ambiente “festivo”, lo que sin duda ayuda a crear vínculos y romper barreras.

8. Facilitación

El problema:

Hacer facilitación en talleres de aprendizaje colaborativo no se valora lo suficiente. En general, no se habla de lo importante que es facilitar, sino sólo de enseñar, moderar o presentar. Las actitudes hacia el aprendizaje que la mayoría de las personas muestran en los talleres nos hablan de un sistema educativo que fomenta principalmente la pasividad. Y estas no son barreras fáciles de derribar. La expresión más común que se escuchó al principio de los talleres fue: “oh, no puedo”, “oh, no sé”, “no soy bueno/a en esto”.

Cómo lo abordamos:

En cierto modo, todo el proyecto en sí es un intento de refutar estas nociones de cómo se lleva a cabo el aprendizaje y quién puede aprender, quién no, y quién enseña. Evitamos el uso de pizarras, powerpoint y casi cualquier cosa que le recordara a las personas un aula típica. Utilizamos una guía de facilitación, pero que no es específica para talleres como el nuestro, por lo que tomamos el consejo general. Por lo tanto, hicimos un esfuerzo consciente para aprender lo que parecía funcionar de un taller a otro. Nuestra forma de involucrar a las personas en las tareas cambió bastante desde el taller 1 al taller 40.

Algunas cosas básicas que probamos:

  • ponerse de pie si la gente está de pie, sentarse si la gente se sienta, intentando no parecerse a un aula típica; pedir a las personas que se muevan alrededor de las mesas en lugar de sentarse en el mismo lugar todo el tiempo;
  • incitar a la gente a “explorar”, abrir cajas y bolsas con partes y componentes, y pensar ellas mismas para qué podrían ser útiles, en lugar de seguir una serie de instrucciones;
  • enfatizar que nosotros (los facilitadores) no somos maestros o profesores, sino pares. Esto último fue difícil, hay actitudes muy arraigadas respecto de lo que se supone que sucede dentro de un espacio de aprendizaje: algunas personas que “saben” cosas y otras personas que no.

En general, nuestra última técnica iterada, que usamos en los talleres de pruebas de OVLI, es llevar la táctica de “averígualo tú mismo” al extremo: por cada pieza o componente electrónico que los participantes sacan de la caja, preguntamos para qué sirve y les damos tiempo suficiente para tratar de descubrir la respuesta entre ellos, crear hipótesis, contradecirse, reír, o simplemente fantasear… Como un rompecabezas colectivo progresivo, intentando nosotros mismos no tocar los componentes, dejando que el resto toque todo lo posible.

Ideas que nos llevamos:

Probar nuevas técnicas de participación durante los talleres requiere que seamos buenos facilitando. La sistematización de nuestros métodos es urgente, para ver claramente qué funciona mejor, qué podría replicarse y qué no de un taller a otro o de una configuración a otra. Pero si fallamos por el lado de la facilitación, será difícil evaluar si ciertas técnicas no funcionan porque somos malos facilitadores o por alguna otra cosa. Ser un buen facilitador parece ser una habilidad prioritaria para lograr el impacto que queremos lograr.

9. Narrativas

El problema:

Mencionábamos anteriormente que las narrativas de la ciencia, de la creación de conocimiento, de los instrumentos y quién los hace son muy sólidas y profundas. A menos que propongamos nuevas historias, que sean convincentes y con las cuales la gente se pueda identificar, no podremos impulsar la ciencia abierta como imaginamos. En nuestros talleres, las personas normalmente no iban y agarraban cosas y comenzaban a probarlas, a menos que nosotros insistiéramos e insistiéramos mucho. La mayoría de ellos ni siquiera se sentían seguros al abrir las cajas y las bolsas. Los niños del Club Social, aquellos que esperábamos fuesen más flexibles o adaptables, seguían llamándonos “profesor” a pesar de que les insistíamos que no lo hicieran.

Cómo lo abordamos:

Esperábamos que la idea de que todos pueden ser parte del proceso de creación de drones se mostraría mejor a través de las acciones y los resultados de los talleres. Si los miembros de la tripulación lo vieron de esa manera o no, es algo que todavía tenemos que descubrir.

Ideas que nos llevamos:

Al igual que con otras barreras, no alzamos la voz lo suficiente para tratar de superarlas. Pensamos que la próxima vez deberíamos hablar más sobre las estructuras que pretendemos ayudar a cambiar: cómo aprendemos, por qué la colaboración es clave, la producción de conocimiento, la ciencia. Pero ¿cómo? ¿Quizás el uso de imágenes, fotografías o videos podría ser parte de la estrategia?

10. Poco financiamiento equivale a poco de todo

El problema:

Financiamiento, eso lo dice todo. Conseguimos financiar nuestras actividades en 2017 y 2018, pero no financiar el tiempo dedicado al proyecto (sólo viajes y alojamiento fueron cubiertos por los financiadores). La financiación de salarios es esencial para que los proyectos sean sostenibles y alcancen su potencial. Si no hay dinero para pagar los salarios, los que terminan involucrados son los “sospechosos de siempre”, los académicos que ya tienen un salario que paga por participar en estos proyectos o los que tienen recursos financieros que les permiten donar su tiempo. Necesitamos que también los sospechosos no habituales trabajen en proyectos como este, y para eso necesitamos salarios.

Cómo lo abordamos:

No lo abordamos.

Ideas que nos llevamos:

Un proceso que a menudo no se prioriza es la convocatoria, que puede parecer secundario en la prisa por completar tareas, pero que en realidad es esencial. Convocar a la combinación correcta de personas, como todo lo demás, requiere tiempo para planificar y dinero para ejecutar.

Buscar mayor y/o mejor financiación. Ser explícito y enfático en esto.

Obtener financiamiento que incluya salarios es más difícil o incluso imposible cuando no se es una organización legalmente constituida. Quizás debamos considerar convertirnos en una. O no. ¿Qué piensan?

Continuará…

Algo que no incluimos aquí es una reflexión detallada de las decisiones metodológicas que tomamos en el camino. Eso requiere otro artículo/informe en sí mismo. Y probablemente también faltan algunas otras cosas que aprendimos.

Estamos tratando de tener todo esto en cuenta para planificar nuestras acciones futuras.

Mientras tanto, seguimos volando…

Ciencia y tecnologías abiertas y libres. www.vuela.cc

Ciencia y tecnologías abiertas y libres. www.vuela.cc