Ya ha finalizado el Community Summit 2023 y se empieza a entrever el camino hacia el que la Comunidad WordPress quiere dirigirse.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify, Google Podcasts, Apple Podcasts e iVoox o suscribirte al feed directamente.
Transcripción del programa
Hola, soy Javier Casares y estás escuchando WordPress Pódcast, en el especial sobre el Community Summit 2023.
El pasado 22 y 23 de agosto se celebró el Community Summit 2023, un evento especial que habitualmente se realiza cada 3 años y que no se hacía desde 2017 en París, saltando el 2020 por la pandemia de la CoVid-19.
Este evento ha reunido alrededor de 125 personas diversas de la comunidad, entre ellos al equipo directivo del proyecto, y a los representantes y participantes de todos los equipos.
En esta ocasión, se han dividido los dos días en 26 sesiones que han tratado muchísimos temas, la mayoría de los cuales han tenido que ver con la gestión de la Comunidad de una manera directa o indirecta.
Todas las sesiones tienen un sistema de no-atribución por lo que todo lo que se ha dicho en las sesiones se ha documentado de forma anónima, ya que algunos debates han sido muy interesantes y con elementos que sólo se hubieran discutido en un entorno sin atribución.
No todas las sesiones tienen disponibles sus notas, pero vamos a intentar hacer un resumen de la mayoría de ellas.
Comenzando por: Refining Five for the Future for a robust WordPress community
La sesión sobre el Five for the Future planteó algunas ideas como el reconocimiento completo de todas las contribuciones, ya que hay muchas que son invisibles.
Un tema que apareció de forma recurrente son las diferencias entre los contribuidores que están patrocinados de aquellos que no lo están, sobre todo por la visibilidad en la diferencia de tiempos que aplican unos y otros. Incluso la posibilidad de disponer de gente contribuyendo sin la necesidad de que sean empleados de la empresa.
Sin duda los retos del proyecto, gestión, y mejora del Five for the Future están delante y con muchas opciones de mejora
En: Building trust in WordPress CMS and plugin security
La seguridad de WordPress es un elemento que está ahí, a la que se le presta atención puntualmente, y a la que la Comunidad le debería prestar más atención.
Para comenzar la comunicación sobre las prácticas de seguridad deberían estar no sólo en la página global sino ser parte de los distintos equipos que están implicados. Incluso, la propia Comunidad es la que debería liderar la conversación sobre seguridad y no dejarla en manos de terceros.
El planteamiento de que la Comunidad disponga de herramientas para mejorar la seguridad de plugins y temas, o incluso que exista un sistema de «Modo Seguro» en caso de que exista algún tipo de problema de seguridad en el sitio.
Sobre: Accessibility in the WordPress project
¿Qué significaría que WordPress sea Accesibility-first? Diseño, desarrollo, documentación, muchos elementos dependen de este sistema que necesitaría, para empezar, de una documentación y metodología, y una guía de estilo para aplicar a todo el proyecto. Como inicio se podría plantear el uso de pequeñas checklist, que no supongan un gran sobresfuerzo.
Desde WordPress 5.9 no ha habido nadie liderando la accesibilidad en los lanzamientos de versiones, aunque no es lo único que necesita tener algo de revisión.
Un ejemplo claro es WordPress TV, donde muchos de los vídeos no tiene subtítulos, lo que no ayuda a personas con distintas capacidades e incluso a la traducción e inclusión de aquellas personas que no conocen el idioma en el que se reproduce el vídeo.
Sobre: How does the Make Team ecosystem work and how are we connected?
Existen ya más de 20 equipos en WordPress, pero ¿están interconectados? ¿estamos conectados? A esto hay que sumarle una segunda capa que es la de los contribuidores patrocinados de los que no lo están. Y podemos aumentar esto sumando los equipos locales, que tienen sus propios sistemas de trabajo que ni siquiera son conocidos por la comunidad global.
Al final, que los equipos trabajen de forma independiente puede causar redundancia en algunos aspectos y en muchos momentos tampoco queda claro quién es el responsable de qué, por lo que crear un listado de DRI, individuos responsables directamente, puede ser un gran paso.
Un aspecto importante está en la posibilidad de que en las Meetup o los equipos locales dediquen cierto tiempo a hacer el onboarding global de la Comunidad, ayudando a crear las cuentas de usuario, la cuenta de Slack y la explicación de los equipos. Y esto lleva también a mejorar y clarificar las expectativas, equipos y trabajo a realizar en los Contributor Day.
La conversación de: Handling Trust & Safety in the WordPress ecosystem: content moderation and sensitive content
Hay distintas partes del proyecto WordPress donde los usuarios pueden incorporar de una manera u otra contenidos. Unos ejemplos muy claros son WordPress Photos, Openverse o Learn WordPress. En algunos casos la moderación de contenidos requiere de acción por parte de los equipos pero no hay acciones claras de desescalada de determinadas situaciones.
En otra línea, WordPress depende de una fundación en Estados Unidos… ¿debe cumplir la legislación de otros países? ¿Qué pasa si un país bloquea Openverse y no se puede usar en el núcleo de WordPress?
¿Hasta qué punto y de qué manera se ha de implicar la Comunidad? Un ejemplo muy claro lo tenemos en el plugin de apoyo a Rusia cuando se declaró la guerra de Ucrania.
En: Aligning processes and contributions between WordPress Core and Gutenberg
El núcleo de WordPress y Gutenberg tienen ritmos distintos, incluso usan herramientas distintas… ¿Cómo se pueden alinear ambos sistemas y procesos?
En la actualidad casi implica el doble de trabajo ya que el sistema que se usa para el plugin, posteriormente se ha de volver a revisar para su inclusión en el núcleo, lo que hace que los recursos, que ya son escasos de por sí, se tengan que reutilizar en tareas que se podrían evitar si sólo se hicieran una vez.
Tomar la decisión de cuál es el flujo de trabajo y quién debe liderar el desarrollo del Editor en este momento es la duda generada y que se deber solucionar, probablemente cambiando el sistema de ciclos de lanzamiento.
Sobre: Aligning WordPress enterprise with WordPress community
Existe un nivel de empresas muy grandes que tienen dudas del uso de WordPress como sistema de gestión de contenidos. ¿Por qué? Principalmente porque WordPress como Comunidad nunca ha hecho el esfuerzo de venderse de esa manera.
Es por esto que se ha creado el canal #enterprise en el Slack global en el que las empresas puedan compartir casos de estudio, dar soporte a contribuidores, tener un claro sistema de versionados y soporte de elementos externos como PHP o bases de datos.
¿Qué se puede hacer para que las empresas contribuyan con WordPress? Un camino claro de cómo las empresas pueden ayudar a los contribuidores, el uso del Backend en sus sistemas, para que puedan incluir más y mejores contenidos, y, la publicación de casos de estudio son los más destacados.
¿Cómo llegar a las empresas para que se impliquen en WordPress? Para empezar, la creación de una página en WordPress.org en el que se incluya los datos de Empresas y hayan casos de estudio, e incluso la posibilidad de crear un equipo dentro de WordPress que lidere este elemento.
En: Exploring how the Accessibility Team can support Making WordPress teams
Actualmente el equipo de accesibilidad es realmente el tiempo de una persona a jornada completa dando soporte a todo el proyecto y equipos. El problema mayor es estar al día en todo lo que pasa en la Comunidad, y poder actuar en consecuencia.
La accesibilidad es un elemento delicado ya que en algunos estamentos hay que aplicar accesibilidad, y hay herramientas y plugins que ayudan a ello pero que, en algunas ocasiones, normalmente por temas o incompatibilidades de terceros, no funcionan y hay entidades que están denunciando a personas de la comunidad que trabajan en proyectos de Accesibilidad.
La relación entre el equipo de Accesibilidad y el resto del equipo, junto a mejorar la documentación son elementos principales de los próximos pasos.
Sobre: Diversity, Equity, Inclusion, and Belonging (DEIB) for all Make Teams
En la sesión sobre diversidad se trató el tema de la situación del grupo de trabajo y de la posibilidad de que acabe siendo un equipo propio dentro de la Comunidad, y tuvo una interesante discusión sobre cómo atraer a personas más diversas a la Comunidad. También tuvo foco en cómo hacer que la propia Comunidad WordPress sea capaz de explicar y dar a conocer que es una comunidad diversa.
Otro de los focos hizo hincapié en qué es la diversidad, y no sólo haciendo referencia a distintas capacidades físicas o mentales, sino a otros elementos como el idioma, o la importancia de la sensación de pertenencia.
Un elemento importante destacado es la gran diferencia entre los equipos globales y locales de la Comunidad, que funcionan mayormente de una forma muy distinta.
Y, el Código de Conducta también tuvo bastante peso en distintos momentos, por ejemplo en la posibilidad de tener elementos separados de las conversaciones en línea de los eventos presenciales.
En: Addressing backwards compatibility in Gutenberg y otras sesiones paralelas sobre la Fields API.
Marcar contenidos como obsoletos es algo correcto, siempre y cuando haya un sistema que permita reemplazarlos por sistemas modernos y actualizados. Y esto es lo que comienza a ocurrir ya con el nuevo Editor de Bloques Gutenberg, que ya lleva unos años en el mercado y se ha de adaptar a las novedades lanzadas por los navegadores.
El núcleo de WordPress se actualiza por defecto. ¿Por qué no hacerlo con plugins y temas para poder mantener esa compatibilidad en las últimas versiones? Mantener más de 20 versiones de WordPress es insostenible para el proyecto, por lo que se debería plantear un nuevo sistema que mantenga de alguna manera determinadas versiones.
Uno de los elementos más vendidos de WordPress es la retrocompatibilidad, pero actualmente no es una realidad en todos los aspectos, y es algo que hay que solucionar.
En: Unifying development tooling for contribution
Desarrollar con WordPress puede ser bastante caótico ya que hay hasta 40 posibilidades y herramientas de trabajo distintas, algunas compatibles y otras no.
Vagrant, Docker, wp-env, GitHub, Slack, PHPUnit son algunas de ellas… y ¿se debería crear un estándar de desarrollo y de herramientas de comunicación? Herramientas como wp-now y WordPress Playground son muy prometedoras, pero aún no estamos ahí.
Documentación, onboarding, automatización y la posibilidad de enlazar a herramientas de terceros son algunos elementos comunes para continuar, y priorizar las herramientas de código abierto para el desarrollo.
Sobre: Revitalizing contributor teams’ leadership pipeline
¿Cómo podemos conseguir nuevas personas que lideren la Comunidad? Sin duda la pandemia de la CoVid-19 ha afectado enormemente a la Comunidad WordPress, y se han hecho esfuerzos como el Proyecto de Reactivación de Meetup, o la nueva página de Contribución, pero no hay suficientes personas para organizar eventos.
El Proyecto de Mentorías y la posibilidad de conseguir nuevos mentores deben ser parte de los próximos pasos además de mejorar la manera de dar reconocimiento, ampliando el uso de los perfiles y dándoles más valor.
En: Improving maintenance of older default themes
En la sesión sobre el mantenimiento de temas antiguos, en este caso los Twenty-algo, surgió la problemática der que actualmente WordPress está focalizado en los bloques y los temas existentes clásicos no tiene soporte completo, y cómo incluso hacer el mantenimiento de estos temas permitiría enseñar a otros desarrolladores a hacerlo.
También surgió la posibilidad de que los temas no sólo se actualicen cuando haya una versión mayor de WordPress, sino que exista la posibilidad de que tenga actualizaciones más continuadas.
Mejorar la documentación, tener una persona responsable de los temas en cada lanzamiento o mover toda la gestión de los temas a GitHub parecen buenos puntos de inicio.
Sobre: Is succession planning possible in open source?
La posibilidad de que haya una cadena de sucesión en los proyectos de código abierto es algo que existe desde el mismo inicio de este concepto. Con la pregunta de ¿qué pasaría si a Matt lo atropella un autobús? comienza un debate interesante sobre la transferencia de conocimiento, el onboarding y el offboarding, ya que en muchos momentos muchas personas cambian de equipo, entran o salen de la Comunidad y su conocimiento queda en riesgo de perderse. Algo que podría llegar al «si yo no lo hago, no lo hace nadie» básicamente porque hay limitaciones de algún tipo o acceso.
Sin duda crear un centro de documentación general de cada uno de los roles es importante, aunque probablemente tenga que estar en cada uno de los equipos ya que cada uno funciona de forma distinta.
El mayor problema de todos: el tiempo. Así que documentar lo máximo posible, lo que incluye no sólo accesos y tareas, sino cómo funciona el equipo; encontrar a personas clave en cada uno de los equipos de una forma inclusiva, y tener un mínimo de 3 Team Reps pueden ser algunas soluciones.
¿Cuáles son los criterios para el uso de unas versiones y no de otras que pueden ser más modernas y estables? El primer ejemplo claro es el uso de NodeJS 16 y no 18, por problemas de compatibilidad.
Y esto es sólo el principio, porque se podría entrar a fondo en la problemática de las versiones de PHP. La responsabilidad con los usuarios de mantener el uso de herramientas estables, seguras y mantenidas entra de frente con el que WordPress es un proyecto muy usado y que debe generar cierta responsabilidad con Internet.
¿Cuándo tomar la decisión de cambiar de versión o dejar de dar soporte? Principalmente, por seguridad y por la imposibilidad de asumir la deuda tecnológica.
Todavía hay muchas sesiones que tienen pendientes de lanzar sus resúmenes y notas, por lo que os invitamos a seguir atentos al sitio del equipo.
Todo esto y mucho más es lo que existen en make.wordpress.org/summit y en la que se puede participar dejando comentarios y generando el camino para los próximos pasos de cada uno de estos proyectos. Sin duda es una muy buena ocasión para dejar un comentario dando tu opinión en cómo deberían ser las cosas a partir de ahora.
Como asistente al evento sí que me gustaría plantear una reflexión general, y es la del que la mayoría de los elementos establecidos en la Comunidad WordPress se hicieron hace más de 10 años, cuando el proyecto era otra cosa, y en estos últimos 10 años todo se ha basado en cómo eran las cosas antes, lo que ha estancado el proyecto como tal.
Es cierto que hay equipos que se han adaptado muy rápidamente, como es el de Comunidad con las nuevas Next Generation WordCamp, pero aún así, seguimos pensando en una Comunidad de 10 equipos y no de más de 20, en una forma de trabajo de PHP de cómo era antiguamente, y como como ahora que sale una versión nueva cada año, y, lo más importante y que quizá no haya quedado reflejado aún en los resúmenes, que es el no saber claramente quién tiene el poder en la Comunidad, porque se supone que no debe haber gente con poder en la Comunidad, y cómo ese poder pasa de unas personas a otras.
Esa falta de definición de qué es un Team Rep (o los representantes de equipo) que se eligen habitualmente cada año y que son los que tiran del carro de cada uno de ellos, y la no posibilidad de usar el concepto de Team Lead, o líder del equipo, aunque sea lo que realmente hacen, genera mucha discusión en el escalado de las personas dentro de los equipos glocales, pero también locales, donde el poder está en manos de unos pocos.
Y, para acabar, este pódcast se distribuye con licencia EUPL; tienes todos los enlaces para ampliar la información, en WordPress Pódcast .es.
Un abrazo, y hasta el próximo programa.