3º Hackathon: lecciones aprendidas

Aviso: Este es un post antiguo, puede que su información esté desactualizada. Si está buscando algo sobre un evento actual, tenga en cuenta que puede que este no sea el que busca.

Hacer un hackathon no es fácil, pero merece la pena. Ninguno es perfecto, pero en cada uno se sacan una serie de conclusiones que nos pueden servir (aunque a veces no) para el siquiente. Cada uno es diferente, y de este hemos sacado las siguientes conclusiones.

• Este hackathon ha sido un fracaso que en realidad ha parecido un éxito. Las fotos muestran una gran cantidad de público, y de hecho ha habido unas 50 personas más alguna que se ha pasado de forma efímera; es más del 50% de los inscritos, lo que es excepcional. Pero lo cierto es que había más personas de fuera de informática que de dentro. Si no hubiera sido por la cantidad de traductores que nos lograron traer Ruth Burbat y Eugenia Arrés, los proyectos habrían atraído uno, dos o quizás tres informáticos. Es cierto que eran muchos proyectos, pero la lección aprendida es que tenemos que intentar difundir mejor, tanto la oficina como los propios proyectos, el hackathon entre nuestros compañeros. Lo cierto es que, como ya resulta habitual, la presencia de profesorado y graduados/doctorandos de la ETSIIT ha sido nula, y si los profesores no difunden nuestras actividades entre sus alumnos, no vamos a ningún lado
• Los créditos, como siempre, son una espada de doble filo. Aunque se han solicitado créditos para la ETSIIT, no se ha difundido este hecho, para que los créditos sean un premio a los que quieren asistir por otra razón, no para los que no tienen otra razón para asistir. Eso ha restado asistentes, claro, pero los asistentes informáticos que hemos tenido han sido entusiastas y comprometidos. Hay que mantener un equilibrio entre calidad y cantidad, y no sé si se habrá tomado la decisión correcta optando por la cantidad.
• El año pasado comentábamos que el hackathon era para informáticos, y lo cierto es que, pese a las apariencias, sigue siendo así. Una vez más, la calidad y cantidad de gente que ha asistido de traductores oculta el fracaso por atraer personas de otras carreras. Incluso ofertando créditos para Bellas Artes, Comunicación, y haberlos solicitado en Ciencias, nadie de esas carreras se ha inscrito siquiera. Falla la comunicación, quizás, pero tampoco tenemos canales para poder publicitar cosas en cada una de las facultades, incluso en las que hemos pedido. La conclusión sigue siendo prácticamente la misma: hay que concentrarse donde sepamos que va a tener cierta repercusión.
• La preparación de los proyectos es fundamental, y el liderazgo de los mismos también. Es esencial llegar al hackathon con ideas bien claras de lo que quieres hacer y cómo vas a hacerlo; una lista de tareas realista y que pueda ocupar a todo el mundo. La lista de tareas tiene que estar abierta para redibir a personas de toda procedencia y conocimientos; aunque lo más probable es que vengan sólo informáticos, también pueden venir de primero de grado y no saber demasiado
• Tener siempre copia de seguridad, incluso de los procedimientos: ni siquiera se puede contar con que la Internet funcione. En esta ocasión se cayó la forja de RedIris el mismo fin de semana, y hubo que recurrir a otros métodos. Skype, Whatsapp, teléfono de dial rotatorio, todo preparado para que en caso de no poder verse físicamente el fin de semana se pueda seguir trabajando y eventualmente hacer una buena actividad en la forja
• La formación sigue siendo imprescindible: desde alguien que explique qué es el sotware libre desde 0, hasta alguien que cuente cómo funcionan los sistemas de control de fuentes o metodologías ágiles; si varios proyectos tienen herramientas comunes(Python, Django), identifícalo y consigue que alguien dé una charla sobre el tema
• Preved material informático para las personas que no se lo lleven: unos cuantos portátiles con software usable directamente, o un aula de prácticas que se pueda usar. Recordad que aunque todo el mundo haya recibido información al respecto, es posible que alguien, por error o simplemente porque no disponga de él, no lleve su portátil para trabajar. Si tenéis material para prestar, usadlo para esto; y comprobad previamente que esté en correcto estado de funcionamiento.

Con todas las lecciones buenas y malas aprendidas, sigue siendo una experiencia muy interesante, tanto para los del proyecto, como para los asistentes, que se convierten en cantera para participar en el concurso de software libre en años sucesivos.