wiki:UtilisationTickets

Guide d'utilisation des Tickets

Les différentes demandes d'amélioration et de correction pour le projet Ancestris sont faites à l'aide de tickets gérés sur ce site. Cette page a pour but de définir les la manière dont ces demandes peuvent être faites par les utilisateurs ainsi que la façon dont ces tickets sont gérés par l'équipe de développement.

TODO mettre quelques rapports ici (par exemple tous les tickets actifs)

Pour les utilisateurs

Tout d'abord en tant que visiteur non authentifié, vous ne pouvez que visualiser les tickets existants. Si vous souhaitez participer en créant ou complétant des tickets, il suffit d'envoyer un courriel à François pour demander un accès au site.

Principales informations d'un ticket

Les tickets comportent un certain nombre de champs qui doivent être renseignés avec le plus de précision possible pour qu'ils soient pris en compte dans les meilleures conditions. Le but de ce guide est de donner quelques conseils pour la rédaction de ces informations. Les champs sont les suivants :

Summary
Fournir ici une description la plus précise et concise possible afin de savoir tout de suite de quoi il retourne. Cette information sera utilisée dans toutes les pages donnant un aperçu synthétique de l'évolution du projet.
Type
La nature même du ticket (défaut, amélioration, tâche)
Description
Description complète avec l'ensemble des informations nécessaires à sa prise en compte
Component
Le module ou la partie concerné par le ticket
Version
La version utilisée
Keywords
Mots clés
Severity
Impact du ticket sur le projet.
Priority
L'importance ou la priorité de ce ticket accordée par le développeur ou l'équipe de développement. Ne pas confondre avec la sévérité! Les valeurs possibles vont de Très basse à Très haute. Note: ce champ est positionné par l'équipe de développement.
Milestone
Etape, échéance pour ce Ticket. Note: ce champ est positionné par l'équipe de développement.
Cc
autre(s) utilisateur(s) intéressés par le déroulement de ce ticket
Assign to
Développeur en charge du ticket. Note: ce champ est positionné par l'équipe de développement.

Type

Le type du ticket peut être :

défaut
pour un défaut de fonctionnement constaté,
amélioration
pour une demande d'amélioration ou un ajout de fonction.
tâche
toute autre action ne rentrant pas dans l'une des deux catégories précédentes et ne nécessitant pas de modification dans le code de Ancestris ni dans sa documentation

Description

La description du ticket est la partie la plus importante. Elle doit contenir toutes les informations utiles pour que le développeur puisse comprendre et éventuellement reproduire le problème. Ces informations sont essentielles pour que la demande soit traitée efficacement.

Dans le cas d'un défaut de fonctionnement, il est utile de préciser:

  • La démarche complète afin de reproduire le problème. N'hésitez pas à joindre un fichier si cela est nécessaire mais attention! ce fichier est lisible par tout le monde donc pas d'information confidentielle.
  • Les informations sur le système utilisé:
    • Type de machine
    • Système d'exploitation
    • Version de java
  • ...

Component

Il s'agit du module concerné par le ticket (rapport, aide, ...).

Version

Non utilisé pour le moment, à renseigner dans la description du ticket

Keywords

Permet de trier les tickets. Note: ce champ est positionné par l'équipe de développement.

Le rôle des mots clé est de fournir aux tickets une information permettant ensuite de les retrouver simplement à l'aide de requêtes spécifiques. Pour le moment les mots clé autorisés sont:

  • needinfo - En attente d'informations de la part de l'utilisateur
  • verify - Le ticket semble être valide mais l'équipe de développement n'a pas été en mesure de vérifier (système différent, version de java, ...). Dans ce cas un aide est sollicité de la part d'une bonne volonté pour reproduire le problème.
  • tobedeleted - tickets qui doivent être supprimés (principalement des tickets qui n'ont rien à voir avec le projet).
  • helpwanted - On demande un développeur pour ce ticket :-)

Sévérités

Bloquant
Point bloquant. Sans la résolution de ce ticket, le projet ne peut plus avancer. Il n'est utilisé que dans des situations exceptionnelles et uniquement pour des défauts de fonctionnement .
Critique
Dysfonctionnement sérieux, arrêt brutal de l'application ou du module pouvant conduire à des pertes de données, un blocage de l'application ou du système. Ne peut également être utilisé que pour des tickets de type défaut.
Majeur
Perte de fonctionnalité importante sans alternative simple. Ceci concerne tant les défauts que les demandes d'amélioration. Le défaut ne conduit pas à une perte de données (mettre Critique dans ce cas).
Normal
La majorité des défauts ou demande d'ajout.
Mineur
Problème ou besoin mineur. Ou alors une alternative simple existe sans pour autant annuler l'intérêt de la demande.

