Le parcours d'un responsable de version non technique pour devenir un mentor pour le développement de base de WordPress

À l'été 2019, on m'a demandé d'aider avec une version WordPress. Quelques mois auparavant, les représentants de l'équipe principale ont contacté d'autres équipes dans le but d'accroître la diversité des équipes de publication, et j'ai commencé à y réfléchir sérieusement.

À l'époque, j'étais déjà fortement impliqué dans l'écosystème WordPress et j'étais dans ma deuxième année en tant que responsable de la communauté et des partenariats WordPress chez SiteGround, mais je n'avais aucune expérience sur la façon dont WordPress est fait d'un point de vue Core. Pourtant, lorsque Josepha Haden, directrice exécutive de WordPress.org, m'a envoyé un ping, j'ai dit oui sans hésitation. Et cela s'est avéré l'une des expériences les plus difficiles et les plus enrichissantes de ma vie. Voici comment.

Un contributeur accidentel : mon parcours dans la technologie

Dès mon plus jeune âge, je semblais être prédestiné à devenir développeur. Mes parents sont programmeurs, ils ont commencé dans les années 60, et j'ai eu mon premier ordinateur personnel en 1982 quand les gens en Italie n'avaient pas vraiment une idée de ce que c'était.

J'ai suivi leur philosophie de travail et je pensais que leur travail était fascinant, faire faire à une machine ce que vous voulez, mais j'étais attiré par d'autres options de carrière. En fait, je ne savais pas vraiment ce que je voulais faire quand j'ai grandi, mais les ordinateurs et les sites Web ont continué à faire partie de ma vie personnelle et professionnelle.

Bien que la programmation back-end ne m'ait jamais intéressé, je me suis retrouvé à suivre un cours de conception Web en 1999, puis je me suis inscrit à un diplôme en arts et multimédia en 2004. J'ai finalement trouvé WordPress en 2008 et j'ai commencé à vivre de ça en 2010.

Bientôt, j'ai réalisé que ma véritable compétence consistait à aider les clients qui venaient me voir avec une demande de site Web à mieux se concentrer sur leur « pourquoi » pour le site Web et à réfléchir à leur stratégie commerciale et marketing avant de m'engager. J'ai écrit des livres sur la planification d'entreprise, la productivité et les sites Web. J'ai également commencé à donner des conférences lors de WordCamps et d'autres événements pour éduquer les pigistes sur ces sujets.

En 2015, j'ai rencontré par hasard des personnes impliquées dans la communauté WordPress, ce qui m'a amené à commencer à contribuer aussi. Je n'avais pas de compétences en développement donc je n'aurais jamais pensé pouvoir contribuer à OSS, mais il s'avère que ce n'était pas nécessaire. J'ai rencontré des gens qui m'ont indiqué les nombreuses équipes différentes qui fabriquent WordPress et j'ai commencé à être actif dans Polyglots d'abord et dans la communauté plus tard.

J'ai continué à travailler sur mon entreprise, mais plus je contribuais à WordPress, plus je voulais trouver un moyen d'aider des milliers de personnes à la fois. Mes efforts de sensibilisation consistant à donner des conférences, à aider les organisateurs communautaires et à rédiger le contenu nécessaire pour évoluer.

C'est là que j'ai rencontré SiteGround. À l'été 2017, ils cherchaient un gestionnaire de communauté et bien que je n'en sois pas un de métier, j'ai décidé de postuler et j'ai obtenu le poste. Rejoindre l'entreprise m'a permis d'avoir du temps sponsorisé pour contribuer à WordPress. Cela m'a également permis de puiser dans les connaissances collectives de mes collègues lorsque je commence à élaborer de nouvelles idées pour le projet.

J'ai donc dit oui sans hésitation, mais la vérité est que ce oui a mis près de cinq ans à se préparer. De plus, j'ai senti que Josepha et SiteGround me faisaient confiance pour faire du bon travail. En retour, j'ai fait confiance à la communauté WordPress pour m'aider à comprendre tout ce que j'avais besoin d'apprendre.

Comment WordPress est fait

