Archivo de la etiqueta: equipo

Reflexiones sobre eventos (que aprendí en una WordCamp)

La cuarta vez que expuse en una WordCamp, allá por el año 2009, no lo hice solo. De nuestro equipo hablábamos los tres, y en su primera vez Rocío me pidió que le echara una mano con su ponencia. Esa ponencia a dos manos tuvo reacciones curiosas. En esa WordCamp, los comentarios del público hicieron que pensara mucho acerca de cómo hacíamos las cosas y cómo debíamos hacerlas en la interacción ponente-público. Y mi charla en solitario, con la que masacré una charla que vino inmediatamente después, también hizo que me empezara a plantear algunas cuestiones acerca de la organización.

Cuatro años y muchos eventos después, después de haberlas puesto en práctica y haberlas perfeccionado bastante, y aprovechando que empieza de nuevo la temporada de eventos, las comparto con vosotros.

El anfitrión o anfitriones

Un anfitrión en un evento tiene mucho trabajo. Si bien es el centro de muchas cosas, durante el evento tiene que estar lo más disponible posible y rodearse de muy buena gente para que todo llegue a buen puerto. Aquí van las ideas que he ido recopilando a lo largo del tiempo.

  • El anfitrión es sólo el impulsor de una idea. Es todo un equipo el que la desarrolla. La flexibilidad en ciertos aspectos es imprescindible.
  • Delegar es importante. Todo lo que no sea imprescindible que lo haga el anfitrión, hay que delegarlo. No es que el anfitrión no haga nada. Es que tiene la obligación de controlar la visión global del conjunto. Y si está ocupado todo el tiempo en tareas menores (aunque imprescindibles) , pierde esa perspectiva.
  • Tiene que procurarse un equipo y un cuerpo de voluntarios bien preparado y dispuesto. Los voluntarios son imprescindibles. Sin ellos y sin su disposición ningún evento saldría tan bien como salen.
  • Hay que cuidar detalles con el equipo y los voluntarios. Camisetas, comida, espacios de relax, horarios cerrados desde el primer momento para que puedan organizarse…
  • Siempre que se pueda, hay que procurar tener una sonrisa y, sobre todo, no transmitir estrés. El anfitrión debe ser quien ofrezca paz y tranquilidad al resto del equipo.
  • Cuida que tus expectativas sean siempre sobre elementos cerrados y confirmados, bien seguros. Es siempre mejor que tus asistentes se lleven una grata sorpresa, a que se vayan a casa con un sentimiento de frustración.  Algo tan simple como esto puede decidir la continuidad de tu evento.
  • Haz encuestas en la web. Hay gente que puede no querer contar cosas, pero que puede proponer temas interesantes. Permite que los propongan y, en caso de ser interesantes, busca un ponente que los cubra. Así no sólo tu evento será más rico, sino que estarás dándole un medio de participación a tus asistentes.

Sobre los espacios:

  • Mi experiencia dice que se debe intentar procurar un espacio de networking o usos múltiples para las post-charlas.

Durante el evento:

  • El anfitrión debe estar lo más disponible posible.
  • A ser posible, debe asistir a todas las charlas. Si hay dos salas, debería haber al menos dos anfitriones que puedan realizar ese trabajo.
  • En las charlas, el anfitrión tratará de poner en valor al ponente, sirviendo de apoyo para hacer preguntas sobre puntos que no han quedado claros (para que la audiencia se entere mejor) y aclarando cuestiones que no se refieran al campo que cubre el ponente. Es el momento de hacer valer nuestra experiencia (o nuestra preparación previa sobre el tema –ver sección de equipo–), haciendo que el ponente luzca.
  • En todo momento  se cuidará que el ponente sea el protagonista de la charla, nadie más. No permitas las reflexiones, sólo preguntas, en el tiempo de preguntas.
  • Se intentará procurar un espacio donde, si quieren seguir la conversación, puedan hacerlo. De esta forma, si se pregunta algo que conllevaría demasiado tiempo o que necesitara de otros medios no disponibles en la sala en ese momento, se puede resolver inmediatamente después en las zonas habilitadas al efecto. El anfitrión hará de catalizador proponiéndolo en el momento.