Guide pour les développeurs

Priority

L'importance ou la priorité de ce ticket accordée par le développeur ou l'équipe de développement. Ne pas confondre avec la sévérité! Les valeurs possibles vont de Très basse à Très haute. Les critères d'attribution d'une priorité peuvent être discutés au sein de l'équipe de développement mais la signification sera toujours de donner plus d'importance dans les développements aux tickets dont la priorité est la plus haute. Cela ne veut pas forcément dire que ce ticket sera résolu avant les autres de priorité moindre car d'autres critères peuvent rentrer en ligne de compte.
Par exemple, on pourra utiliser les critères suivants:

  • Très Haute: Contribue directement à notre ambition, très demandé, pas d'alternative
  • Haute: Contribue directement à notre ambition, très demandé et une alternative existe
  • Normale: Contribue directement à notre ambition, pas très demandé et pas d'alternative
  • Basse:Contribue directement à notre ambition, pas très demandé et une alternative existe
  • Très Basse: Ne contribue pas directement à notre ambition

Status (État)

new
nouveau ticket en attente d'acceptation.
accepted
ticket accepté. C'est la seconde étape dans la vie d'un ticket. Cela signifie que le problème a pu être reproduit ou que la fonction mérite que l'on s'y attarde. En d'autres termes, le ticket est jugé valide par l'équipe Ancestris.
assigned
ticket assigné à un développeur... une solution va bientôt être trouvée ;-)
closed
le problème ou l'amélioration est résolu. Voir ci-dessous les différents cas de fermeture possibles
reopenned
un ticket fermé peut être ré-ouvert si le problème persiste. Attentionbien réfléchir avant de ré-ouvrir un ticket...

Resolution (Résolution)

fixed
le ticket est fermé car la correction ou l'amélioration a été apportée au code. Ou bien, dans le cas d'une tâche, celle-ci est réalisée.
worksforme
faux problème ou l'amélioration demandée existe déjà.
wontfix
le problème n'est pas directement lié à Ancestris ou bien la fonction demandée ne sera pas réalisée car l'équipe de développement ne considère pas que celle-ci fasse partie des objectifs du projet
invalid
le ticket créé ne concerne pas le projet
duplicate
il existe déjà un ticket sur le même problème.
  • Lorsque l'on ferme un ticket en doublon, il faut l'indiquer dans les deux tickets. Par exemple:
    • dans le doublon: Ce ticket est un doublon de #1234
    • dans le ticket d'origine: Le ticket #4567 a été marqué comme doublon de ce ticket
  • Il faut toujours laissé le ticket contenant le plus d'informations pertinentes ouvert.

Description

Une description d'un ticket ne peut être modifiée que par l'équipe de développement dans des cas très ponctuels. A chaque fois que cette description est modifiée, le texte original doit être gardé et les compléments d'informations clairement identifiés. Cela peut être:

  • correction d'erreurs de formatage sans toucher au contenu initial
  • information sur l'état d'avancement d'un développement qui peut être long
  • toute note jugée important et utile afin qu'elle ne soit pas noyée dans les fils de discussion

Milestone (Jalons)

Les jalons correspondent plus ou moins aux différentes versions prévues pour le projet. Les règles ci-dessous doivent s'appliquer:

  • Si la résolution est fixed, le jalon doit être positionné en accord avec le plan de développement (Roadmap)
  • Si la résolution est wontfix, invalid ou worksforme le jalon doit être laissé à blanc.
  • Dans le cas d'une amélioration ou d'un ajout de fonction, ne pas mettre comme jalon une version qui correspond uniquement à des corrections de dysfonctionnements.
  • Si la fonction demandée est une vision a relativement long terme, utiliser 99.0
  • Si le ticket semble pouvoir être corrigé dans un temps raisonnable mais ne fait pas partie du plan de développement, on utilisera alors le jalon correspondant à la version majeure suivant celle en curs de développement. À la date de rédaction de cette notice (septembre 2009) la version en cours de développement étant la version 1.0, on utilisera la version 2.0
  • Lorsqu'aucun jalon ne correspond mais que le ticket est tout de même valide, utiliser En attente.
Last modified 4 years ago Last modified on Aug 29, 2013, 9:42:21 PM