Il est notoire que le bugzilla de Mozilla peut s’avérer difficile à aborder et maîtriser. Pour vous guider dans ce labyrinthe, Liz Henry a rédigé un très bon article illustré sur son blog :  File a bug: the missing manual, now with unicorns.

Nous vous le proposons ici en espérant qu’il vous incitera à contribuer à Mozilla.

Si vous rapportez un bogue ou contribuez à un bogue dans le cadre de la communauté francophone, indiquez le avec le texte [mozfr-community] dans le champs whiteboard (voir ci-après).

Traduction : Sphinx pour MozFr.

Rapporter un bogue : le manuel qui manquait, maintenant avec des licornes

Lors d’innombrables conférences, j’ai entendu la réponse habituelle à la question « comment s’impliquer dans un projet open source ? ». Ça ressemble un peu à ça :

  • Étape 1 : rapporter un bogue !
  • Étape 2 : Envoyer un correctif ! (répéter les étapes 1 et 2 pendant un petit moment)
  • Étape 3 : Vous voilà maintenant prêt à écrire de nouvelles fonctionnalités et de nouveaux trucs ! Déployez vos ailes !

J’ai toujours pensé que c’était intéressant parce que cela représente une tentative pour rassurer les gens en leur disant qu’il n’y a pas forcément du développement et du code dès le début. Juste remplir un rapport de bogue, c’est le premier pas. Cela fait que des gens viennent dans des projets et se demandent vaguement comment trouver des bogues.

En tant que bugmaster pour Mozilla, une partie de ce que je veux réaliser est d’ajouter une étape : regardez tous les bogues que vous avez déjà rapportés, il y en a des tonnes et des tonnes, et voyez ce que vous pouvez faire pour améliorer les méta-données relatives à ces bogues.

Aujourd’hui sur Planet Mozilla, j’ai remarqué quelques très bons conseils de Jason Smith sur la meilleure façon de trouver des bogues : WebRTC testing: Try out conversat.io and file bugs. C’est vraiment sensé mais aussi pratique. Le blog de Jason a quelques billets comme celui-là qui conseillent de se tourner vers des domaines en particulier, comme WebRTC ou les applications Desktop Web, en ajoutant l’utilisation de ces outils dans votre vie quotidienne. Notre séquence d’ « implication dans un projet open source » ressemble donc maintenant un peu plus à ça :

  • Étape 1 : Trouvez une fonctionnalité qui pourrait être testée
  • Étape 2 : Trouvez comment l’utiliser régulièrement
  • Étape 3 : Utilisez-la
  • Étape 4 : Observez un comportement que vous pensez être un bogue
  • Étape 5 : RAPPORTER UN BOGUE (MAIS COMMENT ?)

Il faut connaître beaucoup de choses de ce milieu pour réellement rapporter un bogue dans le système compliqué qu’est bugzilla.mozilla.org (ou BMO).

Prenons donc l’exemple de WebRTC. Disons que vous avez suivi le conseil de Jason, utilisé conversat.io pendant un moment et que vous avez trouvé un BOGUE. Heureusement, Jason fournit un lien qui pointe directement vers Bugzilla dans le formulaire enter_bug, avec les entrées Produit et Composant pré-remplies afin qu’il corresponde à un bogue avec WebRTC (le composant) et Core (le produit). Les bogues dans BMO sont catégorisés selon le produit comme Firefox Desktop, Firefox pour Android, FirefoxOS, Thunderbird, etc. « Core » est le produit pour le code partagé entre beaucoup d’autres produits. Si vous étiez en train de rapporter un bogue de WebRTC en partant de zéro, vous ne sauriez probablement pas sous quel produit l’enregistrer, et pourtant vous auriez dû en choisir un. Donc merci beaucoup Jason de donner un lien avec le bon produit et le bon composant !

Attendez… Il y a encore beaucoup plus de contexte à assimiler. Ce n’est pas obligatoire mais c’est très appréciable une fois qu’il est compris !