El equipo y los voluntarios

El equipo tiene labores fundamentales dentro del evento. A las que tenga asignadas dependiendo del tipo de evento, yo sumo las siguientes:

  •  El equipo debería revisar todas las ponencias con algún tiempo de antelación. De esta forma,
    • evitarán que se pisen contenidos, permitiendo además a los ponentes tener más tiempo para desarrollar otras ideas o conceptos evitando la repetición.
    • permitirá tener todas las ponencias disponibles antes del evento, lo que es una ventaja organizativa a la hora de preparar las proyecciones o vídeos.
    • permitirá que los anfitriones o el equipo de apoyo (a veces denominado sombra) se puedan preparar el contenido en caso de tener que sacar de un apuro a algún ponente poco experimentado.  Los nervios a veces traicionan y no está de más tener a un equipo preparado que te pueda hacer de backup.
  • El equipo debe salir de fiesta/cena al menos la noche antes del evento. No es casualidad que en muchos eventos haya una cena de voluntarios la noche antes de empezar el evento. La confraternización y la confianza es un elemento de valor incalculable a la hora de trabajar bajo presión.
  • Para absolutamente todo, tened un plan B. Nosotros en nuestros eventos hemos aprendido que, para las cosas críticas, es bueno tener hasta plan C y D. Es suficiente con un protocolo de ejecución.
    • El ejemplo más común. Wi-Fi falla. Para cubrir a todos los asistentes necesitaríamos comprar (número) modem USB de (marca) con tarjeta (características). El mapa de ubicaciones sería (éste). Los anunciaríamos en twitter y en (pantallas, ubicaciones, impresiones en papel). La configuración para los modems es (configuración). Tendría un coste de (coste). Están disponibles en (tienda1) y en (tienda2). Los horarios de las tiendas son (horarios). En caso de ocurrir el domingo, utilizaríamos las redes móviles de los organizadores y equipo. (configuración de las redes).

El ponente

Durante mucho tiempo fui de los que decían si sé de lo que voy a hablar. Hago las transparencias y luego allí las cuento. Luis ha conseguido, con el paso de los años, que ensaye mis ponencias. En este punto concreto, momento de iluminación fue ver cómo Lontzo Sainz se preparaba para presentar EBE Euskadi.

  • Prepara tu ponencia con tiempo. Date tiempo a releerla dos o tres veces, con algo de perspectiva, para mejorar su contenido.
  • Ensaya. Por muy controlado que lo tengas, vas a hablar delante de un montón de gente que en ese momento están ahí para escucharte. Muéstrales respeto y llévalo todo lo preparado que puedas.
  • Ensaya. Sí, otra vez. Esta vez, para controlar el tiempo. Si no va a caber todo, recorta.
  • Es mejor dos ideas bien explicadas que muchas ideas poco claras.
  • Deja claro lo que sabes, ejemplifica, y aprovecha el poder de la imagen. Una de las mejores charlas que he visto en mi vida dura 4:17 minutos ( wat ).
  • Asiste a las ponencias anteriores y entérate de qué van a contar los demás. En el último evento en el que estuve pude ver cómo alguien pasaba más de la mitad de su ponencia explicando algo a lo que se le había dedicado toda la ponencia anterior. Un evento es algo orgánico, montado con la participación de mucha gente. Si vas a llegar tarde o no vas a asistir al resto de ponencias, pregunta a alguien de organización si se ha hablado sobre los temas de los que vas a hablar y qué es lo que se ha dicho. Así podrás tratar a tu público como se merece.
  • Ve con tiempo. No eres Beyoncé. Hay gente a la que le gustará compartir tiempo contigo, o preguntarte algo fuera de la sala. O presentarte una idea. O que le orientes en algo. O tomarse un café. ¡Pero eso no es todo! También conocerás a un montón de gente con la que querrás hablar y compartir tiempo. Un evento dura lo que dura el evento, más las noches intermedias. No sólo tu media hora de gloria.
  • Comparte. Si la mitad de tus respuestas a las preguntas van a ser eso no te lo puedo responder, mejor no te subas al estrado. Esto no es una feria de exposición de productos. Es un espacio donde todos aprendemos de todos.
  • Añade bibliografía y/o cita fuentes. Lo mejor de un evento como una WordCamp es que te vas a casa con contenido para seguir profundizando durante un mes o más.

