Tickets est un sys­tème sim­ple de suivi de bugs direc­te­ment inté­gré à l’espace privé de SPIP. Sa voca­tion est avant tout de faci­li­ter la phase de déve­lop­pe­ment du site public (sque­let­tes, gra­phisme, etc.) sur lequel il est ins­tallé.

Lors de la phase de créa­tion d’un site, de nom­breux mes­sa­ges sont échangés pour signa­ler par exem­ple :
— des bugs d’affi­chage du HTML (« c’est tout cassé sous MSIE 6... »),
— des pro­blè­mes d’ergo­no­mie (« la cou­leur des liens hyper­texte, ma grand-mère arrive pas à bien lire... »),
— des mor­ceaux d’Ajax qui ne fonc­tion­nent pas bien dans cer­tai­nes situa­tions,
— des fau­tes d’ortho­gra­phe sys­té­ma­ti­ques à cor­ri­ger (« mon­sieur Coulemole, notre PDG... »),
— cer­tai­nes fonc­tion­na­li­tés man­quan­tes (« il fau­drait ter­mi­ner la news­let­ter... »),
— etc.

Messages vague­ment sto­ckés, que tout le monde n’a pas for­cé­ment reçu, avec un suivi à la va-comme-j’te-pousse qui fait qu’une fois c’est cor­rigé une fois c’est oublié...

C’est typi­que­ment dans ce genre de situa­tion que l’on a besoin d’un sys­tème de suivi de bugs :
— pou­voir signa­ler les pro­blè­mes et les trans­met­tre à tou­tes les per­son­nes concer­nées,
— pou­voir cen­tra­li­ser ces signa­le­ment pour pou­voir les trai­ter de manière sys­té­ma­ti­que,
— pou­voir gérer leur « sta­tut » pour savoir les­quels sont tou­jours vala­bles et les­quels ont été réso­lus,
— per­met­tre d’attri­buer à cer­tains inter­ve­nants les ques­tions qui les concer­nent (ce qui équivaut à « je m’en occupe »),
— signa­ler qu’une ques­tion est très impor­tante ou pas du tout...

Il existe d’excel­lents sys­tè­mes de suivi de bugs dif­fu­sés sous GPL (Mantis, Trac...).

Tickets pro­pose d’insé­rer un sys­tème de suivi de bugs direc­te­ment dans SPIP. En effet :
— c’est le plus sou­vent dans l’espace privé du site en déve­lop­pe­ment que se retrou­vent tou­tes les per­son­nes concer­nées ; Tickets évite ainsi de devoir gérer un espace séparé (que la plu­part des uti­li­sa­teurs finis­sent par oublier d’uti­li­ser), et de devoir gérer une autre liste d’auto­ri­sa­tions de connexions ;
— ce plu­gin pro­pose une inter­face aussi sim­pli­fiée que pos­si­ble, car il est clai­re­ment conçu pour le déve­lop­pe­ment du site public, et non d’un logi­ciel infor­ma­ti­que de grande ampleur. Le nom­bre de champs à ren­sei­gner est donc res­treint et basé sur des choix expli­ci­tes (pas de jar­gon, voca­bu­laire adapté à des non-tech­ni­ciens).

Évolutions
— 1.0 : on peut assi­gner le ticket à un rédac­teur.
— 1.1 : envoi d’un mail aver­tis­sant les rédac­teurs et les admi­nis­tra­teurs lors du chan­ge­ment de sta­tut d’un ticket.