Outil de suivi des anomalies

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Update Needed

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:

Les contributions

Toutes les contributions à JIRA sont soumises au Contribution Agreement de Second Life. En y ajoutant des corrections ou des modifications, vous reconnaissez avoir pris connaissance, compris et approuvé les termes.

Utilisation

JIRA n'est pas destiné aux demandes de support.
S'il vous plait n'ajoutez pas de demandes qui exigent une réponse personnalisée. Pour une assistance spécifique à votre compte, utilisez plutôt notre support.

Exemples à traiter avec le support et non dans JIRA :

"Je veux modifier mon abonnement"
"Une partie de mon inventaire a disparu"
"Quelqu'un a volé mes L$"

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é

<videoflash>Jofq8ClPfNg</videoflash>

Règles de base

Indiquez toujours les étapes à suivre pour reproduire le bug et numérotez-les ! Nous pouvons étudier un bug uniquement si nous sommes capables de le reproduire. Plus il se reproduit facilement, plus vite il peut être corrigé. Par exemple, au lieu de dire "Je crash quand j'importe des fichiers", la description doit être :

Je clique sur Fichier > Charger une image (10L$)...

Je choisis un fichier .TXT au lieu d'un fichier .JPG

Je clique sur Ouvrir

RÉSULTAT : mon ordinateur crash et aucune fenêtre d'incident n'apparaît.

Envoyez cette description à un ami. Si votre ami arrive à suivre les étapes, il y a de fortes chances que nous le puissions aussi !

N’hésitez pas à ajouter des images, des vidéos, des rapports d'incident ou tout autre fichier lié à votre problème (dans la limite de 10 Mo chacun). Dans l’exemple précédent, il serait utile de joindre le fichier que vous avez essayé d’importer.

Ne décrivez qu’un seul problème par demande. Chaque bug a besoin de sa propre demande pour être suivi individuellement.

Recherchez votre problème dans les demandes existantes avant d’en créer une afin d’éviter les doublons.

Évitez d’utiliser les noms de résidents ou de donner des renseignements personnels. Si le problème n'affecte que votre avatar ou une région, commencez par contacter le support technique.

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 êtes un développeur et que vous joignez une patch, 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 à celui du signalement d’un bug avec les variantes suivantes:

Choisissez "New Feature" au lieu de "Bug" dans la zone type d'issue.
Au lieu de décrire la méthode de reproduction d’un bug, 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 également consulter notre blog pour en savoir plus sur les travaux en cours.

Signaler une faille de sécurité