Los asistentes

Los verdaderos protagonistas de tu evento son los asistentes. Cuídalos, mímalos, y haz que estén cómodos. Que aprendan. Que disfruten. Pero eso no significa que todo valga. Hay reglas, y no hay ningún problema por dejarlas claras.

  • A un evento se va a aprender. Ve con la mente abierta.
  • Vas a pasártelo bien. Si vas a ir al evento para criticarlo, mejor quédate en casa. Todos te lo agradeceremos.
  • Está bien tener expectativas, pero recuerda que Murphy es un señor al que todos odiamos moderadamente. Tenlo en cuenta a la hora de ser crítico con la organización.
  • Infórmate de lo que vas a ver. Las webs de los eventos suelen tener bastante información acerca de cómo van a ser las ponencias, charlas o talleres. Eso te ayudará a decidir y a saber qué es lo que vas a ver.
  • Conectando con la anterior, no sólo los ponentes se preparan para el evento. Como asistente, conocer las ubicaciones y mapas, los ponentes, las charlas, y los espacios, es un trabajo previo que puedes hacer en casa. Así no te sentirás desorientado al llegar a tu evento y podrás disfrutarlo mucho más.
  • Pregunta al ponente lo que quieras saber sobre el tema que ha expuesto. Un ponente puede saber de muchas cosas. Ha ido a contar cosas sobre un tema específico y es lo que han ido a escuchar el resto de los asistentes. Si tu pregunta es sobre otro tema, utiliza los espacios designados para networking.
  • No hagas reflexiones. Si querías que el ponente y el resto de los asistentes te escucharan, la mejor forma de hacerlo era proponer una charla. No ocupes el tiempo de los demás. Es una falta de respeto hacia el ponente, hacia el resto de asistentes, y hacia la organización.

Espero que os sirvan para el futuro. Y si tenéis alguna más que añadir (que seguro que sí), los comentarios están abiertos.

WP 3.7, la distribución más esperada

Ayer tuvimos la primera reunión de muchas sobre WordPress 3.7. Mucho se habló de 3.7. y de 3.8 en la WordCamp San Francisco, y ahora los equipos se están poniendo en marcha.

Como algunos ya sabéis, las versiones de 3.7 y 3.8 se desarrollarán en paralelo. Y hay mucho que contar de ellas. 

WP 3.7

WordPress 3.7 es una versión que llamamos de control. No se verán muchos cambios de aspecto externo (casi ninguno, en realidad), pero tendremos muchos cambios internos interesantes. Y más que interesantes, excitantes. La lista es corta, así que vamos a repasarla.

Los líderes de proyecto

Esta versión de WordPress estará encabezada por:

  • Andrew Nacin. Uno de los programadores más veteranos de WordPress y Ninja Coder. 
  • Daryl Koopersmith. Forma un grupo junto a Nacin y a Nikolay Bachiyski que se hicieron famosos por levantar la mano cuando alguien preguntaba ¿quién cree que conoce todo el código de WordPress? Es el creador del Elastic Theme. 
  •  Jon Cave. Experto en seguridad, entró a formar parte del equipo de Automattic después de encontrar vulnerabilidades en una de las últimas versiones

¿Qué significa que ellos sean los Lead Developers de esta distribución? Que sólo ellos (y Aaron Campbell, Lead Developer de 3.6 durante los primeros días) pueden aprobar tickets. Esto hace que el flujo de trabajo sea mucho más ordenado y les permite tener una visión constante del conjunto.

El resto del equipo

Como ya ocurrió con WP 3.0, el equipo se amplía para esta nueva versión. Ayer en el chat apareció y se dio la bienvenida a mucha gente nueva. 230 usuarios con muchas ganas de compartir, aportar, ayudar, y hacer de éste un proyecto aún más grande.

La fecha de salida

La fecha de salida propuesta para la versión 3.7 de WordPress es a principios de Octubre. En palabras de Nacin, “tras WordCamp Europa y antes de mediados de mes, sobre la semana del 7 de Octubre”.

