El viaje de un líder de lanzamiento no técnico para convertirse en un mentor para el desarrollo principal de WordPress

En el verano de 2019, me pidieron que ayudara con un lanzamiento de WordPress. Unos meses antes, los representantes del equipo central se acercaron a otros equipos en un esfuerzo por aumentar la diversidad de los equipos de lanzamiento y comencé a considerarlo seriamente.

En ese momento, ya estaba muy involucrado en el ecosistema de WordPress y estaba en mi segundo año como Gerente de Asociación y Comunidad de WordPress en SiteGround, pero no tenía experiencia alguna sobre cómo se hace WordPress desde un punto de vista central. Aún así, cuando Josepha Haden, directora ejecutiva de WordPress.org, me hizo un ping, dije que sí sin dudarlo. Y resultó ser una de las experiencias más desafiantes y gratificantes de mi vida. Aquí es cómo.

Un colaborador accidental: mi camino en la tecnología

Desde muy temprana edad, parecía estar predestinado a convertirme en desarrollador. Mis padres son programadores, comenzaron en los años sesenta y obtuve mi primera computadora personal en 1982 cuando la gente en Italia realmente no tenía idea de lo que eran.

Seguí su espíritu de trabajo y pensé que su trabajo era fascinante, hacer que una máquina hiciera lo que querías, pero me atrajeron otras opciones de carrera. De hecho, realmente no sabía qué quería hacer cuando fuera grande, pero las computadoras y los sitios web siguieron siendo una gran parte de mi vida personal y profesional.

Si bien la programación back-end nunca fue algo que me interesó, me encontré tomando una clase de diseño web en 1999, luego me inscribí para obtener una licenciatura en Artes y Multimedia en 2004. Finalmente encontré WordPress en 2008 y comencé a vivir de en 2010.

Pronto, me di cuenta de que mi verdadera habilidad era ayudar a los clientes que acudían a mí con una solicitud de un sitio web a enfocarse mejor en su "por qué" para el sitio web y pensar en su estrategia comercial y de marketing antes de contratarme. Escribí libros sobre planificación empresarial, productividad y sitios web. También comencé a dar charlas en WordCamps y otros eventos para educar a los trabajadores independientes sobre esos temas.

En 2015, conocí al azar a algunas personas que estaban involucradas en la comunidad de WordPress, lo que me llevó a comenzar a contribuir también. No tenía habilidades de desarrollo, así que nunca pensé que podría contribuir con OSS, pero resultó que era innecesario. Conocí a personas que me señalaron los muchos equipos diferentes que hacen WordPress y comencé a estar activo en Polyglots primero y Community después.

Seguí trabajando en mi negocio, pero cuanto más contribuía a WordPress, más quería encontrar una manera de ayudar a miles de personas a la vez. Mis esfuerzos de divulgación de dar charlas, ayudar a los organizadores comunitarios y escribir contenido necesitaban escalar.

Aquí es donde conocí a SiteGround. En el verano de 2017, estaban buscando un Community Manager y, a pesar de no ser uno de oficio, decidí presentar una solicitud y obtuve el trabajo. Unirme a la empresa me permitió tener tiempo patrocinado para contribuir a WordPress. También me permitió aprovechar el conocimiento colectivo de mis colegas cuando empiezo a idear nuevas ideas para el proyecto.

Así que dije que sí sin dudarlo, pero la verdad es que ese sí tardó casi cinco años en gestarse. Además, sentí que Josepha y SiteGround confiaron en mí para hacer un buen trabajo. A cambio, confié en la comunidad de WordPress para ayudarme a descubrir todas las cosas que necesitaba aprender.

Cómo se hace WordPress

El otro factor alentador fue que desde WordPress 5.0, ya no se hacía un lanzamiento por una sola persona, como solía ser durante años, o una persona con un par de diputados. Ahora había todo un equipo trabajando, cariñosamente conocido como “el escuadrón”, por lo que hay muchas manos a la obra.

mucha comunicacion

Durante un ciclo de lanzamiento, hay mucha comunicación. Hay publicaciones de blog de diferentes equipos de Make. En cada etapa del lanzamiento, hay publicaciones de blog en la sección de Noticias de WordPress.org. Hay conversaciones constantes en el canal público de Slack y hay uno privado que es la red de seguridad para las nuevas personas que inicialmente pueden sentirse intimidadas al hacer preguntas en un gran canal público.

Los diferentes roles en el equipo de lanzamiento

Lo que más me gusta de este modelo para el lanzamiento es la variedad de roles que incluye. Hay desarrolladores, diseñadores, vendedores, escritores técnicos y gerentes de proyectos. WordPress no solo está hecho de código, y es genial ver todas estas diferentes habilidades reunidas para contribuir a su lanzamiento.

