Retour sur WP 4.9.5 : quelques réflexions sur la direction d’une version mineure de WordPress

Note : cet article est une traduction de l’article que j’ai publié sur Make/Core, en anglais.

WordPress 4.9.5 est sorti il y a maintenant une quinzaine de jours, à l’heure prévue, et sans problème particulier.

Avec Daniel James, nous avons eu le plaisir de co-diriger cette version mineure du CMS, avec l’aide inestimable de Sergey Biryukov en tant “qu’assistant” et le mentorat de Jeff Paul. La particularité de cette release, c’est que nous étions deux co-lead qui contribuons au core de WordPress depuis peu de temps, et nous ne sommes pas Core Committers. Encore merci à tous de nous avoir fait confiance pour cette tâche.

Voici quelques feedbacks et conseils que je souhaitais partager, et qui permettront peut-être à d’autres contributeurs de s’impliquer dans une telle aventure.

To lead a WordPress release, you don’t have to be a core committer, you have to deeply care about the WordPress open-source project.

En français : Pour diriger une version de WordPress, vous ne devez pas obligatoirement être core-committer, vous devez surtout avoir envie de prendre soin du projet WordPress.

Au départ, je me demandais bien comment Daniel et moi pouvions prétendre diriger une version de WordPress sans avoir d’accès commit.

En réalité, il y a de nombreuses tâches qui ne sont pas liées au développement du Core lui même, mais qui demandent une bonne connaissance de l’écosystème et de son fonctionnement. Voici quelques exemples de tâches à réaliser :

• Triage : le tri des tickets et de leur statut. C’est une tâche qui prend beaucoup de temps, car il faut plonger dans les tickets, lire l’ensemble des discussions et vérifier si les patchs apportés sont prêts à atterrir dans votre version mineure.
• Bug scrub meetings : ce sont des réunions où les tickets du Trac sont triés afin de vérifier si les correctifs et améliorations sont en bonne voie et de demander aux Component Maintainers, designers, spécialistes de l’accessibilité ou focus leads d’intervenir pour aider à leur résolution. Il faut prévoir un bugscrub par semaine, voire deux au fur et à mesure que l’on s’approche de la release.
• Dev chats : les dev chats sont les réunions hebdomadaires de la team Core afin d’évoquer l’avancée de la release en cours, de parler des avancées à venir et de placer le focus sur des points particuliers. J’ai eu un moment difficile de ce côté là pour le premier devchat que j’ai tenu avec le lancement d’une discussion animée autour du merge proposal de Gutenberg et du versionnement de WordPress. Dans ce genre de situation, il faut s’en tenir à une approche rationnelle et essayer de faire ce que l’on peut pour que tout le monde puisse s’exprimer.
• Écriture d’articles, réponse à des tickets sur Trac, édition du Codex, et tout ce qui concerne la communication. Cela prend beaucoup de temps et nécessite d’être bien préparé.

Il faut aussi bien s’organiser pour le processus de release.

Les moments clés d’une release WordPress

• J-30 à J-15 : voilà, vous êtes responsable de la prochaine version mineure de WordPress :
  • Vous devez maintenant faire le tour de tous les tickets tagués pour cette version mineure. Prenez le temps de bien prendre connaissance de chacun de ces tickets. Lors de vos bugscrubs, vous devrez être à l’aise avec chacun d’eux, et surtout avec leur avancement et dernières discussions. N’hésitez pas à poser des questions directement aux Component Maintainers associés.
  • N’hésitez pas à faire le tour d’autres tickets tagués pour la version majeure suivante et déjà commités. Il est tout à fait possible de les rapatrier dans votre mineure si ce sont des correctifs (et pas des améliorations) auto-contenues et qui n’entraînent aucune création de nouveau fichier dans le Core. Nous avons pu en rapatrier 5 ou 6 sur WP 4.9.5. Personnellement, je me suis directement fait un tableur avec l’ensemble des tickets à surveiller. Ce document m’a énormément servi par la suite.
  • Préparez chaque bugscrub et devchat en avance : mieux vaut n’avoir qu’à faire des copier-coller lors de ces réunions afin de pouvoir suivre aussi les discussions.
  • Demandez un accès pour pouvoir rédiger des posts sur Make/Core et pour pouvoir notifier les participants au channel Slack #core avec la commande @here.
• J-15 – version beta :
  • Dernier bug scrub : tous les tickets doivent être commit sur la branche. Ceux qui ne sont pas prêts doivent être “punt” pour la version suivante. Ne prenez pas de risque.
  • Un jour avant, prendre contact avec le Mission control pour s’assurer que quelqu’un sera disponible pour construire le package de votre RC. Ne faites pas comme nous : nous nous sommes retrouvés avec une beta prête mais sans personne pour construire le package. Il faut prévenir le Mission control en avance !
  • Publiez votre post sur Make/Core : réutilisez le format des posts précédents et indiquez les changements pour que les gens puissent tester votre version beta.
• J-7 – Release candidate :
  • Bugscrub final : quelques derniers tickets peuvent être commit pour la RC, mais ils doivent avoir été vérifiés par un core-committer expérimenté et être approuvés. D’ailleurs, deux vérifications valent mieux qu’une.
  • Un jour avant, prendre contact avec le Mission control pour s’assurer que quelqu’un sera disponible pour construire le package de votre RC.
  • Publiez votre post sur Make/Core.
  • Modifiez le numéro de version et mettez à jour le changelog de tous les thèmes modifiés par votre release. Voici le ticket Trac que j’ai utilisé pour l’occasion.