L'autre facteur encourageant était que depuis WordPress 5.0, une version n'était plus faite par une seule personne, comme c'était le cas pendant des années, ou une personne avec quelques adjoints. Maintenant, il y avait toute une équipe au travail, affectueusement appelée "l'équipe", donc il y avait beaucoup de mains sur le pont.

Beaucoup de communication

Au cours d'un cycle de publication, il y a beaucoup de communication. Il existe des articles de blog de différentes équipes Make. À chaque étape de la publication, il y a des articles de blog dans la section Actualités de WordPress.org. Il y a des bavardages constants sur la chaîne publique Slack et il y en a une privée qui est le filet de sécurité pour les nouvelles personnes qui pourraient initialement se sentir intimidées en posant des questions sur une grande chaîne publique.

Les différents rôles dans l'équipe de lancement

Ce que j'aime le plus dans ce modèle pour la sortie, c'est la variété des rôles qu'il comprend. Il y a des développeurs, des concepteurs, des spécialistes du marketing, des rédacteurs techniques et des chefs de projet. WordPress n'est pas seulement fait de code, et c'est formidable de voir toutes ces différentes compétences se réunir pour contribuer à sa sortie.

Le rôle du Release Coordinator (celui que j'ai couvert pour WordPress 5.3 et 5.4) et du Triage PM (rôle qui a été couvert par l'excellent David Baumwald pour 5.3, 5.4 et 5.5) est d'essayer de garder un œil sur tous les pièces mobiles. Et je dis essayer parce que c'est presque impossible. C'est pourquoi il existe des pistes de réflexion pour les différentes parties sur lesquelles on travaille.

Matt Mullenweg est le chef de projet et est le responsable de la publication depuis WordPress 5.0. Il propose la feuille de route de haut niveau et les projets prioritaires. Mais au-delà de cela, il n'est pas impliqué dans la vie quotidienne du développement de Core. En plus d'un an d'implication dans les versions Core, Matt n'a demandé qu'une seule fois d'ajouter une fonctionnalité.

Je suis ennuyé quand les gens pensent que tout ce qui se passe dans WordPress est dû au fait que Matt le veut ainsi. Cela diminue le rôle de toutes les personnes qui se soucient du projet et se chargent de faire avancer les choses, de gérer les problèmes, de défendre les tickets et, en général, de s'engager à contribuer à améliorer WordPress pour tout le monde, peu importe s'ils le font. pour un billet ou y travailler à plein temps.

Mainteneurs de composants et core committers

Un groupe de personnes qui contribuent à façonner une version sont les mainteneurs de composants. Ils sont responsables de s'occuper d'un certain composant qui compose Core et de voir comment les tickets dans ce domaine se déroulent. Ce sont eux qui peuvent évaluer si un ticket est prêt à être fusionné.

Une fois qu'un ticket est jugé prêt, les Core Committers entrent en scène. Ils font un examen final du billet. Ils peuvent demander des modifications ou effectuer les modifications eux-mêmes lors de la validation. C'est la chose qui m'a le plus surpris. Je ne pensais vraiment pas qu'un commit pouvait prendre des heures, mais c'est certainement possible. Dans les versions que j'ai coordonnées, je n'ai certainement pas observé beaucoup d'engagement de la part des mainteneurs et des committers, ce qui est très démotivant pour les personnes travaillant sur les tickets. Tout ne peut pas entrer dans une version, même si le correctif est prêt, car il n'y a pas assez de personnes pour réviser, donner des commentaires et finalement s'engager. Avec peu de ressources, vous devez faire des choix et ceux-ci ne correspondent pas toujours aux préférences de chaque utilisateur ou contributeur WordPress.

C'est probablement l'un des plus grands défis que WordPress devra relever pour aller de l'avant : Comment pouvons-nous réactiver les personnes qui peuvent apporter une grande aide ?

La fête de la libération

Malgré ces problèmes, les choses se font et lorsque la version est prête, nous célébrons avec une fête. Je ne sais pas qui a commencé à les appeler Release Parties ou quand ils ont commencé. Ce que je sais, c'est que pour 5.3 et 5.4, j'en ai hébergé pas mal, et ils étaient tous très amusants.

