Souvenez-vous du film des années 80 : « S'il y a quelque chose de bizarre et que ça n'a pas l'air bien, qui allez-vous appeler ? Chasseurs de fantômes! ” ? Dans Joomla, nous avons nos propres chasseurs de fantômes. Ils s'appellent le Bug Squad, nos propres forces spéciales, réparant des choses bizarres qui ne semblent pas bonnes et d'autres choses qui sont cassées. Mais qui sont ces gens ? Que font-ils? Et pourriez-vous être l'un d'eux? Lisez et sachez!
Quel est l'objectif principal de l'équipe ?
Jacob Waisner : L'objectif de l'équipe est de réduire le nombre de bogues dans Joomla. Il y a plus à cela cependant. Nous trions également les problèmes pour déterminer s'il s'agit réellement de bogues et travaillons avec les responsables de publication pour coordonner les corrections de bogues en fonction de la priorité.
Richard Fath : Notre mission est de réduire le nombre de bogues dans Joomla, comme indiqué sur le portail des bénévoles .
Mais tous ceux qui ont de l'expérience dans d'énormes projets logiciels savent que c'est un travail sans fin, une mission impossible, une tâche de Sisyphe. Chaque plus gros morceau de code non trivial aura des bogues, et même les corrections de bogues peuvent introduire de nouveaux bogues.
Notre objectif ne peut donc pas être d'avoir zéro bogue, car cela signifierait que nous ne toucherons pas au code pour autre chose que des corrections de bogues. Aucune amélioration, aucune nouvelle fonctionnalité, aucune nouvelle version de PHP prise en charge, et puis un jour dans un avenir lointain, vous n'aurez peut-être aucun bogue que vous connaissez, mais il pourrait encore en rester des inconnus.
L'objectif ne peut être que de limiter autant que possible le nombre de bogues. Par conséquent, nous voulons gérer au mieux les bugs afin qu'ils soient rapidement triés des autres problèmes comme par exemple les améliorations et résolus dans un délai raisonnable.
Quelle est votre place dans l'écosphère de Joomla ?
Richard : Nous faisons partie du département de production.
Quels rôles avez-vous au sein de l'équipe?
Richard : En plus des membres "normaux" de l'équipe, nous avons tous les responsables des versions dans notre équipe, nous avons donc un canal de communication rapide avec eux.
Membres de l'équipe : présentez-vous s'il vous plaît !
Jacob Waisner (chef d'équipe) : J'ai commencé à contribuer à Joomla en 2015 et j'ai commencé à trier les problèmes signalés. La vraie vie m'a tenu à l'écart pendant un moment peu de temps après ce point. J'ai pu rejoindre l'équipe en 2020. Bien que je ne sois pas spécialisé dans un langage de codage, je travaille pour tester les relations publiques ainsi que les problèmes de tri dans le tracker.
Richard Fath (chef d'équipe adjoint) : Après être devenu un contributeur fréquent au fil des ans, on m'a demandé en mai 2019 de rejoindre l'équipe. Il y a quelques mois, Jacob m'a demandé d'être le chef d'équipe adjoint, et j'ai accepté, alors j'aide un peu aux réunions d'équipe quand il n'a pas le temps. En dehors de cela, je partage mes connaissances sur les sujets liés aux bases de données, à la mise à jour et à l'installation et sur Git et GitHub.
Christiane Maier-Stadtherr : J'ai rejoint l'équipe après une série de tests et pull requests que j'avais fait pour Joomla 3 en 2019 si mes souvenirs sont bons. Je fais la même chose que tous les autres membres : vérifier les nouveaux (et anciens) problèmes, écrire parfois une solution, tester les PR, principalement pour l'interface utilisateur.
Nicola Galgano : Je suis membre de cette équipe depuis un certain temps, j'ai eu l'honneur de diriger cette équipe pendant quelques années, je partage principalement mon expertise sur sql, les services Web et les questions cli principalement.
Troy Hall : Je suis connu sous le nom de « Bear » ou N6REJ et je suis membre de JBS depuis 2010. J'ai tendance à oublier des choses, mais heureusement, l'équipe s'en accommode. Ma place principale est de tester les bogues signalés ou lorsque j'en trouve un, j'essaie de retrouver sa cause première et de le corriger. Je suis passionné par notre iconographie et notre gestion multimédia.
Rick Spaan : L'année dernière, je me suis davantage impliqué dans la contribution au code lorsqu'il y avait des bogues dans le modèle Cassiopeia. Parce que je créais mon propre cadre de modèles basé sur Cassiopeia, j'avais besoin de corriger certaines choses. Au cours du processus de résolution des problèmes, j'ai également commencé à effectuer de nombreux tests de correctifs, car de nombreux problèmes ont été résolus dans d'autres demandes d'extraction. Mes activités ne sont pas passées inaperçues et Richard m'a demandé de rejoindre l'équipe, ce que j'ai fait avec plaisir. Je fais partie de l'équipe depuis 3 mois maintenant et c'est bien d'être membre d'une équipe aussi dévouée ! Ma passion est le développement frontend et j'espère que mon expertise sera un bon ajout à l'équipe.
À quelle fréquence avez-vous des réunions et comment se déroulent-elles ?
Jacob : Nous organisons nos réunions toutes les 2 semaines via Glip et elles se déroulent avec un ordre du jour de base ouvert à tous les membres de l'équipe pour ajouter tout sujet dont ils souhaitent discuter.
Quels outils utilisez-vous pour travailler ensemble ?
Richard : Nous utilisons notre canal d'équipe sur Glip pour le chat textuel lors de nos réunions bihebdomadaires et chaque fois que nous avons besoin de parler avec d'autres membres de l'équipe, et les canaux publics sur Glip, par exemple pour demander à la communauté de tester des pull requests ou de faire des annonces. Problèmes et demandes d'extraction que nous gérons sur GitHub et dans le suivi des problèmes .
Si vous aviez trois mots pour décrire l'ambiance au sein de l'équipe, quels seraient ces mots ?
Troy : Serviable, sans jugement, amical
Richard : Collaboratif, serviable, amical
Nicola : Per aspera ad astra (JCM : cela se traduit approximativement par « à travers les difficultés des étoiles »)
Christiane : Serviable, professionnelle, exigeante
Jacob : Professionnel, collaboratif, passionné
Rick : Dévoué, ouvert, coopératif
Comment l'équipe s'est-elle développée au cours des dernières années ?
Troy : Pendant plusieurs années, l'équipe était pratiquement morte. Avec les membres dont il dispose actuellement, il est à nouveau vivant et contribue fortement à la croissance de Joomla!
Richard: Je n'ai pas beaucoup regardé l'activité de l'équipe avant de rejoindre en avril 2019, mais je pense que Troy a raison et que l'équipe n'était pas très active pendant un certain temps avant cette date. À cette époque, Nicola avait commencé comme chef d'équipe et avait invité de nouveaux membres comme moi et l'avait ainsi amenée à son niveau d'activité actuel. Merci Nicolas pour cela.
Jacob : Comme mentionné par d'autres membres de l'équipe, l'activité était en baisse. L'accent étant désormais mis sur l'arrivée de nouveaux membres dotés d'un large éventail de compétences, allant de la programmation à la capacité de tester les relations publiques, nous avons constaté une augmentation de l'activité. Une coordination supplémentaire avec les responsables des versions nous a également aidés à rester en ligne et à fournir le support nécessaire pour chaque version de manière plus efficace.
Que considérez-vous comme votre plus grand défi ? Que faudrait-il pour réparer ça ?
Troy : Il y a trop de documentation ancienne/contradictoire sur la configuration d'un serveur de développement moderne et des programmes associés pour contribuer au code de Joomla !
Un guide étape par étape très détaillé, y compris la conformité au code, doit être fait pour chacun des principaux IDE utilisés. PHPStorm, Visual studio code serait le top 2 j'imagine.
Christiane : Le travail est souvent chronophage et exigeant. Nous devons vérifier chaque numéro et PR. Nous devons établir si quelque chose est un problème valide ou non, si un test est un test valide ou non. Parfois c'est très facile, parfois des connaissances particulières et beaucoup de temps sont nécessaires. Le plus grand défi réside dans les problèmes qui ne sont pas clairs et qui ne peuvent pas être reproduits.
Avez-vous besoin de volontaires supplémentaires, et si oui, à quel titre ?
Jacob : Les bénévoles sont toujours nécessaires. Cela ne signifie pas nécessairement que vous devez faire partie de l'équipe pour contribuer. Nous avons de nombreux problèmes ainsi que des relations publiques qui peuvent utiliser quelqu'un pour valider et tester. Si vous avez des compétences en programmation, de nombreux problèmes nécessitent une assistance.
Richard : Nous n'avons jamais assez de bénévoles. Mais comme le dit Jacob, vous n'avez pas nécessairement besoin d'être un membre de l'équipe. De toute urgence, nous avons besoin de personnes qui testent des correctifs pour les bogues et les problèmes, appelés « demandes d'extraction », sur GitHub.
Troy : La documentation est fortement nécessaire. Il y a trop de "vaudou" qui se passe, surtout compte tenu des changements dramatiques dans l'architecture qui se sont produits au cours des 2 dernières années.
Rick : Il y a cette idée fausse selon laquelle seul un développeur chevronné peut aider à tester les correctifs. De nombreux correctifs peuvent facilement être testés par des intégrateurs ou même des utilisateurs. Le problème est que les instructions de test ne sont pas toujours aussi claires qu'elles devraient l'être, ce qui peut être décourageant. Par conséquent, écrire de bonnes instructions de test est vraiment important. Le défi consiste maintenant à convaincre les gens que commencer à tester des correctifs n'est ni difficile ni amusant à faire.
Les JUG peuvent également jouer un rôle important en aidant à tester les correctifs. J'encourage chaque JUG à intégrer une session de test de patch dans son programme régulier.
Si nous voulons vous aider, comment pourrions-nous faire cela ? Occasionnellement, ou en rejoignant l'équipe, ou peut-être les deux ?
Richard : Vous pouvez nous aider en signalant les problèmes sur GitHub et dans le suivi des problèmes , en commentant les problèmes si vous pouvez aider à l'enquête, en créant des demandes d'extraction sur GitHub ou en testant les demandes d'extraction d'autres personnes.
Si vous le faites de temps en temps, ça va, mais bien sûr, nous sommes heureux si vous trouvez le temps de le faire plus régulièrement.
Si tel est le cas, nous remarquerons votre activité GitHUb après un certain temps, et notre chef d'équipe vous enverra une invitation à rejoindre notre équipe.
En tant que membre de l'équipe, vous nous aideriez - en plus de votre contribution continue - avec les éléments de "gestion", comme la définition de demandes d'extraction au RTC (prêt à valider, c'est-à-dire prêt à être fusionné dans le code source) lorsqu'ils ont 2 tests humains réussis ou en leur attribuant des étiquettes pour mieux les catégoriser.
Toute personne qui signale des problèmes peut être très utile en procédant comme suit :
- Donnez à votre problème un titre significatif, fournissez les détails nécessaires et restez réactif pour obtenir des éclaircissements, alors vérifiez votre courrier électronique de temps en temps pour le courrier de GitHub concernant votre problème. Ne vous contentez pas de poster un problème et de partir.
- Tout ce qui ne fonctionne pas comme prévu n'est pas un bogue. La définition d'un bogue est que le logiciel ne se comporte pas comme souhaité par le programmeur. Le mot « bogue » dans ce contexte vient de l'ancien temps des ordinateurs à tube à vide lorsque de vrais bogues provoquaient des courts-circuits, de sorte que l'ordinateur calculait des résultats étranges. Donc, ne donnez pas à votre problème un titre comme "Bug dans Joomla" alors qu'il s'agit simplement d'un problème UX qui pourrait être une amélioration ou juste une question de goût.
- Soyez disponible pour tester un correctif (pull request) pour votre problème. Souvent, il faut un certain environnement, une configuration ou des données pour pouvoir reproduire un problème, et puisque vous avez rencontré le problème, vous avez tout cela. Si possible, effectuez une sauvegarde complète (fichiers et base de données) que vous pourrez utiliser ultérieurement sur un sous-domaine ou un environnement de test local pour reproduire le problème et tester le correctif. Chaque pull request nécessite 2 tests humains réussis, donc avec votre test, il aura déjà 50% des tests requis.
Troy : articles détaillés et facilement consultables sur les changements de code.
