Tickets, suivi de bugs

Tickets est un système simple de suivi de bugs directement intégré à l’espace privé de SPIP. Sa vocation est avant tout de faciliter la phase de développement du site public (squelettes, graphisme, etc.) sur lequel il est installé.

Lors de la phase de création d’un site, de nombreux messages sont échangés pour signaler par exemple :
— des bugs d’affichage du HTML (« c’est tout cassé sous MSIE 6... »),
— des problèmes d’ergonomie (« la couleur des liens hypertexte, ma grand-mère arrive pas à bien lire... »),
— des morceaux d’Ajax qui ne fonctionnent pas bien dans certaines situations,
— des fautes d’orthographe systématiques à corriger (« monsieur Coulemole, notre PDG... »),
— certaines fonctionnalités manquantes (« il faudrait terminer la newsletter... »),
— etc.

Messages vaguement stockés, que tout le monde n’a pas forcément reçu, avec un suivi à la va-comme-j’te-pousse qui fait qu’une fois c’est corrigé une fois c’est oublié...

C’est typiquement dans ce genre de situation que l’on a besoin d’un système de suivi de bugs :
— pouvoir signaler les problèmes et les transmettre à toutes les personnes concernées,
— pouvoir centraliser ces signalement pour pouvoir les traiter de manière systématique,
— pouvoir gérer leur « statut » pour savoir lesquels sont toujours valables et lesquels ont été résolus,
— permettre d’attribuer à certains intervenants les questions qui les concernent (ce qui équivaut à « je m’en occupe »),
— signaler qu’une question est très importante ou pas du tout...

Il existe d’excellents systèmes de suivi de bugs diffusés sous GPL (Mantis, Trac...).

Tickets propose d’insérer un système de suivi de bugs directement dans SPIP. En effet :
— c’est le plus souvent dans l’espace privé du site en développement que se retrouvent toutes les personnes concernées ; Tickets évite ainsi de devoir gérer un espace séparé (que la plupart des utilisateurs finissent par oublier d’utiliser), et de devoir gérer une autre liste d’autorisations de connexions ;
— ce plugin propose une interface aussi simplifiée que possible, car il est clairement conçu pour le développement du site public, et non d’un logiciel informatique de grande ampleur. Le nombre de champs à renseigner est donc restreint et basé sur des choix explicites (pas de jargon, vocabulaire adapté à des non-techniciens).

Évolutions
— 1.0 : on peut assigner le ticket à un rédacteur.
— 1.1 : envoi d’un mail avertissant les rédacteurs et les administrateurs lors du changement de statut d’un ticket.