TicketingPolicy » History » Version 4

« Previous - Version 4/11 (diff) - Next » - Current version
Anonymous, 07/04/2007 02:43 PM


= Ticketing Policy =

This page describes how '''Users''' and '''Developers''' should use the ticketing system:

General Definitions

=== Ticket Type ===
Describes the nature of a new ticket.

'''Defect''': Anything that does not work as expected
'''Enhancement''': An improvement over an existing feature
'''Request''': A new feature that should be added
'''Task''': Anything that does not fall into the categories above

=== Priority ===
Describes the order in which the ticket should be dealt with.

'''blocker''': Reduced functionality of parts of the system or the entire system until problem is fixed
'''critical''': Security breach or severe loss of data due to the defect
'''major''': Defect with major impact '''OR''' big enhancement
'''normal''': Defect with normal impact '''OR''' medium enhancement
'''minor''': Defect with minor impact '''OR''' small enhancement
'''trivial''': Defect with little or no impact '''OR''' cosmetic enhancement

=== Versioning ===
Describes the difference between milestones and versions.

'''Milestone''' Planned version (future)
'''Version''' Released milestone (past)
Ticket Handling

=== Opening new Tickets ===
Users need only to set the '''Ticket Type''' and the '''Version''' of software to which the ticket applies. The '''Priority''' is optional and may be reassigned by one developers later. BR

Developers verify each ticket and, on acceptance, assign an '''Owner''', '''Priority''', '''Component''', and '''Milestone'''. If more informationthan given in the original ticket description is needed, its status should remain '''new''' until acceptance/refusal is possible.

=== Closing Tickets ===
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:BR

{{{COMMAND list-of-tickets}}}

{{{COMMAND}}} close closed closes fix fixed fixes
list-of-tickets ticket:2, ...
!ticket:1 & !ticket:2 & ...
!ticket:1 and !ticket:2 and ...
Alternatives bug:1, #1