Le jour de l'une des étapes de la publication (il peut s'agir de bêtas, de versions candidates ou de versions générales), le canal Core devient très actif : de nombreuses personnes se connectent pour voir comment la version de WordPress est publiée. Il y a plusieurs étapes et différentes personnes impliquées dans différentes tâches. Les étapes de publication sont documentées dans le manuel Core et sont suivies publiquement afin que tout le monde puisse les voir toutes.

La plus grande fête est le jour de la sortie générale ; il y a un moment spécifique qui est incroyablement puissant. WordPress a un compteur de téléchargement, donc avant de publier la nouvelle version, l'équipe prend une capture d'écran de la précédente, nous disons tous au revoir et souhaitons la bienvenue au nouveau. Bien que tout soit virtuel, ce moment est presque tangible et ne cessera de m'émouvoir. Nous avons fait WordPress, une fois de plus.

12 mois en tant que contributeur principal

Pendant que j'écrivais cet article, il m'est venu à l'esprit que je suis un contributeur principal depuis un an maintenant. J'ai toujours mon rôle à temps plein chez SiteGround, avec lequel j'ai parfois eu du mal à jongler, je dois donc remercier mon équipe pour son soutien.

Je ne sais toujours pas écrire PHP et méprise profondément JavaScript, mais quand je regarde en arrière, je suis incroyablement fier des changements qui se sont produits au cours des 12 derniers mois. Je ne peux pas m'attribuer le mérite de chacun d'eux, mais je suis heureux d'avoir pu en faire partie d'une manière ou d'une autre.

Calendrier de publication

Une chose que beaucoup de contributeurs ont demandée était un calendrier de sorties à moyen terme, pour mieux les adapter à leur travail et à leur calendrier personnel. Être le petit nouveau peut être difficile parce que vous ne connaissez pas toute l'histoire et les raisons pour lesquelles les choses sont faites d'une certaine manière, mais c'est aussi un avantage. Vous êtes libre de reprendre les conversations. Après en avoir discuté avec l'équipe et d'autres équipes, il était clair pour moi que c'était juste une question de "qui va en parler avec Matt". Et c'est ce que j'ai fait. Quelques jours plus tard, un calendrier de publication provisoire jusqu'à ce que WordPress 6.0 soit publié sur le blog Core, et nous l'utilisons depuis.

Plus grande équipe de lancement et mentorat

L'équipe de lancement s'agrandit également à chaque sortie. De nombreuses équipes sont impliquées dans sa fabrication et affectées par celle-ci. Il est important que toutes ces équipes soient représentées dans le processus. Dans WordPress 5.5, il y a plusieurs nouveaux rôles, et dans 5.6 il y en aura encore plus : Test, Documentation, Support sont tous des composants essentiels de ce qui rend WordPress génial, il est donc important d'avoir leurs commentaires pendant que le logiciel est en développement actif.

Et il est important d'avoir des mentors. Il s'agit d'une amélioration majeure que Josepha a introduite dans WordPress 5.3. L'équipe de publication n'est pas seulement composée de chefs de file, mais il existe un groupe croissant de mentors capables d'aider les nouveaux contributeurs à apprendre les ficelles du métier. L'idée est que ces personnes finiront par devenir des mentors et enseigneront à de nouvelles personnes. C'est un autre excellent moyen d'impliquer de plus en plus de personnes dans Core, avec des compétences et des parcours différents.

Et cela m'amène au plus grand changement (et défi) de tous. WordPress 5.6, qui s'annonce comme une version massive, aura une équipe entièrement composée de femmes et de personnes qui s'identifient comme des femmes. Comme beaucoup de choses dans WordPress, tout a commencé par un moment « Penser à haute voix » et est maintenant une réalité. Le travail sur cette version va commencer très bientôt, et je suis ravi d'en faire partie en tant que mentor.

WordPress a besoin de votre aide