El rol del Coordinador de lanzamiento (el que cubrí para WordPress 5.3 y 5.4) y del Triage PM (rol que fue cubierto por el excelente David Baumwald para 5.3, 5.4 y 5.5) es intentar vigilar todos los partes móviles. Y digo intentarlo porque es casi imposible. Esta es la razón por la que hay pistas de enfoque para las diferentes partes en las que se está trabajando.

Matt Mullenweg es el líder del proyecto y ha sido el líder del lanzamiento desde WordPress 5.0. Él presenta la hoja de ruta de alto nivel y los proyectos de enfoque. Pero más allá de eso, no está involucrado en la vida cotidiana del desarrollo de Core. En más de un año de estar involucrado en los lanzamientos de Core, Matt pidió solo una vez que agregara una función.

Me molesta cuando la gente piensa que todo lo que sucede en WordPress es porque Matt lo quiere así. Disminuye el papel de todas las personas que se preocupan por el proyecto y se encargan de hacer avanzar las cosas, guiar los problemas, defender las multas y, en general, comprometerse a contribuir para que WordPress sea mejor para todos, sin importar si lo hacen. por un boleto o trabajar en él a tiempo completo.

Mantenedores de componentes y responsables principales

Un grupo de personas que son fundamentales para dar forma a una versión son los mantenedores de componentes. Ellos son los responsables de cuidar un determinado componente que conforma el Core y ver cómo van los tickets en esa área. Ellos son los que pueden evaluar si un ticket está listo para fusionarse.

Una vez que se considera que un ticket está listo, los encargados principales entran en escena. Hacen una revisión final del ticket. Pueden solicitar algunos cambios o hacer los cambios ellos mismos mientras se comprometen. Esto es lo que más me sorprendió. Realmente no pensé que un compromiso podría tomar horas, pero definitivamente puede hacerlo. En los lanzamientos que coordiné, definitivamente no observé mucho compromiso por parte de los mantenedores y los encargados de confirmar, y esto es muy desmotivador para las personas que trabajan en los tickets. No todo puede incluirse en un lanzamiento, incluso si el parche está listo, porque no hay suficientes personas para revisar, dar comentarios y, en última instancia, comprometerse. Con pocos recursos, debe tomar decisiones y esas no siempre se alinearán con las preferencias de cada usuario o colaborador de WordPress.

Este es probablemente uno de los mayores desafíos que WordPress tendrá que enfrentar en el futuro: ¿Cómo podemos reactivar a las personas que pueden brindar una gran ayuda?

La fiesta de lanzamiento

A pesar de estos problemas, las cosas se hacen y cuando el lanzamiento está listo, lo celebramos con una fiesta. No sé quién empezó a llamarlos Release Parties o cuándo empezaron. Lo que sé es que para 5.3 y 5.4, organicé bastantes y todos fueron muy divertidos.

El día de uno de los pasos del lanzamiento (puede ser Betas, Release Candidates o General Release), el canal Core se vuelve muy activo: mucha gente se conecta para ver cómo se lanza la versión de WordPress. Hay múltiples pasos y diferentes personas involucradas en diferentes tareas. Los pasos de lanzamiento están documentados en el manual de Core y se siguen públicamente para que todos puedan verlos todos.

La fiesta más grande es el día del lanzamiento general; hay un momento específico que es increíblemente poderoso. WordPress tiene un contador de descargas, por lo que antes de lanzar la nueva versión, el escuadrón toma una captura de pantalla de la anterior, todos nos despedimos y damos la bienvenida al nuevo niño. A pesar de que todo es virtual, este momento es casi tangible y nunca dejará de conmoverme. Hicimos WordPress, una vez más.

12 meses como colaborador principal

Mientras escribía este artículo, se me ocurrió que he sido colaborador principal durante un año. Todavía tengo mi rol de tiempo completo en SiteGround, que a veces me resultaba difícil de manejar, así que tengo que darle crédito a mi equipo por su apoyo.

Todavía no puedo escribir PHP y desprecio mucho JavaScript, pero cuando miro hacia atrás, estoy increíblemente orgulloso de los cambios que han ocurrido en los últimos 12 meses. No puedo atribuirme el mérito de todos ellos, pero estoy feliz de haber podido ser parte de ellos de alguna manera.

Calendario de lanzamiento