Como ya os comentaba antes, esta es una version que en desarrollo se denomina “de control”, y lo que se espera es que el ritmo de movimiento de los tickets suba mucho durante estas semanas. Y ya se está viendo en el trac. Lo propuesto son seis semanas de desarrollo, una alpha, una beta, una RC, y sacar la versión definitiva.

Desde mi punto de vista, el día de contribuidores del core de WordCamp Europa puede ayudar a cerrar los últimos detalles, ya que Nacin estará allí, y desde mi punto de vista, el cierre de fases de forma presencial ha ayudado mucho a la buena consecución de los mismos en las últimas versiones. Al fin y al cabo, las WordCamps también están para eso.

Language Packs, el futuro prometido

Hace más de dos años, JoeTheSor publicó un artículo en WordPress Ideas. En él planteaba que WordPress necesitaba una solución multiidioma. Una solución de verdad, nada de plugins. Algo con integración total. Y planteaba, desde una perspectiva que creo muy acertada, que algo tan importante como esto debería tener soporte continuo por parte de los propios desarrolladores del core de WordPress. 

Muchos votamos esa idea, y desde hace unos meses se etiquetó como algo realizable. Hoy tenemos el ticket #18200, y es una de las tres tareas principales para WP 3.7.

Creo que no tengo que explicaros lo importante que es para muchos de nosotros el poder utilizar un sistema multiidoma de forma nativa en WordPress. Estamos muy contentos, emocionados, y ya nos hemos ofrecido a ayudar en todo lo que podamos.

Automatic Updater, seguridad ante todo

Esta idea surge de un plugin de Gary Pendergast llamado Automatic Updater.

El software, en sus ciclos de desarrollo, sigue un sistema de versiones. Este sistema de versiones sirve de etiquetado para el software, para su sencilla localización, y también da mucha información a los usuarios. Típicamente, en el versionado diferenciamos entre versión mayorversión menor.

  • En una versión mayor suele haber cambios estructurales o visuales evidentes. Serían los cambios que ocurrieron entre la versión 2.9 y 3.0 de WordPress, por ejemplo.
  • En una versión menor suele haber correcciones de código o pequeños cambios que modifican y/o mejoran la funcionalidad, así como solucionan problemas de seguridad.

A efectos de programación, en las versiones mayores debemos revisar la compatibilidad de nuestros temas y plugins con las nuevas especificaciones y estructras. Por poner un ejemplo, de WP 3.5 a 3.6 ha cambiado la versión de jQuery, lo que hace que algunos plugins no funcionen de forma correcta. Estos plugins habría que actualizarlos para que funcionaran en la nueva versión.

Las versiones menores suelen incluir detalles de seguridad y cambios que mejoran o corrigen el funcionamiento del software. Así, WP 3.5.1 es una versión menor que corrige problemas de seguridad y otros pequeños problemas, normalmente reportados por los usuarios (suelen ser casos extraños, no generales, que ocurren con determinadas configuraciones específicas).

La idea de Automatic Updater es que esas actualizaciones menores, que siempre mejoran el rendimiento del sistema sin modificar estructuras, se realicen de forma automática. Es decir, que si mañana saliera WordPress 3.6.1, o Jetpack 2.3.5, lo que se espera es que el sistema realice la actualización de forma automática, y que sólo nos pida interactuar cuando nos encontremos ante un cambio de versión mayor. De esta forma, si un plugin o el propio sistema tiene una actualización de seguridad, ésta se aplicará de forma automática a todos los usuarios.

 Limpieza y orden

Una de las cosas que tiene WordPress es que es muy participativo. Si no sabes nada de código y tienes una buena idea puedes dejarla en WordPress Ideas. Allí la comunidad votará las ideas, y las más votadas se convertirán en realidad. Y si sabes código, puedes utilizar el trac.

El trac tiene ahora mismo más de 3800 tickets, lo que lo convierte en un espacio a veces inabarcable, porque no permite tener una visión global, de conjunto, de todo lo que hay abierto en el sistema.

3800-tickets

Durante la WordCamp San Francisco se cerraron más de 100 tickets en un día y medio, lo que da una idea de cómo puede ser el ritmo de trabajo de estos días si todos los desarrolladores dedican dos o tres horas a la semana al trac.

