How to write a ticket » History » Revision 2
« Previous |
Revision 2/16
(diff)
| Next »
Niels Hoffmann, 12/22/2009 03:20 PM
How to write a ticket¶
Short summary¶
Be as explanatory as you can in the summary. Ideally your ticket has a short summary that describes the problem and no further explanation is needed in the Full description field. This is not possible of course for all kinds of problems. . T really saves time when browsing through ticket lists
Type¶
Use the types wisely according to the following descriptions
Bug¶
Task¶
Feature Request¶
Full description¶
Any information that could not go in the short summary or additional information goes into this field. This includes:
In case of a bug, instructions to reproduce it
Links that hold information connected to the ticket
Stack traces
s.o.
In an ideal world a developer not familiar with the problem described in the ticket at all has all needed information at hand and is able to work on the problem immediately.
Ticket Properties¶
Priority¶
The priority indicates which tickets are more severe and should be worked on first. However this is not a totally strict system and you don't have to work on your tickets from top to bottom. If something with lower priority can be fixed easily, go for it.
Component¶
Define the component the ticket belongs to. This is quite important because developers might perform searches based on components (e.g. show all tickets with component cdmlib), but is also forgotten very often.
Keywords¶
Cc¶
Milestone¶
Severity¶
This field is to be used by external, non developers to give them the opportunity to rank the problem as they see fit. Note: This has nothing to do with what the pro
Assign To¶
If you think you know who is responsible for working on the ticket you just created fill in a user name here. If this field is left blank, the ticket gets assigned to the person in charge of the component you selected earlier.
The fields "Dependencies", "Include in GanttChart", "Due to assign", "Due to close" are not really used by the development team at the moment. This might change in the future and their recommended use will be described here.
Updated by Niels Hoffmann over 14 years ago · 2 revisions