Una cosa que muchos colaboradores pidieron fue un cronograma de lanzamientos a mediano plazo, para que se ajusten mejor a su trabajo y calendario personal. Ser el chico nuevo puede ser difícil porque no conoces toda la historia y los antecedentes de por qué las cosas se hacen de cierta manera, pero eso también es una ventaja. Eres libre de reiniciar conversaciones. Después de discutirlo con el equipo y otros equipos, me quedó claro que solo era una cuestión de "quién va a discutir esto con Matt". Y así lo hice. Un par de días después se publicó en el blog de Core un programa de lanzamiento tentativo hasta WordPress 6.0, y lo hemos estado usando desde entonces.

Escuadrón de lanzamiento más grande y tutoría

El equipo de lanzamiento también se hace más grande con cada lanzamiento. Muchos equipos están involucrados en su elaboración y se ven afectados por él. Es importante que todos estos equipos estén representados en el proceso. En WordPress 5.5, hay varios roles nuevos, y en 5.6 habrá aún más: prueba, documentación, soporte son componentes vitales de lo que hace que WordPress sea excelente, por lo que es importante recibir sus comentarios mientras el software está en desarrollo activo.

Y es importante tener mentores. Esta es una mejora importante que Josepha introdujo en WordPress 5.3. El equipo de lanzamiento no solo está formado por líderes de enfoque, sino que hay un grupo creciente de mentores capaces de ayudar a los nuevos colaboradores a aprender las cuerdas. La idea es que esas personas eventualmente se conviertan en mentores y enseñen a nuevas personas. Esta es otra excelente manera de involucrar a más y más personas en Core, con diferentes habilidades y antecedentes.

Y esto me lleva al mayor cambio (y desafío) de todos. WordPress 5.6, que se perfila como un lanzamiento masivo, tendrá un equipo compuesto completamente por mujeres y personas que se identifiquen como mujeres. Como muchas cosas en WordPress, todo comenzó con un momento de “pensar en voz alta” y ahora es una realidad. El trabajo en este lanzamiento comenzará muy pronto y estoy emocionado de ser parte de él como mentor.

WordPress necesita tu ayuda

Desearía poder decir que todo son unicornios y arcoíris, pero no lo es. El número de personas involucradas activamente en hacer realidad este proyecto es aún muy pequeño en comparación con la magnitud de su alcance.

Soy un gran emprendedor, así que deseo que la gente se tome el tiempo y la energía que dedican a criticar WordPress y lo conviertan en tiempo de contribución activa. Sí, a veces requiere ser muy terco con un boleto y requiere darle seguimiento sin descanso, pero sigo pensando que vale la pena.

La participación activa también significa dejar comentarios constructivos en los tickets u ofrecerse a tomar notas durante el chat de desarrollo. Esa es la maldición y la belleza de un proyecto masivo. ¡Siempre hay algo que hacer!

En los últimos años, también he visto un aumento en la contribución de diferentes tipos de empresas. En SiteGround, por ejemplo, contribuimos principalmente a eventos y a la comunidad durante años. Patrocinamos y nos ofrecimos como voluntarios, fuimos organizadores y oradores. Trabajamos mucho dentro de la comunidad española de WordPress para ayudarla a desarrollarse y crecer, y ahora es una de las más grandes de la comunidad global. En el último año hemos aumentado las horas que dedicamos a equipos más técnicos. Todavía estoy activo en Core como mentor y como representante del equipo. Uno de nuestros ingenieros de WordPress, Stanimir Stoyanov, forma parte del equipo de seguridad, y uno de nuestros ingenieros de JavaScript, Kiril Zhelyazkov, ahora dedica un par de días a la semana a Gutenberg.

Estos temas se alinean con nuestros valores, por lo que fue una progresión natural para nosotros involucrarnos más.

Finalmente, espero ver a la gente involucrarse en una propuesta que publiqué hace unos días en el blog de Core sobre pruebas de extremo a extremo. Ahora mismo hay uno, y estoy seguro de que podemos hacerlo mejor. Una vez más, los desarrolladores no son los únicos que se necesitan. Los usuarios son los contribuyentes más raros y probablemente los que más necesita el proyecto para finalmente tener algunas pruebas de usuario. No soy desarrollador y estoy feliz de que los no desarrolladores puedan tener un impacto.

Mis preocupaciones personales y esperanzas para el futuro del proyecto

Cuando comencé a contribuir con Core, comencé una nota en mi computadora con algunas observaciones. No tener 17 años de experiencia en el proyecto me ayuda a ver las cosas sin prejuicios, y no ser desarrollador me ayuda a ver el proyecto más como un cuerpo vivo que respira, en lugar de componentes o boletos. Permítanme compartir mis preocupaciones, esperanzas y sueños para el futuro.

Mantenedores de componentes y responsables principales: se les necesita más que nunca