J'aimerais pouvoir dire que ce ne sont que des licornes et des arcs-en-ciel, mais ce n'est pas le cas. Le nombre de personnes activement impliquées dans la réalisation de ce projet est encore très faible par rapport à l'ampleur de sa portée.

Je suis vraiment un faiseur, donc j'aimerais que les gens prennent le temps et l'énergie qu'ils consacrent à critiquer WordPress et à le transformer en temps de contribution actif. Oui, parfois ça demande d'être très têtu sur un ticket et ça demande de le suivre sans relâche, mais je pense quand même que ça vaut le coup.

La participation active signifie également laisser des commentaires constructifs dans les tickets ou proposer de prendre des notes pendant le chat de développement. C'est la malédiction et la beauté d'un projet massif. Il y a toujours quelquechose à faire!

Au cours des dernières années, j'ai également constaté une augmentation de la contribution de différents types d'entreprises. Chez SiteGround, par exemple, nous avons principalement contribué aux événements et à la communauté pendant des années. Nous avons parrainé et nous nous sommes portés volontaires, nous étions organisateurs et conférenciers. Nous avons beaucoup travaillé au sein de la communauté WordPress espagnole pour l'aider à se développer et à grandir, et c'est maintenant l'une des plus importantes de la communauté mondiale. Au cours de la dernière année, nous avons augmenté le nombre d'heures que nous consacrons à des équipes plus techniques. Je suis toujours actif dans Core en tant que mentor et en tant que représentant de l'équipe. L'un de nos ingénieurs WordPress, Stanimir Stoyanov, fait partie de l'équipe de sécurité, et l'un de nos ingénieurs JavaScript, Kiril Zhelyazkov, consacre désormais quelques jours par semaine à Gutenberg.

Ces sujets correspondent à nos valeurs, c'était donc une progression naturelle pour nous de nous impliquer davantage.

Enfin, j'espère voir des gens s'impliquer dans une proposition que j'ai publiée il y a quelques jours dans le blog Core à propos des tests de bout en bout. En ce moment, il y en a un, et je suis sûr que nous pouvons faire mieux. Encore une fois, les développeurs ne sont pas les seuls nécessaires. Les utilisateurs sont les contributeurs les plus rares et probablement ceux dont le projet a le plus besoin pour enfin avoir des tests utilisateurs en place. Je ne suis pas un développeur et je suis heureux que les non-développeurs puissent avoir un impact.

Mes préoccupations personnelles et mes espoirs pour l'avenir du projet

Quand j'ai commencé à contribuer à Core, j'ai commencé une note sur mon ordinateur avec quelques observations. Ne pas avoir 17 ans d'expérience dans le projet m'aide à voir les choses sans parti pris, et ne pas être développeur m'aide à voir le projet davantage comme un corps vivant et respirant, plutôt que comme des composants ou des tickets. Permettez-moi de partager mes préoccupations, mes espoirs et mes rêves pour l'avenir.

Mainteneurs de composants et core committers : vous êtes plus que jamais nécessaires

Au moment de la rédaction de cet article, le projet compte environ 60 committers et 60 mainteneurs de composants, avec beaucoup de personnes effectuant des tâches doubles, triples et parfois sextuples. Mais la réalité est que dans WordPress 5.4 et 5.5, des centaines de commits ont été effectués par Sergey Biryukov. Je suis incroyablement reconnaissant pour le travail de Sergey. En même temps, j'ai l'impression que nous construisons par inadvertance un facteur de bus dans Core. La majorité des personnes ayant accès à Core Commit n'ont pas commis un seul ticket. De même, j'ai contacté tous les responsables des composants pour connaître leurs plans pour les prochaines versions et seulement 50 % des composants ont répondu.

Comment s'assurer que les personnes qui ont le pouvoir, et donc la responsabilité, d'aider à commettre et à gérer les contraventions sont impliquées ? Mais aussi, comment encourager les gens à démissionner et à se déclarer inactifs pour que de nouvelles personnes puissent intervenir ?

Ma carrière s'étend sur plus de 25 ans dans différentes industries, et une chose reste la même : lorsque les gens voient qu'il y a quelqu'un d'autre qui remplit un rôle, ils seront moins motivés et parfois même intimidés pour intervenir. La rareté ne stimule pas seulement les achats, elle génère de nouveaux engagements.

