Difference between revisions of "Outil de suivi des anomalies"
m |
|||
Line 54: | Line 54: | ||
== Les types de demandes == | == Les types de demandes == | ||
Il existe deux principaux types de demandes : les bugs et les propositions | Il existe deux principaux types de demandes : les bugs [[Image:Issue Type-Bug.gif]] et les propositions [[Image:Issue Type-New Feature.gif]]. | ||
* Un rapport de bug est composé d'une description du problème et des étapes pour le reproduire. | |||
* Une proposition | * Une proposition contient une description détaillant le principe de la nouvelle fonctionnalité souhaitée. | ||
* Les demandes sont affichées aux autres utilisateurs qui peuvent les compléter. | * Les demandes sont affichées aux autres utilisateurs qui peuvent les compléter. | ||
* Les demandes les plus populaires accumulent les votes. | * Les demandes les plus populaires accumulent les votes. | ||
Line 65: | Line 65: | ||
L'avancement d'une demande importée est visible par son statut : dès que les modifications sont réalisées et en attente d’intégration dans le client, la demande reçoit le statut '''"Fix Pending"''' (Correction en attente). Une fois la modification ajoutée au client et après confirmation de la correction par [[QA Portal|l’assurance qualité de Linden Lab]] et les résidents, la demande passe à '''"Resolved"''' (Traitée) ou '''"Closed"''' (Fermée). Une demande peut aussi être fermée si elle est non reproductible, mal classée, incomplète ou si elle doublonne une autre demande. | L'avancement d'une demande importée est visible par son statut : dès que les modifications sont réalisées et en attente d’intégration dans le client, la demande reçoit le statut '''"Fix Pending"''' (Correction en attente). Une fois la modification ajoutée au client et après confirmation de la correction par [[QA Portal|l’assurance qualité de Linden Lab]] et les résidents, la demande passe à '''"Resolved"''' (Traitée) ou '''"Closed"''' (Fermée). Une demande peut aussi être fermée si elle est non reproductible, mal classée, incomplète ou si elle doublonne une autre demande. | ||
== Signaler un bug ou proposer une fonctionnalité == | == Signaler un bug ou proposer une fonctionnalité == |
Revision as of 11:55, 15 January 2009
Avertissement | |
La traduction de cet article est obsolète. Pour accéder au contenu le plus récent, veuillez vous reporter à la version anglaise. Si vous le souhaitez, vous pouvez participer à la mise à jour de la traduction de cet article en vous inscrivant à la page Community Translation Project. set version=2 |
This article needs an update to reflect recent changes in the base article located at Issue tracker. When you're done with the update, change the {{Help/CODE|Parent=Issue tracker|BugFixes=*}} part to {{Help/CODE|Version=2|Parent=Issue tracker|BugFixes=*}}. Thank you for your help!
Portail d'Aide & Base de connaissances: |
Avatar | Bugs | Client | Communication | Communauté | Lexique | Multimédia | Navigation | Objet | Tutorials Vidéo | Terrain | Wiki | Divers |
|
|
Qu'est-ce que JIRA ?
Le site JIRA, consultable à l'adresse http://jira.secondlife.com, est une base de données qui référence les bugs et les propositions des résidents de Second Life. Vous pouvez y retrouver et compléter les problèmes que vous rencontrez sur les clients ou le site officiel de Second Life. Cette page a pour but de vous familiariser avec cet outil.
Plus précisément, JIRA est un outil de gestion des anomalies édité par Atlassian. Il est utilisé par la communauté open source de Second Life et est appelé JIRA Public, PJIRA, ou plus simplement JIRA.
Les types de demandes
Il existe deux principaux types de demandes : les bugs et les propositions .
- Un rapport de bug est composé d'une description du problème et des étapes pour le reproduire.
- Une proposition contient une description détaillant le principe de la nouvelle fonctionnalité souhaitée.
- Les demandes sont affichées aux autres utilisateurs qui peuvent les compléter.
- Les demandes les plus populaires accumulent les votes.
- Les programmeurs de la communauté open source peuvent joindre leurs corrections ou détailler les modifications nécessaires.
- Les votes et les réunions de tri aident à établir les demandes prioritaires.
- Les demandes approuvées par Linden Lab sont ensuite importées dans le JIRA privé des développeurs pour être étudiées et corrigées.
L'avancement d'une demande importée est visible par son statut : dès que les modifications sont réalisées et en attente d’intégration dans le client, la demande reçoit le statut "Fix Pending" (Correction en attente). Une fois la modification ajoutée au client et après confirmation de la correction par l’assurance qualité de Linden Lab et les résidents, la demande passe à "Resolved" (Traitée) ou "Closed" (Fermée). Une demande peut aussi être fermée si elle est non reproductible, mal classée, incomplète ou si elle doublonne une autre demande.
Signaler un bug ou proposer une fonctionnalité
Règles de base
|
Restez à jour
- Consultez les notes de versions pour connaître les derniers développements du client. Les informations sur les nouveaux bugs et sur les modifications volontaires y figurent. Par exemple, l’interdiction de vendre un terrain pour 0L$ n'est pas un bug mais une fonction voulue par les développeurs.
- Vérifiez que les pilotes de votre carte graphique sont à jour.
Vérifiez si votre bug a déjà été signalé
Avant d'ouvrir une demande, vérifiez déjà la base de connaissance du support et regardez si le statut de la grille fait état d'un problème sur la grille.
Éviter les doublons est très important. Leur gestion représente un important travail de tri tant pour les Lindens que pour les résidents. Il est plus efficace de concentrer le suivi d’un bug sur une demande unique : les demandes les plus actives ont bien souvent une plus grande priorité.
Une fois connecté à Jira, vous aurez accès aux filtres de recherche. Vous pourrez ainsi choisir d’afficher les demandes non résolues pour chaque projet. D'autres filtres vous permettront d'affiner votre recherche. Vous pouvez créer et enregistrer vos propres filtres ou lancer de nouvelles recherches depuis la zone de « Recherche Rapide ». Cette recherche est indispensable avant la création d'une nouvelle demande.
Si vous constatez que votre bug est déjà signalé, vous pouvez continuer à aider :
- en laissant un commentaire contenant des informations supplémentaires
- en ajoutant une autre façon de reproduire le bug
- en votant pour la demande et montrer qu'elle est importante
Signaler un bug
- Connectez-vous sur Jira.
- Cliquez sur "Create a new issue" (Créer une demande) dans la barre des menus.
- Sur la première page :
- Choisissez le projet correspondant le mieux au bug à signaler. Attention : les failles de sécurité doivent êtres soumises directement à l'équipe de sécurité (voir Failles de Sécurité).
- Choisissez "Bug" (Bogue) dans la zone Issue type (Type de demande).
- Cliquez sur "Next" (Suivant).
- Sur la deuxième page:
- Dans Summary (Résumé), entrez un descriptif clair et concis du bug.
- Dans Priority (Priorité), indiquez la gravité du bug. Par exemple, un bug "Showstopper" rend le programme inutilisable alors qu'un bug "Low" est mineur. Cliquez sur l'icône d’aide pour plus de détails.
- Dans Components (Composants), choisissez les composants affectés par le bug. Vous pouvez choisir plusieurs composants en utilisant la touche Ctrl.
- Dans Versions, précisez la version affectée par le bug. Vous devez choisir les versions où le bug a pu être observé. Choisissez "First Look" uniquement si le bug ne s'applique qu’à la version First Look.
- Dans Environment (Environnement), reportez la configuration de votre système. Indiquez par exemple si le bug ne se produit qu’avec un certain matériel ou une certaine configuration logiciel. Par exemple, "Arrive seulement avec Mac OS X 10.4.1," ou "Vu seulement avec la carte NVIDIA GeForce Go 7800," etc. sont des commentaires trés intéressants. La meilleure façon de connaître votre configuration est de reprendre celle donnée depuis le menu Aide > À propos de Second Life... Certains éléments peuvent être révélateurs comme le modèle de carte graphique pour les problèmes de rendu ou le modèles de casque audio pour les problèmes de chat vocal. Si la configuration importe peu, laissez cet espace vide.
- Dans Description, donnez une description du bug qui contient :
- Les étapes pour reproduire correctement le bug ou du moins une description de sa cause. Essayez de donner une description simple mais précise pour permettre la reproduction du bug. Plus la reproduction sera plus simple, plus la cause du bug sera facile à déterminer.
- Le résultat observé (ce qui arrive quand le bug se produit).
- Le résultat attendu (ce qui aurait du se produire).
- Tous les éléments susceptibles d'aider, comme les liens vers le forum ou les articles de blog.
- Ne donnez pas de renseignements personnels !
- Si vous avez une capture d'écran ou une vidéo ou tout autre fichiers concernant le bug, vous pouvez l'attacher en pièce jointe. Les fichiers ont une limite de taille de 10 Mo. Il vous sera toujours possible d’attacher des fichiers supplémentaires plus tard. Consultez la page Debug Help pour connaître les différentes façons de fournir de tels renseignements.
- Si vous désirez joindre une correction, précisez la version source sur laquelle s’appuie votre patch et cochez l’option Patch attached.
- Enfin, cliquez sur "Create" (Créer) pour publier la nouvelle demande.
Proposer une nouvelle fonctionnalité
Le processus est semblable au signalement d’un bug avec quelques différences :
- Choisissez "New Feature" (Nouvelle fonctionnalité) dans la zone Issue type (Type de demande).
- Dans la description, décrivez clairement l’implémentation et la fonctionnalité désirée. Assurez-vous que cette dernière n’a pas déjà été proposée. Vous pouvez aussi consulter notre blog pour en savoir plus sur nos projets en cours.
Signaler une faille de sécurité
Les failles de sécurité sont des bugs permettant d’abuser des autres résidents, de modifier/copier/transférer les objets des autres ou de compromettre la grille ou la vie privée des résidents. Les failles de sécurité doivent être signalées directement à l’équipe de sécurité. Pour plus de réactivité, vous pouvez envoyer directement le descriptif de la faille à cet e-mail. Lisez cette page pour plus d'infos.
Restez poli
Les règles de la communauté de Second Life s'appliquent à tous les domaines de Second Life, y compris JIRA. Un résident ne respectant pas ces règles peut se voir interdire l'accès à JIRA. Exemples d'actions pouvant entraîner un bannissement de JIRA :
- Utiliser JIRA pour faire de la publicité ou promouvoir une cause, un blog, un site Internet ou tout sujet non lié au problème.
- Provoquer par des message incitant à la haine ou attaquant un autre résident. Tout message contrevenant à cette règle sera effacé.
- Utiliser JIRA pour des discussions privées. Poster des opinions personnelles hors sujet est interdit. L’objectif du Jira est de trouver des solutions aux problèmes techniques. Nous apprécions les commentaires productifs.
- Faire des guerre d'édition. Les modifications répétées relatives à la résolution, la priorité ou la classification d’une demande sont interdites. En cas de désaccord avec un autre résident, utilisez les commentaires de la demandes pour en discuter.
Votez
Vous pouvez voter pour l’ajout de nouvelles fonctionnalités et la correction de bugs. Le tri des bugs par nombre de votes est disponible ici. JIRA utilise le vote par approbation, vous pouvez voter pour autant de demandes que vous voulez, mais vous êtes limité à un vote par demande. Les votes sont utilisés pour établir les priorités. La faisabilité et la durée de développement de la nouvelle fonctionnalité ou de la correction du bug sont également prises en compte. Une demande avec beaucoup de votes ne sera pas forcément résolue avant une demande en ayant moins mais dont la correction est plus facile.
Surveillez l’état de votre demande
Les développeurs consultent régulièrement les demandes créées sur JIRA et sont donc susceptibles de vous demander des informations supplémentaires. Relisez régulièrement votre demande pour voir si des commentaires ou des questions ont été rajoutés.
Les états d'une demande
- Open (Ouverte)
- Demande attribuée ou non à un développeur.
- In progress (En cours)
- Un développeur travaille au traitement de la demande.
- Reopened (Rouverte)
- La demande a été fermée puis rouverte pour signaler que le problème était toujours présent.
- Resolved (Traitée)
- Un traitement a été effectué et est en attente de vérification par le rapporteur. La demande reçoit une résolution :
- Fixed (Corrigé)
- Le bug est corrigé dans la version officielle de Second Life.
- Fix Pending
- Le bug est corrigé dans une prochaine version.
- Contact Support
- Le problème signalé doit être traitée en passant par le support.
- Won't Finish
- Le responsable de la fiche considère que la demande ne peut pas être corrigée.
- Duplicate (Doublon)
- Une autre demande décrit déjà le même bug ou fonctionnalité.
- Expected Behavior
- Le fonctionnement observé est bien celui attendu.
- Need more info
- La demande manque d'informations et doit être complétée.
- Under Advisement
- La demande nécessite des discussions internes à Linden Lab en plus d'une correction.
- Cannot reproduce
- Le bug ne peut pas être reproduit. Complétez la description si des étapes supplémentaires sont nécessaires.
- Misfield
- Cette demande n’est pas traitable sur Jira
Comment aider ?
Identifier les doublons
Si vous remarquez une demande récente qui doublonne une autre demande bien documentée, vous pouvez la passer à l’état "Resolved" (Traitée) avec la résolution "Duplicate" (Doublon). Liez les deux demandes par le bouton "Link" (Lier) puis "This issue duplicates" (cette demande doublonne) et indiquez la clé de la demande principale. Cela permet ainsi d’identifier les bugs souvent signalés et de centraliser toutes les demandes au même endroit.
Identifier les problèmes de support
Cette partie est destinée aux personnes capables de différencier un problème de support d'un bug. La différence n’est pas toujours évidente mais vous êtes encouragés à traiter ce type de demandes. La responsabilité de prouver qu’il s’agit bien d’un bug affectant plusieurs résidents incombe au rapporteur de la demande.
Les bugs non reproductibles
Si vous n’êtes pas capable de reproduire le bug en faisant exactement la manipulation décrite et dans le même environnement, vous devez traiter la demande. Soyez prudents : vous devez avoir la même carte vidéo si la demande concerne un bug graphique. Il est préférable de laisser cette partie aux développeurs.
Reproduction des bugs
Si vous êtes capable de lister étape par étape la marche à suivre pour reproduire un bug, faites-le ! Suivez la description du rapporteur et ajoutez la liste des étapes pour générer le bug. Cela facilite le travail des développeurs en les aidant à se focaliser sur les bugs reproductibles.
FAQ
Consultez cette page pour trouver les réponses aux questions les plus fréquentes.
Rechercher sur JIRA
Consultez cette page pour plus d’information sur la recherche dans JIRA.
Autres sources d’informations
- Issue Tracker Forum Transcript : informations de Rob et Aric Linden sur l’utilisation de Jira et les opérations réalisés en arrière-plan.
- Le guide d'utilisation de JIRA par Atlassian, créateur de JIRA.
<videoflash>Jofq8ClPfNg</videoflash>