How to write a ticket » History » Version 10
Niels Hoffmann, 12/22/2009 03:47 PM
1 | 1 | Niels Hoffmann | |
---|---|---|---|
2 | # How to write a ticket |
||
3 | |||
4 | |||
5 | 5 | Niels Hoffmann | This document describes best practices when creating a new or contributing to an existing ticket. In an ideal world a developer not familiar with the problem described in the ticket has all information at hand to be able to work on the problem. All information you gather while working on a ticket should be added to the ticket as well. This also includes email discussions (copy/paste them into the ticket) which would not be accesible by other developers otherwise. Always remember: _The ticket system is a tool that should help developers to carry out their work_ |
6 | 1 | Niels Hoffmann | |
7 | |||
8 | |||
9 | 5 | Niels Hoffmann | ## The Ticket Form |
10 | 4 | Niels Hoffmann | |
11 | |||
12 | |||
13 | ### Short summary |
||
14 | |||
15 | 1 | Niels Hoffmann | *Be as explanatory as you can in the summary*. It really saves time when browsing through ticket lists. Ideally your ticket has a short summary that describes the problem and no further explanation is needed in the Full description field. |
16 | 2 | Niels Hoffmann | |
17 | 1 | Niels Hoffmann | |
18 | |||
19 | 4 | Niels Hoffmann | ### Type |
20 | 2 | Niels Hoffmann | |
21 | 7 | Niels Hoffmann | Use the types wisely according to the following recomendations |
22 | 1 | Niels Hoffmann | |
23 | 2 | Niels Hoffmann | |
24 | 4 | Niels Hoffmann | #### Bug |
25 | 3 | Niels Hoffmann | |
26 | 1 | Niels Hoffmann | Bugs are severe problems and misbehaviourisms of the software. If something goes obviously wrong in the software or is not working as expected, that is considered a bug. Bugs by nature will always have highest priority. |
27 | 3 | Niels Hoffmann | |
28 | |||
29 | 2 | Niels Hoffmann | |
30 | 4 | Niels Hoffmann | #### Task |
31 | 1 | Niels Hoffmann | |
32 | 8 | Niels Hoffmann | A task is something that was decided, has to be done or has to be implemented but is not critical to the correct workings of the software. |
33 | 3 | Niels Hoffmann | |
34 | |||
35 | 2 | Niels Hoffmann | |
36 | 4 | Niels Hoffmann | #### Feature Request |
37 | 1 | Niels Hoffmann | |
38 | 3 | Niels Hoffmann | Anything that users would like to be implemented in the future goes into the feature request category. Things considered as nice-to-have go in this category as well. Once a feature request is agreed on it will be moved to the tasks and therefore be queued for implementation. |
39 | 2 | Niels Hoffmann | |
40 | 1 | Niels Hoffmann | |
41 | 3 | Niels Hoffmann | |
42 | |||
43 | 4 | Niels Hoffmann | ### Full description |
44 | 1 | Niels Hoffmann | |
45 | 2 | Niels Hoffmann | Any information that could not go in the short summary or additional information goes into this field. This includes: |
46 | 1 | Niels Hoffmann | |
47 | 2 | Niels Hoffmann | * In case of a bug, instructions to reproduce it |
48 | 1 | Niels Hoffmann | |
49 | 2 | Niels Hoffmann | * Links that hold information connected to the ticket |
50 | |||
51 | * Stack traces |
||
52 | |||
53 | 9 | Niels Hoffmann | * Any information useful to somebody working on the ticket |
54 | 2 | Niels Hoffmann | |
55 | |||
56 | 1 | Niels Hoffmann | |
57 | 4 | Niels Hoffmann | ### Ticket Properties |
58 | 1 | Niels Hoffmann | |
59 | |||
60 | |||
61 | 4 | Niels Hoffmann | #### Priority |
62 | 1 | Niels Hoffmann | |
63 | 10 | Niels Hoffmann | The priority indicates which tickets are more severe and should be worked on first. 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. When prioritizing a ticket that was created by a non-developer keep in mind to honour the severity. |
64 | 2 | Niels Hoffmann | |
65 | 1 | Niels Hoffmann | |
66 | |||
67 | 4 | Niels Hoffmann | #### Component |
68 | 1 | Niels Hoffmann | |
69 | 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. |
||
70 | 2 | Niels Hoffmann | |
71 | |||
72 | 1 | Niels Hoffmann | |
73 | 4 | Niels Hoffmann | #### Cc |
74 | 3 | Niels Hoffmann | |
75 | 1 | Niels Hoffmann | Add user names here you think that might be interested in the process of working on the ticket. |
76 | 2 | Niels Hoffmann | |
77 | 3 | Niels Hoffmann | |
78 | 1 | Niels Hoffmann | |
79 | 4 | Niels Hoffmann | #### Milestone |
80 | 2 | Niels Hoffmann | |
81 | 3 | Niels Hoffmann | EDIT deliverables as well as internal Sprints are represented as milestones. Simply choose a milestone that fits your ticket or leave blank if unsure. Note: *Think twice before adding a ticket to a running sprint*. It lies in the nature of Sprints that no new tasks are added when they are actively worked on. |
82 | 2 | Niels Hoffmann | |
83 | |||
84 | 3 | Niels Hoffmann | |
85 | 4 | Niels Hoffmann | #### Severity |
86 | 2 | Niels Hoffmann | |
87 | 10 | Niels Hoffmann | This field is to be used by external, non developers to give them the opportunity to rank the problem. This has nothing to do with how the ticket will be ranked by the developers through priorities. |
88 | 2 | Niels Hoffmann | |
89 | |||
90 | |||
91 | 4 | Niels Hoffmann | #### Assign To |
92 | 2 | Niels Hoffmann | |
93 | 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. |
||
94 | |||
95 | |||
96 | |||
97 | 3 | Niels Hoffmann | The fields "Keywords", "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. |