Tout d’abord, vous devez avoir un compte Bugzilla pour que le lien fonctionne correctement. Si vous faites ça, vous serez un nouvel utilisateur de Bugzilla et certains champs du formulaire de bogue vous apparaîtront différemment : vous serez automatiquement dirigé sur un « formulaire guidé de champs de bogue » qui est divisé en plusieurs étapes, au lieu d’avoir le formulaire vous montrant la « vue avancée » complète avec plusieurs douzaines de champs et de menus déroulants.

Ensuite, pourquoi ne pas regarder la liste de tous les composants du produit Core. Cela représente une bonne partie des connaissances du domaine : un petit morceau de la carte ou de la géographie de Bugzilla. Comme vous pouvez le voir, il y a beaucoup d’autres composants en plus de Core. Descendez un peu jusqu’au WebRTC, vous pouvez voir qu’il y a plusieurs sous-catégories : WebRTC, WebRTC : Audio/Video, WebRTC : Networking (réseau) et WebRTC : Signaling (signaux). cliquer sur le composant général WebRTC pour voir une liste des bogues ouverts sur WebRTC. C’est là que la leçon de géographie devient utile.

En ce moment il y a 113 bogues ouverts pour WebRTC. Vous pouvez les consulter rapidement pour avoir une idée de ce que les autres ont pu trouver comme bogues. On y reviendra plus tard !

Le plus important maintenant est ce qui va suivre : est-ce que votre bogue a déjà été rapporté ? Suivant le nombre de bogues dans cette liste et votre degré de patience et d’intérêt, vous pourriez avoir envie de, soit parcourir et lire rapidement les résumés (le titre du bogue) ou soit de faire une recherche dans la page pour les mots qui peuvent correspondre au bogue que vous vous apprêtez à rapporter.

Si vous trouvez quelque chose dans cette liste que vous pensez être votre bogue, regardez y de plus près. Lisez le rapport et les commentaires pour essayer de comprendre ce dont ils sont en train de parler. Si c’est la même chose que votre bogue, vous pouvez avoir envie de laisser un commentaire décrivant ce que vous avez vu se produire.

Mais prenons le cas où vous n’avez pas trouvé votre bogue dans cette liste. Haha ! Et là, vous utilisez le lien du billet de blog original : lien pour rapporter un bogue sur WebRTC. Si vous êtes dans mon cas, ou êtes un utilisateur de Bugzilla qui a fait plus de 25 éditions ou commentaires à des bogues, vous verrez le formulaire avancé, qui est énorme :

(cliquez sur l’image réduite pour l’agrandir)

image 1 formulaire grand format

Si vous êtes un utilisateur de Bugzilla relativement nouveau, vous passerez par un formulaire guidé qui se décompose en plusieurs écrans. (Vous pouvez changer à tout moment pour avoir le formulaire avancé via un lien en bas de page si jamais le fait de passer par plusieurs écrans vous ennuie). Le premier écran pour une entrée de bogue guidée correspondra normalement à la sélection du produit et du composant. Étant donné que ceux-ci ont déjà été sélectionnés avec le lien pratique de Jason, vous pouvez commencer au deuxième écran pour renseigner un résumé de votre bogue. Dans ce cas, je rapporte une espèce d’invasion de licornes.

étape 2 avec licorne

Une fois votre résumé écrit, vous verrez une liste de bogues potentiellement similaires apparaître sous le champ du résumé. Il est important de les parcourir et de les lire pour voir si quelqu’un d’autre a déjà rapporté des licornes envahissant leur écrans de conversat.io dans Firefox. Ici, ce n’est clairement pas le cas.

étape 3 avec arc-en-ciel

Étant donné que personne n’a rapporté ce bogue, je clique sur « Mon problème n’est pas dans la liste » (en anglais : “My issue is not listed”) et je passe au troisième écran qui suggère comment décrire les actions ou les étapes pour reproduire le problème, ce qui se passe exactement lorsque j’observe un bogue et ce que je pense qui aurait plutôt dû se passer.

étape 3 image 4