Muchos de estos tickets necesitan revisión. En palabras de Nacin de ayer, “hay 44 tickets sobre feeds abiertos, 16 sobre fecha/hora, y 134 sobre comentarios”. Hay mucho que limpiar, cerrar las cosas que ya no tengan sentido, y reordenar un poco. Un pequeño equipo se encargará de eso, y todo el que quiera participar es bienvenido.

Andrew Nacin y Jon Cave, además, están trabajando en algunas mejoras en el Trac, que incluyen suscripción por componentes. Así, cada uno podrá suscribirse a hilos completos sobre el espacio que le interese: internacionalización, feeds, etc. Esto estará disponible la semana que viene.

Un poco más de seguridad

La tercera cuestión que se incluye de base en 3.7. es la de ampliar la seguridad de las contraseñas en WordPress. Por lo que se viene hablando, se eliminará el usuario admin por defecto (cosa que ya está hecha en la última versión) y se está hablando de utilizar un generador de contraseñas para los usuarios. Lo que sí se tiene cada vez más claro es que casi todos los problemas de seguridad en WordPress vienen por robos de contraseñas y accesos no autorizados, por lo que hay que hacer mucho hincapié en que los usuarios no puedan poner una contraseña como 12345.

La bola extra: developers.svn.wordpress.org

Desde ayer está disponible developers.svn.wordpress.org. Como podéis leer en este artículo, es un nuevo espacio en el que no sólo estarán los tickets, sino que habrá montones de herramientas para desarrolladores.

Las más interesantes, desde mi punto de vista, son los tests unitarios. Estos tests, haciendo un gran resumen, son pequeños scripts que recorren el código buscando qué salida devolverían, y viendo si se corresponde en formato con lo que debería ser. En la página de Travis os podéis hacer una idea de cómo funcionan.

La idea inicial para esta versión es cerrar unos 700-1000 tickets. No es moco de pavo, pero si veis la velocidad a la que va el trac, veréis que es más que posible. Además, el grupo de accesibilidad estará muy pendiente de esta distribución y estará ayudando en todo lo que pueda a que se cumpla la misma.

Para los interesados en JavaScript, la semana que viene habrá una reunión para organizar esa parte, y elegir un framework para trabajar (¿node.js?).

Contributors day

Los días de contribuidores de las WordCamps cada vez son más importantes. Por un lado, para formar a los nuevos integrantes de los equipos de desarrollo. Por otro, para ponerlos en contacto con el resto de la comunidad. Y por último, para divertirse juntos y sentir que somos parte de un gran proyecto. Estoy esperando con muchas ganas el de la WordCamp Europa.

WP 3.8

La versión 3.8 de WordPress se desarrollará en paralelo a la versión 3.7, aunque la fecha de salida es posterior (sobre Diciembre). Esta tarde será la primera reunión de organización.

Los dos elementos principales serán Twenty Fourteen, el nuevo tema por defecto de WordPress basado en Further y del que hablamos anteriormente, y el MP6.

El MP6 es un cambio estructural en la administración, sobre todo, y que lleva años arrastrándose (si no recuerdo mal, desde antes de 3.4). Creo que por eso el líder de proyecto será el propio Matt.

Si queréis probar MP6 podéis instalaros este plugin que no debería existir (actualizado hoy por última vez) o mirar la foto de abajo.

mp6

Os seguiré contando más cosas más adelante, después de la reunión y de haber reordenado ideas 🙂

Cambios en Mecus

El equipo actual de mecus
El equipo actual de mecus

Puede que ya lo hayáis leído en el blog de mecus y en el de Luis. Mecus sigue creciendo, y los mantenimientos, cambios, sugerencias y nuevas funcionalidades de nuestros clientes siguen creciendo también, por lo que el tiempo para nuevos desarrollos e investigación cada vez es más escaso. Así que estamos buscando a otra persona que entre a formar parte de nuestro equipo y nos ayude a seguir adelante y a hacer todas esas cosas que tenemos ganas de hacer ;).

Si crees que la cosa te puede interesar, pásate por alguno de los enlaces anteriores, que Luis lo ha contado mejor que yo.