Al momento de escribir este artículo, el proyecto tiene alrededor de 60 confirmadores y 60 mantenedores de componentes, con muchas personas realizando tareas dobles, triples y, a veces, séxtuples. Pero la realidad es que en WordPress 5.4 y 5.5, Sergey Biryukov hizo cientos de confirmaciones. Estoy increíblemente agradecido por el trabajo de Sergey. Al mismo tiempo, siento que, sin darnos cuenta, estamos creando un factor de bus en Core. La mayoría de las personas con acceso a Core Commit no comprometieron un ticket. De manera similar, me comuniqué con todos los mantenedores de componentes para conocer sus planes para los próximos lanzamientos y solo respondieron alrededor del 50 % de los componentes.

¿Cómo nos aseguramos de que participen las personas que tienen el poder y, por lo tanto, la responsabilidad de ayudar a cometer y supervisar las multas? Pero también, ¿cómo alentamos a las personas a renunciar y declararse inactivas para que nuevas personas puedan ascender?

Mi carrera abarca más de 25 años en diferentes industrias, y una cosa sigue siendo la misma: cuando las personas ven que alguien más ocupa un puesto, estarán menos motivados y, a veces, incluso intimidados para dar un paso al frente. La escasez no solo impulsa las compras, sino que también genera un nuevo compromiso.

El Equipo de la comunidad, por ejemplo, mantiene una lista de diputados y sus diferentes estados. Me he estado preguntando si Core podría hacer algo similar para que cuando la gente nueva quiera dar un paso al frente, puedan ver a primera vista qué componentes faltan. Las personas que se quejan de "Los desarrolladores principales" no los verán como una gota, sino como individuos que en cualquier momento pueden estar inactivos por un período. Cuando vea que en realidad solo hay unas pocas personas que revisan y se comprometen activamente, es posible que sea más propenso a comprender por qué no todos los boletos pueden llegar a la línea de meta.

La documentación es la forma más elevada de generosidad

Digo esto cada vez que hablo de contribuir al SFA: con frecuencia falta documentación. A menudo, lo que hay está desactualizado.

¿Cómo nos aseguramos de que la documentación no sea una ocurrencia tardía sino que se integre en el proceso de desarrollo?

Hay mucho trabajo puesto en escribir notas de desarrollo para los cambios que afectan el desarrollo, pero esa no es la única documentación que se necesita. Algunos de los procesos descritos en los manuales básicos están desactualizados, algunos faltan porque viven en la mente de los colaboradores experimentados.

Como gran admirador de Gutenberg y del texto rico y atractivo, deseo que nuestros manuales aprovechen al máximo el poder del editor de bloques y sean más atractivos. En este momento son una pared de texto y cada vez que le decimos a la gente que mire los manuales siento que se me encoge el corazón.

Posibles soluciones, que no estoy segura de que sean técnicamente factibles, pero una chica puede soñar: sincronizar con GitHub para resolver al menos el problema del control de versiones. Luego reclute, reclute, reclute y trabaje con Documentación, Meta y Diseño para proporcionar manuales útiles, atractivos, legibles y fáciles de escanear.

Realice un seguimiento de las piezas móviles y trabaje como uno solo

La otra cosa que noto a menudo es cómo los equipos, los enfoques y los componentes funcionan en silos.

Esto no se hace en absoluto para ser guardianes, es solo la forma en que cada equipo se autoorganizó a lo largo de los años.

Necesitamos encontrar una manera de tener una vista panorámica de lo que sucederá en la próxima versión y cuáles son todas las partes móviles.

Trac es muy granular y tiene una serie de informes preparados, puede filtrar por hitos y ver cuántos tickets hay en cada componente, pero eso es solo una parte de la historia.

Sí, estoy hablando de encontrar una manera de administrar el proyecto como un todo y no como partes y bobs.

Ingresa a GitHub. En algún momento.

Esto no va a suceder pronto, pero espero que eventualmente suceda. Mueva el desarrollo y la gestión de proyectos de WordPress a GitHub, como lo ha estado haciendo Gutenberg.

Sé que para muchos será un incentivo para contribuir con WordPress de una forma más familiar. Bajará el listón a la entrada, que siempre es de agradecer. Con algunos tutoriales útiles, permitirá que personas no técnicas contribuyan a la documentación, las pruebas y la gestión de proyectos.

El futuro es brillante

A pesar de todos los problemas, o quizás debido a ellos, el futuro de WordPress es brillante.

He estado al acecho en varios equipos en estos años, y últimamente noto que más personas se incorporan, más personas participan en cada lanzamiento, más personas asumen roles de liderazgo en diferentes equipos. También he notado un aumento en la diversidad, que siempre es un cambio bienvenido.

En pocas palabras: WordPress necesita de todos nosotros para que esto suceda. ¡Espero verte a bordo!