Génial, nous avons rempli un rapport de bogue ! Revenons à cette liste « comment contribuer à un projet open source » :

  • Étape 1 : Trouvez une fonctionnalité qui pourrait être testée
  • Étape 2 : Trouvez comment l’utiliser régulièrement
  • Étape 3 : Utilisez-la
  • Étape 4 : Observez un comportement que vous pensez être un bogue
  • Étape 4.5 : Créez un compte sur bugzilla.mozilla.org
  • Étape 4.6 : Confirmez votre compte avec l’e-mail de confirmation
  • Étape 4.7 : Connectez-vous sur bugzilla.mozilla.org
  • Étape 5 : RAPPORTEZ UN BOGUE (et maintenant vous savez comment faire !!!)

Attendez, il y en a encore — enfin, si vous voulez retrouver votre cap sur cette carte de Bugzilla. Regardons à nouveau cette liste de tous les bogues ouverts à propos de WebRTC. Que pouvons-nous en tirer ?

Pendant que je regarde cette liste, elle me semble assez mystérieuse. Avec le langage contenu dans les résumés, je suppose que certains des bogues sont des notes de l’équipe de développement pour leur propre liste de trucs à faire, d’autres semblent avoir été découverts par des utilisateurs courants du logiciel. La première chose que je fais : trier la page de différentes façons pour voir ce qu’elle révèle. Trier les États (ou status en anglais) montre les bogues NON CONFIRMÉS en premiers et les NOUVEAUX juste en dessous. Il y en a un appelé getUserMedia gèle tout le système qui n’est pas encore confirmé et qui peut être un bon exemple.

En voici un intéressant : aucun événement lorsqu’un pair à distance disparaît. Mon aperçu de ce bogue va être différent du vôtre si vous êtes nouveau sur Bugzilla parce que j’ai plus de pouvoirs magiques comme la confirmation et édition de bogues ainsi que d’autres choses concernant l’administration. Il y a beaucoup de choses sur la page et c’est très chargé en texte. Vous devez apprendre à l’écrémer et à la filtrer mentalement afin de voir et de remarquer ce qui important à cet instant. Voici à quoi ressemble un bogue pour un nouvel utilisateur de Bugzilla :

bogue soumis par autre utilisateur

Ce que je peux déduire de cette lecture c’est qu’au moins une personne est en train de regarder les nouveaux bogues rapportés, les trie et travaille sur le projet. En fait, si je clique sur d’autres bogues concernant WebRTC, je peux lire et voir que Jason est très actif sur la plupart d’entre eux, ce qui n’est pas surprenant vu qu’il écrit des billets sur le sujet.

Le blog de Jason ressemble à un endroit plutôt utile pour trouver des endroits où accueillir des testeurs et des trouveurs de bogues. Vous pouvez aussi consulter les pages de la communauté Assurance Qualité de Mozilla (QMO) qui expliquent comment faire fonctionner des versions nightly et participer aux journées de tri et de test des bogues de l’assurance qualité (QA).

Cependant, le point le plus important ici, c’est que pour commencer à contribuer à un projet open source, à part rapporter un bogue exceptionnel découvert par hasard, il est super utile d’apprendre l’environnement d’un projet. Adoptez le projet et regardez autour pour apprendre ce qui s’y passe. Si vous êtes en train de rapporter un bogue, regardez les autres bogues. Regardez qui commente et qui travaille sur ces bogues. Rejoignez leur canal IRC et lisez leurs pages wiki et (souvent plus formel que les pages wiki) leur documentation pour les développeurs. Sinon vous pouvez utiliser Google pour en apprendre plus sur le projet et ce qui va avec. Dans notre cas, j’ai trouvé que conversat.io était assez récent et avait été développé en partie pour montrer ce qu’est WebRTC et ce qu’il peut faire.

Dans mes premières explorations, la grande transparence de Mozilla était clairement visible et m’a fait voir la fantastique profondeur technique que l’on peut atteindre juste en passant une demi-journée à lire et à naviguer dans les bogues. Pour la société dans laquelle nous vivons, nous devons nous rendre compte des implications que cela peut avoir pour l’éducation et le système éducatif. C’est une évolution culturelle importante et je suis heureuse d’y participer.