TicketingPolicy » History » Version 11

Paweł Widera, 04/28/2014 05:45 PM
Formatting corrected.

1 9 Anonymous
h1. Ticketing Policy
2 1 Anonymous
3 9 Anonymous
This page describes how *Users* and *Developers* should use the ticketing system:
4 1 Anonymous
5 9 Anonymous
h2. General Definitions
6 1 Anonymous
7 1 Anonymous
h3.  Ticket Type
8 9 Anonymous
9 1 Anonymous
Describes the *nature* of a new ticket.
10 9 Anonymous
11 11 Paweł Widera
|| *Defect*      || Anything that does not work as expected ||
12 11 Paweł Widera
|| *Enhancement* || An improvement over an existing feature ||
13 11 Paweł Widera
|| *Feature*     || A new feature that should be added ||
14 11 Paweł Widera
|| *Task*        || Anything that does not fall into the categories above ||
15 1 Anonymous
16 9 Anonymous
h3. Priority
17 1 Anonymous
18 1 Anonymous
Describes the *importance* of a ticket and the *order* in which it should be dealt with.
19 9 Anonymous
20 11 Paweł Widera
|| *immediate* || Reduced functionality of parts of the system or the entire system until problem is fixed ||
21 11 Paweł Widera
|| *urgent*    || Security breach or severe loss of data due to the defect ||
22 11 Paweł Widera
|| *high*      || Defect with major impact *OR* big enhancement ||
23 11 Paweł Widera
|| *normal*    || Defect with normal impact *OR* medium enhancement ||
24 11 Paweł Widera
|| *low*       || Defect with minor impact *OR* small enhancement ||
25 1 Anonymous
26 9 Anonymous
h3. Versioning
27 1 Anonymous
28 9 Anonymous
Describes conventions for *naming* milestones and versions.
29 1 Anonymous
30 11 Paweł Widera
|| *Milestone* || Planned version (future)  ||
31 11 Paweł Widera
|| *Version*   || Released milestone (past) ||
32 9 Anonymous
33 1 Anonymous
*Milestones* are named according to the next *Version* number.
34 1 Anonymous
35 1 Anonymous
*Keywords* can be added to specify a special purpose of a *Milestone*/*Version*, e.g. "usability", "performance"
36 9 Anonymous
37 9 Anonymous
h2. Ticket Handling
38 9 Anonymous
39 9 Anonymous
h3. Opening new Tickets
40 1 Anonymous
41 11 Paweł Widera
Users only need to set the *Ticket Type* and the *Version* of the software to which the ticket applies. The *Priority* is optional and may be reassigned by one of the developers later.
42 9 Anonymous
43 9 Anonymous
Developers verify each ticket and, on acceptance, assign an *Owner*, *Priority*, *Component*, and *Milestone*. If more information than given in the original ticket description is needed, its status should remain as *new* until acceptance/refusal is possible.
44 9 Anonymous
45 1 Anonymous
46 9 Anonymous
h3. Referring to Tickets
47 9 Anonymous
48 10 Paweł Widera
Tickets can be referenced in the wiki using @#@:
49 9 Anonymous
50 10 Paweł Widera
<pre>
51 10 Paweł Widera
issue #1
52 10 Paweł Widera
</pre>
53 9 Anonymous
54 9 Anonymous
h3. Closing and Referencing Tickets
55 9 Anonymous
56 9 Anonymous
Tickets should not be closed by hand, but automatically when committing the code changes to the SVN repository, referring to the ticket numbers as follows:
57 1 Anonymous
58 11 Paweł Widera
|| close a ticket    || "close", "closes", "fix", "fixes" ||
59 11 Paweł Widera
|| refer to a ticket || "references", "refs", "addresses", "re", "see" ||
60 11 Paweł Widera
|| list-of-tickets   || separator is one of: @, & and@, eg. !#1 and !#2 ||
61 9 Anonymous
62 9 Anonymous
*Example:*
63 5 Anonymous
64 9 Anonymous
The following example will close tickets !#10 and !#12, and add a note to ticket !#12.
65 9 Anonymous
66 5 Anonymous
<pre>
67 10 Paweł Widera
close #10 and #12, references #12
68 10 Paweł Widera
</pre>