L'équipe communautaire, par exemple, tient à jour une liste des députés et leurs différents statuts. Je me demandais si Core pouvait faire quelque chose de similaire afin que, lorsque de nouvelles personnes souhaitent intervenir, elles puissent voir d'un coup d'œil quels composants manquent de mainteneurs. Les personnes qui se plaignent de "The Core Developers" ne les verront pas comme un blob, mais comme des individus qui, à tout moment, pourraient être inactifs pendant une période. Lorsque vous voyez qu'il n'y a en fait que quelques personnes qui examinent et s'engagent activement, vous pourriez être plus enclin à comprendre pourquoi tous les billets ne peuvent pas atteindre la ligne d'arrivée.

La documentation est la plus haute forme de générosité

Je le dis à chaque fois que je parle de contribuer à l'OSS : la documentation fait souvent défaut. Souvent, ce qui s'y trouve est obsolète.

Comment s'assurer que la documentation n'est pas une réflexion après coup, mais qu'elle est intégrée au processus de développement ?

Il y a beaucoup de travail consacré à la rédaction de notes de développement pour les changements qui affectent le développement, mais ce n'est pas la seule documentation nécessaire. Certains des processus décrits dans les manuels de base sont obsolètes, certains manquent parce qu'ils vivent dans l'esprit des contributeurs expérimentés.

En tant que grand fan de Gutenberg et d'un texte riche et engageant, j'aimerais que nos manuels tirent pleinement parti de la puissance de l'éditeur de blocs et soient plus invitants. En ce moment, ils sont un mur de texte et chaque fois que nous disons aux gens de regarder les manuels, je sens mon cœur se serrer.

Des solutions possibles, dont je ne suis pas sûre qu'elles soient techniquement réalisables, mais une fille peut rêver : se synchroniser avec GitHub pour résoudre au moins le problème de contrôle de version. Ensuite, recrutez, recrutez, recrutez et travaillez avec Documentation, Meta et Design pour fournir des manuels utiles, attrayants, lisibles et faciles à numériser.

Gardez une trace des pièces mobiles et travaillez comme un seul

L'autre chose que je remarque souvent est la façon dont les équipes, les focus et les composants fonctionnent en silos.

Ce n'est absolument pas fait pour être des gardiens, c'est juste la façon dont chaque équipe s'est auto-organisée au fil des ans.

Nous devons trouver un moyen d'avoir une vue d'ensemble de ce qui se passe dans la prochaine version et de toutes les pièces mobiles.

Trac est très granulaire et vous avez un certain nombre de rapports prêts à l'emploi, vous pouvez filtrer par jalons et voir combien de tickets se trouvent dans chaque composant, mais ce n'est qu'une partie de l'histoire.

Oui, je parle de trouver un moyen de gérer le projet dans son ensemble et non comme des bric et de broc.

Entrez GitHub. À un moment donné.

Cela n'arrivera pas de sitôt, mais j'espère que cela finira par arriver. Déplacez le développement et la gestion de projet de WordPress vers GitHub, comme Gutenberg l'a fait.

Je sais que pour beaucoup, ce sera une incitation à contribuer à WordPress d'une manière plus familière. Il baissera la barre à l'entrée, ce qui est toujours le bienvenu. Avec quelques tutoriels pratiques, il permettra aux personnes non techniques de contribuer à la documentation, aux tests et à la gestion de projet.

L'avenir est prometteur

Malgré tous les problèmes, ou peut-être à cause d'eux, l'avenir de WordPress est prometteur.

J'ai rôdé autour de plusieurs équipes au cours de ces années, et dernièrement, j'ai remarqué que plus de personnes se joignaient à nous, plus de personnes impliquées dans chaque version, plus de personnes assumant des rôles de leadership dans différentes équipes. J'ai aussi remarqué une augmentation de la diversité, ce qui est toujours un changement bienvenu.

Conclusion : WordPress a besoin de nous tous pour y arriver. J'espère vous voir à bord !