• J-2 :
  • Prise de contact avec la team Akismet pour vérifier si une nouvelle version doit être livrée avec la release.
  • Prise de contact avec les personnes chargées des bundle themes pour leur demander de se préparer à livrer la nouvelle version des thèmes sur le repo w.org.
  • Prise de contact avec le Mission control afin de leur vérifier leur disponibilité pour le jour J.
• J-1 :
  • Prise de contact avec la team Security (généralement ce sont eux qui viendront vers vous) pour savoir si des patchs de sécurité vont atterrir dans votre release (nous en avons eu trois). Évidemment, ces informations sont confidentielles, vous ne pouvez pas les communiquer.
  • Préparer le changelog de la nouvelle version avec la liste complète des changements pour le changelog du Codex (attention, si la release contient des patchs de sécurité appliqués à toutes les branches supportées, il faudrait faire une nouvelle page pour chaque version !) et pour le post Make/Core.
• Jour J :
  • Préparation des builds (branche courante + branches précédentes si un patch de sécurité est livré) avec les personnes du Mission control.
  • Demander à la team Meta de préparer la liste des contributeurs de la nouvelle version et de mettre à jour l’API Credits.
  • Préparer le post Make/Core et le post pour le blog général, qui doivent être publiés juste après le lancement des auto updates.
  • Préparer quelques phrases types telles que “@committers please refrain from committing while we package the 4.9.5 release.” ou “Heads up to everyone following along: We’re in the process of releasing right now. You’ll see some builds appear in this channel, but we have not released until there is a new post on WordPress.org/news/. Please do not tweet, publish, or otherwise announce a release until there is a public post about it on WordPress.org” pour le slack, à répéter régulièrement pendant le processus de build.
  • Préparer des instances de test en local pour tester chaque package de chaque version de WordPress, sur différents environnements PHP. Avec un peu de chance, d’autres contributeurs pourront vous aider à tester les packages de leur côté.

Voilà, c’est le grand jour, la release est construite et les mises à jour automatiques vont être faites sur les installations WordPress du monde entier. N’hésitez pas à demander au Mission control quelques statistiques, les chiffres sont incroyables. Il ne sont malheureusement pas communicables publiquement mais cela vous fera certainement plaisir de connaître en temps réel le nombre de personnes qui sont en train de profiter de votre travail.

Au prochain devchat, vous suivrez avec attention les retours de la team Support Forum qui vous donnera les retours des utilisateurs. Heureusement, dans notre cas, rien à signaler.

Quelques notes en vrac

• Pensez à prévenir les gens du Mission control un jour ou deux avant chaque release (beta, RC, release finale). Sans eux, vous ne pouvez rien faire ! Lors de la beta et de la RC, nous n’avons pas très bien géré cela et nous avons dû nous organiser un peu au dernier moment. Merci aux gens du Mission control qui se sont montrés compréhensifs et bienveillants.
• Une difficulté lorsque vous êtes relativement nouveau dans le développement du Core, c’est de trouver les bonnes personnes a qui s’adresser. Il ne faut pas hésiter à prendre contact avec un maximum de personnes, elles sauront vous aiguiller vers les gens qui pourront vous aider. Souvenez-vous que vous ne pouvez pas construire une release de WordPress seul.
• N’hésitez pas à entrer en contact directement avec les gens qui peuvent vous aider : Component Maintainers, Focus leads, Theme and/or Plugins team, Mission control, Security. Un petit message de présentation au tout début de la release ne fait pas de mal, et tout le monde sera très content de vous aider si besoin.
• Pensez aussi à suivre autant de component/focus meetings que possible. Certains changements peuvent affecter votre release et cela vous permet de savoir comment avancent certains tickets.
• Pensez à prévoir environ trois soirées par semaine à réserver à la release pendant un mois. Cela dépend de votre fuseau horaire mais en ce qui me concerne, j’ai dû réserver au minimum tous mes mardis et mercredis soir, parfois jusqu’à très tard dans la nuit. En dehors, il faudra aussi suivre ce qui se passe dans les tickets tout au long de la semaine. Parlez-en à votre patron pour vous organiser, je remercie d’ailleurs Whodunit, l’agence WordPress où je travaille, de m’avoir donné un peu de temps.
• Organisez-vous bien afin de ne surtout pas avoir de surprise au dernier moment. Par exemple, pour le “Try Gutenberg Callout”, nous étions prêts à l’intégrer ou non, et nous avons envisagé les deux solutions, que ce soit sur l’organisation générale ou pour la rédaction des changelogs et billets de blog sur Make/Core.
• Si vous fonctionnez en co-lead (ce que je vous souhaite), alternez le lead de façon égale afin que chacun puisse profiter de l’expérience du triage, des bugscrubs, des devchats et des différentes releases.
• De façon plus personnelle, si vous ne pratiquez pas un très bon anglais ce n’est pas la fin du monde : concentrez vous sur le fait de faire passer vos idées avant tout. Personne ne vous reprochera de ne pas parler un anglais parfait. Les contributeurs WordPress sont des gens gentils, compréhensifs et professionnels.
• Profitez de tout cela, car le temps passe très vite !

Pour conclure, je dirais que diriger un projet open-source, c’est avant tout permettre aux gens qui sont derrière de s’organiser pour le mener à bien, cela compte bien plus que les détails techniques du projet.