mardi, 23 avril 2013

Première contribution : rapporter un bogue sur Bugzilla

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.

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.

jeudi, 14 mars 2013

Firefox OS et l’évolution des API Web - par Brendan Eich

Dans cet article que MozFr a traduit pour vous ci-dessous, Brendan Eich qui est le créateur du JavaScript et l’un des fondateurs de Mozilla fait le point sur le succès qui accompagne le lancement de Firefox OS et sur l’intérêt des nombreuses API pour mobiles que Mozilla propose à la standardisation,  […]

Lire la suite

Optimiser les accès de variables JavaScript

Cet article est issu du blog de Luke Wagner. L’article original a été écrit en anglais par Luke Wagner. J’ai récemment fini un projet visant à améliorer la manière dont SpiderMonkey implémente les accès de variable, ainsi j’ai pensé qu’il était temps d’expliquer comment cela fonctionne désormais. En  […]

Lire la suite

mardi, 19 février 2013

L'assembleur du Web

Re-publication du billet de CLOCHIX sur son blog asm.js est un projet de recherche de Mozilla qui vise à améliorer les performances de JavaScript en n’utilisant qu’un sous-ensemble du langage, plus facile à optimiser. Il se compose de plusieurs sous-projets : la spécification du langage ;  […]

Lire la suite

lundi, 15 octobre 2012

IonMonkey arrive dans Firefox 18

Kraken

Cet article est issu du blog JavaScript de Mozilla. L’article original a été écrit en anglais par David Anderson. Depuis le lundi 12 septembre, IonMonkey, notre nouveau compilateur JavaScript à la volée, est arrivé dans Firefox 18. IonMonkey représente un grand pas en avant pour nos performances sur  […]

Lire la suite

jeudi, 4 octobre 2012

Ramasse-miettes incrémentiel dans Firefox 16

nonincremental.png

Cet article est issu du blog JavaScript de Mozilla. L’article original a été écrit en anglais par Bill McCloskey. Firefox 16 va être la première version à supporter un ramasse-miettes (en anglais Garbage Collector ou GC) incrémentiel. C’est une fonctionnalité majeure, ayant nécessité plus d’un an de  […]

Lire la suite

mercredi, 3 octobre 2012

Présentation du nouveau blog officiel de l'équipe JavaScript de Mozilla

La mission de Mozilla est de «  promouvoir l’ouverture, l’innovation et les possibilités offertes sur la toile  ». Les membres de l’équipe du moteur JavaScript ont une occasion unique de soutenir cette mission. Leur travail passe par des défis techniques tels que la création d’un ramasse-miettes  […]

Lire la suite

vendredi, 27 juillet 2012

about:csswg - Sources d'innovation

Cet article est issue d’une série d’article sur le fonctionnement du CSS Working Group au W3C. L’article original a été écris en anglais par Fantasai. Sources d’innovation Il y a eu de nombreux débats pour savoir si les standards devaient découler des implémentations ou si ce sont les  […]

Lire la suite

mardi, 24 juillet 2012

about:csswg - Processus de spécification


Lire la suite

samedi, 21 juillet 2012

about:csswg - Modularité

Cet article est issue d’une série d’article sur le fonctionnement du CSS Working Group au W3C. L’article original a été écris en anglais par Fantasai. Modularité de CSS Lorsque CSS Level 3 a été créé, il a été pensé comme un ensemble de spécifications modulaires permettant de recréer CSS Level 2 et  […]

Lire la suite

vendredi, 20 juillet 2012

about:csswg - Prise de décisions

Cet article est issue d’une série d’article sur le fonctionnement du CSS Working Group au W3C. L’article original a été écris en anglais par Fantasai. Prise de décisions Comme défini dans le processus du W3C, le CSS WG prend des décisions par consensus. Le consensus dans le CSS WG est généralement  […]

Lire la suite

mercredi, 18 juillet 2012

about:csswg - Communication

Cet article est issue d’une série d’article sur le fonctionnement du CSS Working Group au W3C. L’article original a été écris en anglais par Fantasai. Communication Le CSS Working Group communique régulièrement à trois niveaux différents : Liste de diffusion Les discussions techniques sur les  […]

Lire la suite

vendredi, 13 juillet 2012

about:csswg - Personnes et responsabilités


Lire la suite

samedi, 7 juillet 2012

about:csswg

Nous avons traduit pour vous une série d’articles écrits par Fantasai sur le fonctionnement du CSS Working Group, Fantasai est une employée Mozilla qui participe à l’élaboration du standard CSS depuis plus d’une dizaine d’années maintenant. On ne la remerciera jamais assez :)

Elle est un des piliers du CSS Working Group et cette série d’articles est une plongée unique dans l’un des groupes de travail du W3C les plus actifs et les plus emblématiques du travail de standardisation du consortium. Loin des clichés et des idées reçues, c’est une occasion unique de mieux comprendre le long travail des ces hommes et femmes de l’ombre qui œuvrent au W3C.

Ces articles ont été traduits par Jérémie Patonnier et Frédéric Bourgeon avec l’aimable autorisation de Fantasai. Nous les publierons dans les semaines qui viennent, pour vous mettre en appétit voici le premier article qui donne le sommaire des suivants…

Lire la suite

mardi, 19 juin 2012

BrowserID, implémentation en Java côté serveur

Il y a quelque temps Pierre Rudloff publiait un billet présentant BrowserID et expliquant comment mettre en place cette technologie. Je l’ai implémentée dans un de mes projets qui utilise du Java côté serveur (le framework Play!, pour être précis). Comme Pierre ne présentait le code serveur qu’en  […]

Lire la suite

mercredi, 13 juin 2012

Thunderbird Test Day

C’est jeudi et ce n’est pas ravioli :-) (Je tiens à préciser que cette phrase inepte n’est pas de moi mais de Ludovic Hirlimann… voila, c’est dit, c’est fait :P) Jeudi toute la journée, la communauté des utilisateurs de Thunderbird, le logiciel libre de messagerie de la fondation Mozilla, organise  […]

Lire la suite

lundi, 21 mai 2012

Le futur des animations sur le Web

À la demande de Clochix, voici un petit état des lieux rapide des discussions liées aux animations Web au sein du W3C. C'est aussi une occasion de voir comment se construit un standard Web.

Lire la suite

mercredi, 16 mai 2012

BrowserID

De plus en plus de sites utilisent des systèmes de connexion sans mot de passe comme Facebook Connect ou OpenID. Ces systèmes permettent à l'utilisateur de se connecter rapidement en un ou deux clics. Mozilla a sorti il y a quelque temps BrowserID[1], un système de connexion similaire, simple à  […]

Lire la suite

mardi, 15 mai 2012

La boîte à outils du développeur Web : Raphael

Cet article est le premier d'une série d'articles dédiés aux bibliothèques utiles que tout développeur Web devrait avoir dans sa boîte à outils. Le but est de montrer ce que ces bibliothèques sont capables de faire et comment les utiliser à leur plein potentiel. Ce premier article va vous présenter  […]

Lire la suite