• Un ticket corresponde a una discusión individual sobre algo, que puede ser un defecto, una mejora, una información, una instalación, etc. Por eso es importante etiquetar de que se trata, así como su gravedad y el área a la que pertenece. Todos estos valores son configurables.

• Un ticket tiene un estado. New cuando se crea. Cuando alguien lo lee y cree que le corresponde a él llevar su desarrollo lo acepta. Cuando tras sucesivos comentarios que hayan dado lugar a acciones cree que se ha terminado el objeto del ticket lo cierra con un código de resolución: Fijado, inválido, duplicado, workaround, wontfix ...

• Los tickets posteriormente pueden reabrirse de nuevo. Cualquiera puede quitarle la asignación a otro asignándoselo él, o el dueño (el que lo aceptó) puede asignárselo a otro. También se puede poner en CC a otros (usando el login ldap) de forma que los cambios lleguen con una notificación de correo.

• Esto lo implementamos nosostros aquí y no es estándar de trac, es el estado "check". En este estado normalmente el dueño espera que el informador o alguien en CC le confirme algo que se debe probar antes de cerrar el ticket. Es como decir: "yo he hecho mi trabajo, ahora decidme que va bien para cerrarlo".

• Un milestone es un objetivo que puede tener fecha o no. Por ejemplo, "bacula 1.0" será el objetivo de que bácula sustituya a arcserve. Cuando lo haya hecho, crearemos un nuevo milestone con otro objetivo (aunque sea simplemente el de que siga funcionando bien). Todos los tickets de un milestone deben de haberse cerrado (o movido al nuevo milestone) antes de considerar completado el milestone.

• En la barra de progreso vereis los tickets que están cerrados, los abiertos, los de estado check y los porcentajes que representan así como la fecha de finalización del milestone.

• Cuando uno quiera poner un comentario en un ticket pone simplemente eso, un comentario. La apertura de un nuevo ticket hijo de otro se debe hacer si hay alguna tarea que realizar relacionada pero diferente de la actual, si el que tiene que aceptarla es diferente del que ha aceptado el ticket padre, etc. No os corteis al abrir tickets, aunque sea simplemente para anotar algo que se os ha pasado por la cabeza y que creeis que hay que mirar. Pero tampoco pasa nada porque un ticket termine con bastantes comentarios si el tema lo necesita.

• Por último en cualquier ticket podeis referiros a otro poniendo su numero precedido de #. Es una forma muy cómoda de facilitar la navegación cuando se trabaja con trac. Podeis adjuntar ficheros, capturas de pantalla, poner enlaces, formatear con wiki, etc. La busqueda es muy buena y queda todo bastante estructurado. Para temas dinámicos en pleno desarrollo es mejor que drupal.