Memoria PyConES 2013

_images/logo.png

Esta memoria documenta el proceso de organización de la Python Conference Spain (PyConES) en su primera edición, celebrada del 22 al 24 de noviembre de 2013 (http://2013.es.pycon.org/).

El objetivo es dejar constancia del desarrollo, comentar los aciertos y errores cometidos y servir de referencia a los organizadores de futuras ediciones.

Contenidos

Resumen y objetivos de la PyConES 2013

PyConES 2013 surge con el impulso por la creación de la Asociación Python España. En enero de 2013 un grupo de asiduos a las charlas de Python Madrid decidimos crear la Asociación Python Madrid. Una vez nos pusimos en marcha, vimos que parecía más apropiado crear una asociación de ámbito nacional, dado que no había, y que era una forma sencilla de congregar a los aficionados a Python dentro de España.

Qué es PyConES 2013

PyConES es la Conferencia sobre Python en España. Sigue la idea de convenciones similares en otros países, las PyCon. Aunque no hay un formato que tengan que seguir las PyCon, sí que hay un factor común: evento de charlas y talleres en torno al lenguaje de programación Python. Es un evento que reúne sobre todo a desarrolladores y aficionados, y con charlas esencialmente técnicas.

Objetivos

Hemos cumplido varios objetivos en esta primera PyConES:

  • ser el evento inaugural de la Asociación Python España.
  • reunir a las pequeñas comunidades de ámbito local que no teníamos nociones de otros grupos. En este mismo sentido, también hemos podido tomar el pulso a la comunidad y confirmar que la Asociación Python España viene a llenar un hueco que hacía falta llenar.
  • generar un punto de encuentro para aficionados y profesionales de Python.
  • crear un evento sobre Python con buen nivel, que anime a seguir desarrollando y aprendiendo este lenguaje.
  • conseguir la atención de empresas, hasta el punto de que varias hayan patrocinado el evento.
  • crear un ambiente cómodo y no excluyente para quienes asistieran de alguna forma.
  • poner a disposición de cualquier persona todo el material de las charlas mediante grabaciones en vídeo y el material usado en la presentación misma.
Diversidad y código de conducta

La PyConES se hizo eco del código de conducta de otras PyCon acogiéndose a un texto que reunía muchas de las nociones que había en otros eventos de este tipo. El objetivo subyacente era visibilizar la intención de hacer un evento libre de prejuicios o exclusiones. La idea de hacer hincapié explícito en estas directivas es de alguna forma novedoso en este tipo de eventos en España, y desde la organización estamos muy contentos con la buena acogida, y con el ambiente que se dio durante todo el fin de semana.

Podéis leer el código de conducta en la web de PyConES.

Creación de la asociación

Escrito por el presidente de la Asociación Python-España, Pablo Lobariñas

El germen se empezó a gestar allá por el otoño de 2010, cuando Kiko Correoso empezó a ‘molestar’ por las listas de cara a crear un grupo de pythonistas de la zona centro del país. En noviembre de ese mismo año, Kiko creó una lista de la zona centro que más tarde pasaría a llamarse Python-Madrid. Ese mismo noviembre hicimos la primera quedada y nos presentamos J. Cea, P. Lobariñas, Lasizoillo y K. Correoso. La primera reunión formal se realizó en febrero de 2011. Aquí quiero agradecer la amabilidad de Eduardo Ferro y Alea Soluciones, que nos cedieron sus oficinas para este primer encuentro. A partir de aquel momento, las reuniones se sucedieron mes tras mes, también fuímos cambiando de local. Además de las oficinas de Alea Soluciones, pasamos por O2C, Aurigae, Tuenti, Tetuan Valley y Kaleidos, que ha sido nuestro lugar de encuentro más habitual, desde sus primeras oficinas en Príncipe de Vergara, hasta las actuales en la zona de la Guindalera. Sin duda, Kaleidos y su gente (Jesús Espino, Andrey Antoukh, Yamila Moreno) han sido elementos clave para la consolidación de un grupo permanente, además de habituales como Jesús Cea, Kiko Correoso, Juan Luis Cano, Alberto Chamorro, JJ, Lasizoillo, por nombrar algunos.

Todo esto nos lleva a Febrero del 2012, cuando se propone en la lista de correo crear un logotipo del grupo Python-Madrid. El diseño de Rubén Hidalgo y las aportaciones al mismo de Juan Luis Cano tienen una aceptación casi instantánea. Se imprimen con él camisetas que se distribuyen a gente de Madrid, principalmente, y a otros puntos de España, incluso se envían a Estados Unidos, pues a la PSF les han gustado. Este pequeño detalle marca un punto importante, pues muestra que hay interés por hacer cosas, y gente interesada, no sólo en Madrid, sino por toda España.

Se había comentado más de una vez, de manera informal, la posibilidad de montar algo tipo PyCon, pero es entonces cuando esa idea empieza a tomar forma real. Uno de los primeros pasos para ello es crear una asociación, una entidad jurídica que respalde un evento de esas características. Comienzan los contactos y se lanza la idea por las listas, donde gente de distintas partes de España la acogen muy positivamente.

Durante el verano de ese año P. Lobariñas elaboró los Estatutos y el Reglamento de la futura asociación, después vinieron algunas reuniones y la firma del Acta Fundacional, que viajó por toda España, recogiendo las firmas de los quince socios fundadores. Finalmente la asociación Python España queda registrada el 13 de junio de 2013, con fecha de fundación del 22 de enero de ese mismo año, no sin algunos contratiempos a la hora de presentar la documentación en la Administración Pública que pudieron salvarse sin mayor problema.

Los preparativos para la PyConES 2013 ya estaban en marcha desde mucho antes, y Yamila Moreno trabajaba contra reloj para tener todo organizado para Noviembre de este mismo año, cosa nada sencilla. Al final, gracias a su gran trabajo y el de muchos voluntarios todo salió estupendamente.

Si bien la asociación nace en primera instancia para hacer posible la PyConES 2013, su intención es apoyar y promover el uso del lenguaje Python en España, y la PyCon es una forma de hacer eso posible. Prueba de ello, es que tras la misma, varias comunidades han organizado encuentros y reuniones: Valencia, Barcelona, Castellón, pero hay muchas más cosas que la asociación puede y debe hacer. Apoyar a las distintas comunidades que se reparten por toda España es una de ellas, hacerlas visibles, y promover su crecimiento, para que en el futuro podamos disfrutar de una comunidad Python fuerte, de la que puedan surgir nuevas iniciativas, que permitan nuevos eventos tipo PyConES o incluso una EuroPython, ¿por qué no?

Por ello estamos trabajando en una nueva web, calendario de eventos, y otras acciones.

Lo que ocurra a partir de ahora está en nuestras/vuestras manos.

Elección de la sede

La elección de la sede fue la primera tarea que acometimos; el lugar donde se realiza una conferencia otorga ciertas características a la propia conferencia: tipos de aulas, comunicaciones entre aulas, el entorno, etc.

Los requisitos que debía cumplir la sede eran:

  • Abierto en fin de semana. Se decidió que era mejor celebrar la conferencia en fin de semana que entre semana.
  • Que no pusiera problemas a la hora de cobrar entrada o contratar un catering.
  • Una sala con capacidad para unas 400 personas. Usada en la apertura, lightning talks y cierre de la PyConES 2013 ya que permitía incluir a todos los participantes en una misma sala.
  • Diversas aulas con aforos entre 100 y 250 personas. Los tres tracks se celebraron en estas aulas.
  • Wi-Fi.
  • Zonas amplias donde poder realizar los descansos (comidas, cafés,...).
  • Zonas de paso entre áreas donde los patrocinadores pudieron colocar sus stands.
  • Zona de parking.
  • Comunicación con transporte público.

Al principio la elección estaba entre Madrid, Sevilla y Zaragoza. En Madrid se habían mirado ya varias posibilidades durante el verano de 2012 (Pablo Lobariñas, Eva Morano, Juan Luis Cano).

  • Eva Morano se puso en contacto con el ayuntamiento y varios centros de innovación: Madrid on Rails, Vaguada, La Catedral de la Innovación. La mayoría quedaron descartados por ser demasiado pequeños. Las negociaciones con el ayuntamiento quedaron estancadas y a partir de cierto punto la persona de contacto dejó de contestar.
  • La ETSI Aeronáuticos de la UPM no acogió la idea con entusiasmo y puso unos requisitos incompatibles con la conferencia. La ETSI Navales quedó descartada por ser demasiado pequeña.
  • El Medialab Prado se mudó a un edificio más pequeño y resultó ser demasiado caro.

Por otro lado, Javier Gutiérrez de Sevilla ofreció la US pero quedó descartada por el precio, y varias personas en Zaragoza ofrecieron varios espacios y buenas condiciones. Finalmente la EU Informática de la Universidad Politécnica de Madrid ofrecía las condiciones más ventajosas: sin problemas de aforo, razonablemente bien comunicado con el centro, experiencia en la organización de eventos tecnológicos, coste de las instalaciones muy bajo. En Madrid además estaba el epicentro de la organización y se pensó que para la primera edición sería más conveniente.

La Escuela Universitaria de Informática de la Universidad Politécnica de Madrid se volcó con este proyecto y nos ofreció su experiencia como sede anfitriona de otros eventos similares. Lo bueno de la sede:

  • La disponibilidad de varias aulas de distintos tamaños permitió distribuir a los asistentes de tal forma que ninguna sala se quedara pequeña y que ningún asistente se quedase sin poder asistir a una charla debido a excesivo aforo. La asignación de determinada aula a determinado track se realizó después de una encuesta realizada a los asistentes que compraron la entrada a la PyConEs a través de Ticketea y a través de su web permitieron el contacto por correo de forma explícita. A las personas que no autorizaron que la organización se pusiera en contacto con ellos no se les incluyó en esta encuesta previa.
  • Conexión Wi-Fi en todas las instalaciones.
  • Parking gratuito y suficiente para el aforo.
  • Los trabajadores propios de la UPM que estuvieron ayudando en todo momento.
  • La buena educación de todos los asistentes que se mostraron muy colaborativos de cara a recoger los restos de comida y demás después de cada comida, café, etc.

Lo malo de la sede:

  • Conexión Wi-Fi lenta.
  • La sede está apartada del centro de la ciudad y no dispone de zonas de servicios (bares, restaurantes, supermercados,...) cercanas a la misma.
  • Los pasillos estaban fríos si estabas trabajando en ellos durante muchas horas (personas encargadas de los stands) y las aulas estaban excesivamente calientes en momentos puntuales, aunque esto era más fácil de resolver al poder abrirse las ventanas de las aulas.

Cosas a mejorar:

  • El frío en los pasillos.

Gestión de tareas

Herramientas de gestión

  • Lista de correo: usamos el grupo de Google de Python España para la organización del evento. Desde aquí coordinábamos las reuniones del grupo, también las visitas. En la lista se proponían y debatían algunas ideas. También se usaba para hacer llamamientos a voluntarios.

Ventajas llegaba a muchos potenciales interesados, y al ser una lista pública, se daba transparencia a la organización. Desventajas al ser una lista de propósito general había mucha gente con intereses muy diversos. Esto dificultó la gestión de los implicados. Como recomendación para futuras organizaciones, sería mejor crear una lista exprofesso. Podría ser de acceso libre, pero la inercia ayudaría a que se inscribieran los interesados en colaborar.

  • Google Drive: en GDrive teníamos una carpeta con documentación compartida por los organizadores: presupuesto del evento, facturas, certificados, logos, presupuestos de proveedores.

Ventajas fácil comprartir la información entre varios. Inconvenientes al ser información no normalizada, había que tener bastante conocimiento de la documentación para ubicarse. Aplicación propietaria (la información está en servidores ajenos a la organización).

  • Web: en el panel de administración de la web teníamos el listado de empresas candidatas a patrocinio y llevábamos la gestión inicial ahí. También registrábamos aquí las propuestas de charlas.

Ventajas información fácil de gestionar con la administración de Django. Aplicación libre (la información está en servidores de la organización). Inconvenientes no es tan flexible como un repositorio de documentación.

  • Trello: con Trello montamos una especie de panel kanban de tareas asignadas a sus encargados y con el estado de la tarea. Teníamos varios paneles de Trello: financiación de ponentes, seguimiento de patrocinadores, otro para el horario, y uno general con tareas diversas.

Ventajas organización muy visual de las tareas. Inconvenientes Aplicación propietaria (la información está en servidores ajenos a la organización). Solo sirve para tareas pequeñas y atómicas.

  • Wiki Python Hispano: cuando el equipo empezaba a organizarse teníamos a nuestra disposición el wiki de Python Hispano. Sin embargo, el formato wiki no nos resultó útil así que lo dejamos en beneficio de otras herramientas.

En general, tener muchas herramientas tiene varios problemas: - dificulta la gestión de colaboradores - dificulta la gestión de la información pues no está unificada

En el caso de PyConES 2013, podríamos haber prescindido de la administración de Django y usar una hoja de cálculo para la recepción de propuestas y para los patrocinadores.

A cambio, diversificar con varias herramientas permite tener la solución adecuada para cada tipo de tarea. En definitiva, las herramientas dependen mucho de cada grupo organizativo.

Organización de las tareas

La mayor parte de las tareas fueron llevadas a cabo por el núcleo organizativo, formado por 4-5 personas. La decisión de qué tareas concretas había que realizar la tomaba normalmente una persona (Yamila) en acuerdo con el resto de equipo organizativo. Asímismo, el seguimiento de las tareas las realizaba Yamila.

En el caso de PyConES 2013 faltó experiencia en organización distribuida y casi toda la gestión surgió del equipo organizador desde Madrid. Consideramos que no es imprescindible que sea así y que con un poco de esfuerzo se podrían organizar tareas atómicas, fácilmente delegables.

Tareas realizadas

A continuación, un listado de las principales tareas que se realizaron en la I PyConES:

Logística

  • gestión del presupuesto: la información relacionada con el presupuesto se puede ver en Elaboración del presupuesto
  • patrocinadores: la información relacionada con los patrocinadores se puede ver en Patrocinadores
  • web: contamos con la ayuda de un diseñador que creó una web sencilla y mantenible. Tuvo muy buena acogida. Es importante tener una web desde pronto, desde donde poder distribuir la información a todos los interesados en el evento. Inicialmente era un Symposion, pero como no veíamos que nos fuera a resultar útil, la dejamos en una web Django. El código está disponible en:

https://github.com/python-spain/pycones-web

  • cátering: pedimos unos 10 presupuestos distintos. Tuvimos en cuenta el precio, la calidad, la cantidad, también pedíamos que nos pudieran ofrecer menús vegetarianos. Uno de los aciertos en este sentido fue conseguir que el cátering, ya que no era en cafetería, nos lo dieran en cajas individuales: resultó fácil de repartir y de recoger.
  • grabación: pedimos muchos presupuestos. Aquí nos encontramos muchísima variedad de presupuestosy precios, con distintas calidades y servicios.
  • cartelería: creamos 3 rollups (uno por cada track) con los patrocinadores, y también paneles con el horario para cada sala.
  • papelería: los welcome packs incluían trípticos e información útil impresa.
  • camisetas: sabíamos que las camisetas eran un elemento importante para los asistentes. Hicimos un concurso para el diseño y conseguimos un taller que nos las dio en muy buena calidad y que nos daba un modelo de tallaje para mujer.
  • welcome pack: para el welcome pack buscamos una empresa que nos ofreciera todo lo que queríamos: el tríptico, las chapas, las cartulinas para las comidas, la bolsa y el lanyard.
  • logística: tuvimos que organizar algunos detalles logísticos menores, como conseguir ordenadores para las ponencias, y pendrives para las slides. También telas para vestir las mesas de los stands y botellas de agua para los ponentes.
  • venta de entradas: buscamos varias empresas para la gestión de entradas. Finalmente nos decidimos por la que nos ofrecía mejores condiciones. Hacíamos seguimiento diario de la venta de entradas pues representaba parte del presupuesto y afectaba a otros aspectos de la organización.
  • call4papers: para el c4p creamos un equipo específico que recibió todas las charlas y votó y organizó los tracks. Para más información sobre el c4p, ver Selección de charlas
  • voluntarios durante la charla. Tuvimos dos tipos de voluntarios durante el evento:
  • voluntarios dentro de las charlas. Consistió en asistentes que ya tenían entrada y que se ofrecieron a la microgestión de las charlas: asegurarse de que funcionaba el proyector, dar la botella de agua para los ponentes, controlar el tiempo de las charlas, grabar las transparencias en el pendrive...
  • voluntarios de información. Buscamos voluntarios que no tuvieran entrada: a cambio de su ayuda en el stand de información, en las acreditacoines, o controlando la entrada al recinto, etc, consiguieron una entrada y pudieron asistir a charlas cuando no estuvieran atendiendo. Se hizo un cuadrante que asegurara que disponían de al menos la mitad del tiempo para asistir a charlas.

Comunicación

  • newsletter: creamos un boletín muy sencillo, con el que informábamos de novedades y dábamos los avisos pertinentes.
  • información útil. También generamos información útil para los asistentes: hoteles y transporte que les ayudaran a gestionar el viaje.
  • otros medios: para saber sobre las tareas de comunicación, ver Comunicación

Otros detalles

  • regalos: conseguimos una importante cantidad de regalos para los asistentes: libros, camisetas y planes en distintas plataformas de software.
  • cena de ponentes y patrocinadores. El viernes previo a la conferencia organizamos una cena de cocktail para ponentes y patrocinadores. Funcionó muy bien como antesala de la conferencia.
  • pybirras: el sábado por la noche, tras el primer día de charlas, nos juntamos los asistentes enun pub. Teníamos cervezas y picoteo patrocinados.

Elaboración del presupuesto

La elaboración del presupuesto tuvo dos vertientes fundamentales:

Organización de la información

La principal mantenedora y gestora del presupuesto fue Yamila Moreno. Dado que Yamila reconoció no tener experiencia en la gestión de presupuestos, la aproximación inicial fue una hoja de cálculo compartida. El documento fue creado por TODO en un formato sencillo donde pudiéramos ir gestionando entradas y salidas.

Conforme el presupuesto fue haciéndose más sofisticado tanto en conceptos como en cantidades, el documento se fue ampliando, conforme Yamila iba necesitando.

La hoja de cálculo ha sido siempre accesible. En sus primeras versiones, era de escritura para varios voluntarios; pronto vimos la oportunidad de hacer el proceso transparente y pusimos acceso de lectura a quien lo solicitara. El siguiente paso fue hacer que fuera de lectura para cualquiera que tuviera el enlace, que fue distribuido con generosidad en las correspondientes listas.

En vista de que la principal encargada y también responsable era Yamila, tomó la decisión de quedarse ella como única usuaria con privilegios de escritura.

Actualmente, el presupuesto sigue estando accesible en modo solo lectur

Conforme el presupuesto fue haciéndose más sofisticado tanto en conceptos como en cantidades, el documento se fue ampliando, conforme Yamila iba necesitando.

La hoja de cálculo ha sido siempre accesible. En sus primeras versiones, era de escritura para varios voluntarios; pronto vimos la oportunidad de hacer el proceso transparente y pusimos acceso de lectura a quien lo solicitara. El siguiente paso fue hacer que fuera de lectura para cualquiera que tuviera el enlace, que fue distribuido con generosidad en las correspondientes listas.

En vista de que la principal encargada y también responsable era Yamila, tomó la decisión de quedarse ella como única usuaria con privilegios de escritura.

Actualmente, el presupuesto sigue estando accesible en modo solo lectura en la siguiente URL:

https://docs.google.com/spreadsheet/ccc?key=0AnZrjxQqa3mYdEJhT0tTbVl4NWVUbmxiWjIxNTRxRkE&usp=sharing

Junto a la hoja de cálculo, teníamos varias carpetas compartidas (en Google Drive) con las facturas emitidas y las facturas recibidas. El tesorero en ese momento (Andrey Antoukh) y Yamila Moreno se encargaban de generar las facturas numeradas y hacer seguimiento de los pagos correspondientes.

Organización del presupuesto

Además de cómo llevar la “burocracia” presupuestaria, hubo que decidir cómo gastar el dinero y cómo prever el presupuesto. Al ser el primer evento, y sin saber bien cuál iba a ser la acogida, optamos por una conferencia de presupuesto lo más bajo posible, de forma que el presupuesto no fuera impedimento para que viniera quien quisiera.

Esto significó que necesitábamos conseguir muchos patrocinios. Teníamos dos formas principales de financiación:

  • patrocinios
  • entradas de asistentes: pusimos una primera aproximación de 25€ para tener algún punto de partida.

Y muchas incógnitas sobre estas dos fuentes de financiación que condicionaron la forma en que planteamos los gastos:

  • ¿cuánto dinero nos va a entrar por patrocinio?
  • ¿se venderán todas las entradas? ¿cuántos asistentes tendremos?

Muchas dudas con las que lidiar a la hora de presupuestar el cátering o los welcome packs. También afectaba a otros temas incluso más importantes como la organización de tracks, tema que tratamos aparte.

Las dudas sobre las entradas las resolvimos sacando unas pocas en modalidad “Early bird” (un poco más baratas por ser con antelación). Tuvieron una acogida fantástica y eso nos dio una pista sobre la demanda que tendríamos. Al final, la demanda superó con mucho las expectativas y de hecho, no pudimos escalar el evento para dar cabida a todos los que querían asistir. En todo caso, teníamos bastante claro que podíamos contar con unas 200 entradas vendidas.

Los patrocinios eran más difíciles de prever porque intervienen muchas variables aparte del mero interés; requiere, por ejemplo, llegar a tiempo, antes de que las empresas gasten el presupuesto dedicado a eventos.

Finalmente optamos por un presupuesto incremental: teníamos bastante idea de en qué queríamos gastarnos el dinero, así que priorizamos estos conceptos y según veíamos que conseguíamos más financiación, íbamos añadiendo gastos. Establecimos qué era una conferencia viable:

  • 150 personas
  • charlas
  • cátering básico

y pusimos el precio final: 35€.

A partir de aquí, las entradas de dinero representaban ampliar conceptos a la estructura de la conferencia:

  • becas para ponentes
  • grabación de charlas
  • detalle para ponentes
  • welcome pack con camiseta
  • trípticos a color con los horarios
  • cartelería
  • cátering más sofisticado
  • regalos para asistentes
  • etc.

Patrocinadores

La búsqueda y gestión de patrocinadores fue algo caótica en su inicio: no sabíamos bien a qué tipo de empresas acudir, qué información podría resultarles interesante, cómo organizar los niveles de patrocinio.

Éramos 3 ó 4 encargados de conseguir patrocinadores. Teníamos un listado compartido con las empresas que se nos ocurrían que podrían querer patrocinar PyConES. Una vez que una empresa entraba en la lista, uno de los encargados se la asignaba y le escribía un correo inicial (teníamos uno estándar redactado). Este correo incluía un PDF muy bonito con la información relevante sobre la conferencia y los niveles de patrocinio.

El equipo organizador tuvo que tomar algunas decisiones:

  • ¿Qué niveles de patrocinio hay? En primera instancia se nos ocurrió poner ciertos rangos, pero se descartó rápidamente por el desequilibrio intrínseco que conlleva. Así que decidimos dejarlo en cantidades fijadas.
  • ¿Cuántos niveles de patrocinio? ¿Qué cantidad en cada nivel? Vimos que era innecesariamente complicado sofisticar mucho el sistema de patrocinios, y no veíamos que fuéramos a tener una mejor respuesta si el sistema de patrocinio tuviera más variantes.
  • Patrocinio y colaboración. Establecimos 4 niveles de patrocinio en forma de donación directa, y un nivel de colaboración donde pudimos dar visibilidad a otras formas de apoyo. Este nivel se incluyó en una etapa avanzada cuando nos dimos cuenta de que había muchas formas de colaborar que no tenían por qué implicar necesariamente donar dinero (difusión, regalos).
  • ¿Qué compensaciones por patrocinio dábamos? Hicimos un listado de las compensaciones que podíamos ofrecer. Cuanto mayor fuera el nivel, más y mejores compensaciones se tenían (siempre en modo incremental).

Contactamos con una serie de empresas tecnológicas internacionales (Dell, Pinterest, Softonic, HP, Disqus) que en su mayoría ignoraron nuestras propuestas. De Dropbox incluso obtuvimos un rotundo “Sponsorship, ignore” (a tener en cuenta para futuras ocasiones). Al final, como se puede ver en la lista de patrocinadores la mayoría del dinero vino de empresas españolas. Google hizo una aportación de bajo nivel, y además requirió cierto papeleo previo.

Una de las preguntas que más hacían, en los primeros correos que intercambiábamos con los patrocinadores candidatos, eran sobre números y estimaciones. Esto en nuestro caso era complicado de saber, pues no teníamos ediciones anteriores en las que fijarnos: cuántos asistentes, cuántas empresas, qué presupuesto estimado, etc. El próximo equipo organizador podría tener esta información en cuenta a la hora de preparar el material de marketing para patrocinios.

Otro de los fallos que nos achacaron fue a la hora de dar pases para las personas que iban a estar en el stand. Según algunos patrocinadores en otras conferencias se venden a precios más bajos o se regalan directamente, no dando acceso a las charlas. Para tener en cuenta para la próxima vez.

Comunicación

Las vías de comunicación principales con la audiencia fueron la cuenta de Twitter @PyConES y una newsletter periódica que se mandaba al correo electrónico y en la que se hacían resúmenes de la actividad reciente.

Además, se crearon varias cuentas de correo para atender a los patrocinadores, el formulario de contacto y las charlas. Se intentó contestar a los emails de manera rápida y personal.

En un momento dado se redactó una nota de prensa y se difundió a varios medios de comunicación generalistas y a revistas de informática. El resultado fue un fracaso absoluto, no habiendo conseguido que ninguno de los medios contactados la publicase. Probablemente fue un fallo a la hora de plantear la audiencia a la que nos dirigíamos: a través de Twitter alcanzamos bastante difusión y los medios generalistas tal vez veían la conferencia como algo demasiado específico.

Afortunadamente se consiguió contactar con el ayuntamiento para que difundiese la conferencia a través de La Catedral de la Innovación.

Tal vez podría haberse planteado tener un blog en el que publicar actualizaciones periódicas como hacen otras conferencias (EuroPython) y ofrecer la posibilidad de suscripción por correo electrónico. De este modo se cumpliría la misión de llegar a la audiencia interesada y de poder publicar noticias con contenido de cara al público.

Cuando empezó la conferencia se echó en falta un medio donde publicar cierta información y algunas personas se quejaron de un fallo en la comunicación a la hora por ejemplo de anunciar los talleres (solo se anunciaron por Twitter). En otros casos se recurrió a Gists de GitHub para difundir la información.

Registro

Desde muy pronto, vimos que no necesitábamos generar un sistema de registro para usuarios, porque toda la información era pública. Además, habíamos descartado montar plataformas de comunicación para asistentes, y lo que hicimos fue fomentar conversaciones abiertas en redes sociales.

De esta forma, no necesitábamos tampoco asociar el registro en la web con el asistente, y pudimos derivar toda la gestión de venta de entradas en una empresa externa. La propia plataforma generaba las facturas correspondientes, lo cual es una labor costosa en tiempo para los organizadores, tiempo que nos ahorramos y pudimos dedicar a otros temas.

Esta decisión fue acertada en general (recomendable repetir el procedimiento), aunque es cierto que contó con algunos contras como que al no tener control sobre las entradas, teníamos que simular compras manualmente para poder dar entradas de los patrocinadores.

Selección de charlas

En este apartado se define el proceso mediante el cual llegamos a la selección final de charlas que conformaron la parrilla final de la PyConES 2013.

Call for papers

El call for papers se abrió el 01 de Junio de 2013 y se cerró el 15 de Septiembre de 2013. Se solicitó que cada propuesta incluyese el título, el ponente o ponentes, correo de contacto, twitter y demás parafernalia social, un breve resumen de la charla, el nivel de la misma y una breve biografía del ponente.

Se recibieron un total de 82 charlas que, finalmente, quedaron distribuidas de la siguiente forma:

  • 30 charlas propuestas para el track básico
  • 29 charlas propuestas para el track avanzado
  • 23 charlas en el track científico

Cosas a mejorar:

  • El track científico surgió sobre la marcha al ver la cantidad de charlas relacionadas con esta temática. Por tanto, en el envío previo de charlas no existía la posibilidad de elegir que el ‘nivel’ fuera para el científico. Habría que anticiparse mejor a esto y obligar a los ponentes a seleccionar un nivel de charla ya que algunos no pusieron a qué nivel correspondía su charla y el comité de selección de charlas tuvo que improvisar basándose en la descripción de la misma.
  • ¿Mejor comunicación para informar sobre plazos? El tema de que el c4p se centrase en verano provocó que nos surgieran dudas pensando que quizá mucha gente estaría de vacaciones o volviendo de las mismas y con mucho trabajo acumulado y se olvidase de enviar su charla en plazo.
  • Para la recepción de las propuestas, sería mejor usar un formulario único, en lugar de un correo con la información. Esto facilitaría el conseguir la información y evitaría el “peloteo” de correos.

Proceso de selección

El proceso de selección se realizó de la siguiente forma:

  • Se pidieron voluntarios para coordinar el proceso. Se consideró que 5 era un buen número para formar este comité y se incluyeron dos personas como reserva en el caso de que alguno de los 5 no pudiese disponer del tiempo necesario. El comité de selección final quedó compuesto por (en orden alfabético) Andrey Antukh, David Barragán, Kiko Correoso, Alejandro Rodas y Fernando Salamero.
  • Se pidió al comité de charlas que definiese a que track iban a pertenecer las charlas donde no se definió el nivel.
  • A posteriori, al ver la cantidad de charlas relacionadas con el ámbito científico, se pidió al comité de charlas que definiera las charlas que pertenecerían al track científico.
  • Una vez definidos los tres tracks, se pidió que cada uno de los miembros del comité diese una primera valoración individual a cada charla pero pensando, a su vez, de una manera global sobre el evento en sí (pensando en el interés general, en la no repetición de tópicos, intentando abarcar todas las posibles temáticas,...). Esta primera valoración individual se hizo de forma independiente y sin que un miembro supiera las votaciones del resto de miembros.
  • Una vez disponibles las votaciones individuales de cada uno de los cinco miembros del comité de selección se juntaron las votaciones y se obtuvo una parrilla inicial de charlas para cada uno de los tracks.
  • En la siguiente fase se pasó a discutir la idoneidad de esa parrilla inicial obtenida para cada track. Hubo modificaciones para evitar charlas que, a priori, podían ser similares dejando la/s charla/s más votada/s dentro del track, moviendo alguna charla a algún otro track e incluyendo alguna charla cuyo tópico no estaba bien cubierto del global surgido de la votación inicial.
  • Comunicación final del comité de selección a los organizadores de los tracks finales.
  • Selección de charlas de reserva en el caso de que alguna charla se cayese de alguno de los tracks.

Lo bueno:

  • Lo difícil que lo pusieron los ponentes enviando charlas de temáticas interesantes, variadas y de calidad.
  • El comité de selección puso en todo momento lo mejor de si para intentar tener la mejor ‘PyConES 2013’ posible.
  • En general, hubo quorum y no hubo excesiva polémica durante el proceso de selección.
  • La compresión de algunos ponentes al no haber salido su charla seleccionada.

Lo malo:

  • La comunicación entre los miembros del comité de selección se realizó mediante correos, documentos compartidos y hangouts. Alguna decisión fue larga y cansada al tener que definir cosas mediante correos electrónicos cruzados (muchos) de forma iterativa para llegar a decisiones consensuadas, mediante hangouts que requerían que los cinco miembros estuvieran disponibles en el mismo espacio temporal y con acceso a los medios necesarios,...
  • La incompresión de algunos ponentes al no haber salido su charla seleccionada.

Cosas a mejorar:

  • El comité de selección, como ya se ha comentado, estaba formado por cinco personas. Este número creemos que es correcto para obtener una valoración de charlas con un mínimo de entropía pero, en algunos casos, es difícil de manejar ya que algunas pasos del proceso están limitados por la respuesta de todos los miembros y si alguno desaparece puntualmente el proceso no puede continuar provocando un alargamiento innecesario del mismo.
  • Después del c4p se dispuso de unos 10 días ‘útiles’ para hacer toda la selección. Habría que hacer una reflexión sobre si es necesario más tiempo para poder interactuar con las propuestas de los ponentes y poder resolver dudas que no quedan resueltas con el resumen que aporta cada propuesta o si es mejor ser práctico y tener un plazo corto e improrrogable para que el comité actúe con celeridad.

Ponentes internacionales

TODO - queríamos atraer gente internacional para dar más visibilidad mutua - idioma en que se daban las charlas (importante)

Becas

Una de las partidas presupuestarias que decidimos meter fue la de dar ayudas a los ponentes que lo pidieran, en concepto de transporte y alojamiento.

Desde el equipo organizador solicitamos ayuda financiera a la Python Software Foundation para dar estas becas a ponentes que vinieran de fuera de España. La PSF nos concedió 2500$ (1875€) para repartir entre 5 ponentes. Este dinero estaba íntegramente destinado a ayudar a ponentes que vinieran de fuera de España.

Aparte, gracias al presupuesto, pudimos completar estas 5 dotaciones, y elevarlas hasta 500€ según fuera necesario. Además del presupuesto de la PSF, pudimos destinar otros 2175€ a becas para ponentes (de España o fuera).

Del presupuesto de 4050€ destinados a becas para ponentes, se pudieron entregar (contra tickets o facturas) 3030€.

Hubo algunos casos en los que nos pidieron ayuda financiera, pero la que dábamos por cada ponente no llegaba a ser suficiente. Nos encontramos ante la tesitura de elevar una única dotación a más de 1000€ (para un ponente que ya tenía charla seleccionada): no fue fácil la decisión, pero el equipo organizador decidió que no era apropiado elevar tanto la dotación de una única persona.

Feedback

Obtención de feedback

Para conseguir opiniones sobre el evento añadimos una encuesta en el welcome pack. Y para animar a los asistentes a rellenarla, la encuesta venía con la opcióin a participar en el sorteo. De forma que los que querían participar, tenían que entregar aparte la encuesta.

Durante la redacción de esta sección, aún no está procesada la información extraída de estas encuestas.

Conclusiones

  • aciertos y errores más importantes
  • qué hemos aprendido
  • evaluación general: interna y externa

Cifras

TODO - cuántos asistentes - cuánto dinero - dinero en patrocinios - número de patrocinadores - mujeres - cuántos correos

Futuro

  • en la redacción de esta sección seguimos sin equipo organizador para pycones 2014, aunque hay interés.
  • las empresas muy interesadas
  • otras opciones de evento: idioma, dinero, talleres