Les failles de sécurité doivent être signalées directement à l’équipe de sécurité. (Les failles de sécurité sont des bugs permettant d’abuser des autres résidents, d’avoir des accès non autorisés aux scripts, de modifier/copier/transférer les objets des autres (les bugs de pouvoirs) et des bugs susceptibles de compromettre la grille ou la vie privées des résidents.
Pour plus de réactivité, vous pouvez envoyer directement le descriptif de la faille à security@lindenlab.com. Lisez cet article pour plus d'infos.

Restez poli

Note: Les CS de Second Life s'appliquent à tous les domaines de Second Life, y compris le JIRA. N'importe quel résident ne respectant pas ces directives peut se voir interdire l'utilisation du JIRA.

Exemples de conduites ou d'actions pouvant entraîner un bannissement du JIRA :

En utilisant le JIRA pour faire de la publicité ou promouvoir une cause, un blog, un site Internet ou tout sujet non lié au problème.
La provocation : par l’utilisation de message destiné à inciter la haine ou la colère ou en attaquant directement un autre résident. Ce type de comportement n’est pas adapté au JIRA. Tout message contrevenant à cette règle sera effacé.
Les discussions privées - Poster vos opinions personnelles ou des déclamations hors sujet est interdit. L’objectif du Jira est de trouver des solutions aux problèmes techniques. Nous apprécions les commentaires productifs. Restez dans le sujet. Les messages ne respectant par cette règle seront supprimés.
Guerre des éditions - Les modifications répétées relatives à la résolution, la priorité ou la classification d’une anomalie sont interdites. En cas de désaccord avec un autre résident, utilisez la partie commentaire de la fiche pour discuter de ces éléments.

Voter

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. Le JIRA utilise le le scrutin d'approbation, vous pouvez voter pour autant de fiches que vous voulez, mais vous êtes limité à un vote par fiche.

Les votes sont utilisés dans le processus de priorisation. La faisabilité et la durée du développement de la nouvelle fonctionnalité ou de la correction de l’anomalie entrent également en ligne de compte. Une fiche ayant reçu beaucoup de votes ne sera pas forcément résolue avant une fiche en ayant moins mais dont la correction est plus facile.

surveiller le l’état de votre fiche

Linden Lab étudie régulièrement les fiches crées sur jira.secondlife.com. L'équipe en charge de la correction est susceptible de vous demander des informations supplémentaires ou la participation de d’autres contributeurs. Revenez régulièrement sur votre fiche pour voir si cette dernière a reçu des commentaires ou des questions de Linden Lab.

Les états possibles

Voici comment le Linden Lab utilise les états de fiches :

Open

C'est une fiche assigné à un responsable. Ce dernier peut corriger l’anomalie ou la renvoyer à son émetteur en la marquant « Resolved » (voir ci dessous)

In progress

Un développeur signale qu'il travaille à la correction de l’anomalie.

Reopened

Comme l’état "Open", sauf que la fiche a été fermée puis rouverte pour signaler que le problème était toujours présent.

Resolved

C'est une état renvoyant implicitement la fiche à son émetteur. La fiche n’est pas fermée mais plutôt dans une zone de transition don l’issue dépend de sa résolution. C'est à l’émetteur de décider s'il faut rouvrir ou fermer la fiche.

Fixed: signifie que le bug est corrigé dans la version officielle de Second Life.
Fix Pending: signifie que le bug est corrigé dans une version du client prochainement disponible.

Contact Support: L'anomalie signalée doit être traitée en passant par le support. Le résident foit remplir un ticket.
Won't Finish: Signifie que le responsable de la fiche considère que la fiche ne peut et ne sera jamais corrigée.
Duplicate: Signifie qu’une autre fiche décrit déjà le même problème/fonctionnalité.
Expected Behavior: L'anomalie n'en est pas une, le fonctionnement observé est bien celui attendu.
Need more info: cette fiche manque d'informations. Vous devez la compléter si vous souhaitez que l’anomalie puisse être corrigée.
Under Advisement: L'anomalie nécessite des discussions internes à Linden Lab en plus d'une correction. Cet état permet de signaler à la communauté que la fiche a été vue et est en cours de discussion.
Cannot reproduce: L’anomalie ne peut pas être reproduite. Peut être une paramétrage ou des actions supplémentaires sont-elles requises pour reproduire l’anomalie. Complétez votre description du problème si vous souhaitez que l’anomalie puisse être corrigée. Les fiches qui ne peuvent être reproduites seront à terme fermées.
Misfield: Cette fiche n’est pas traitable dans le jira

Closed: La fiche est close.

FAQ

Consultez cette page pour trouver les réponses aux questions les plus classiques !

La recherche

Consultez cette page pour davantage d’information !

Comment aider?

vous avez bien fait de demander

Identifier les doubles

Si vous remarquez une fiche récente qui doublonne une fiche existante déjà bien documentés vous pouvez la passer à l’état "Resolved" et "Duplicate". Choisissez également "Link" et inscrivez le texte "This issue duplicates " (cette fiche doublonne la n°) et indiquez le numéro de la fiche principale. Cela permet de garder une trace de la dépendance des fiches entre eux et d’identifier les bugs les plus souvent signalés. Cela permet ainsi d’attirer l’attention sur les bugs souvent signalés et de centraliser toutes les fiches au même endroit pour s’assurer qu’il s’agit bien d’un doublon

Problème de support

Cette partie est destinée aux experts techniques capables de différencier un problème de support et un bug – la différence n’est pas toujours évidente. Vous êtes encouragé à « résoudre » ce type de fiches. Une fois une telle fiche « résolue », la responsabilité de montrer qu’il s’agit bien d’un bug affectant plusieurs résidents incombe à l’émetteur de la fiche.

Les anomalies non reproductibles

Si en faisant exactement la manipulation décrite, dans le même environnement, vous n’êtes pas capable de reproduire le bug, vous devriez « résoudre » le fiche. Soyez prudents, en cas de problème de rendu graphique, vous devez avoir la même carte vidéo. Il est préférable de laisser cette partie aux experts techniques.

Reproduction des bugs

Ce point est très important! Si vous êtes en mesure de lister étapes par étapes la marche à suivre pour reproduire le bug, faites le ! De telle description facilite le travail de Linden Lab en les aidant à se focaliser sur les bugs reproductibles. À moins un qu’un bug puisse être reproduit, il est impossible de vérifier sa correction ou non. Suivez la description de l’émetteur de la fiche et rédigez une liste des étapes à suivre pour générer le bug, ajoutez cette liste à la fiche en signalant que le bug a pu être reproduit. Les anomalies le plus largement documentées ont une plus haute priorité de correction et facilite le travail de l’équipe de tri des bugs.

Autres sources d’informations

Vous voulez en apprendre plus sur notre Traqueur d'issues?

Issue Tracker Forum Transcript - les Informations de Rob et Aric Linden sur les raisons de l’utilisation du Jira, les opérations réalisés en arriere plan et les réponses à différentes questions relatives au Jira.
Le guide d'utilisation du JIRA par Atlassian, créateur du JIRA.