This article shall describe the ticket system and the corresponding workflow. Further down, you'll find the template for the ticket's descriptions during the workflow.
Why do we use a ticket system? It should be enough to document all changes in the changes log and force the users to report bugs and requests via email. But there are a bunch of reasons, why a ticket system supports the development of complex software better than emails:
|
V
[open] -------------------------------\
| |
V |
[accepted] -------+-------------------> |
| | |
| V |
| <----- [postponed] |
V |
[analyzing] -------+--------+----------> |
| | | |
| V | |
| <----- [postponed] | |
| V |
| <----------- [to-be-clarified] |
V |
[implementing] <-----\ |
| | |
V | |
[testing] ---------/ |
| |
V V
[fixed/closed] [rejected]
Use the following template for the description of the tickets. Insert the template below the description just when the ticket enters the status analyzing.
###Analysis:
(*Describe, what's the issue and which changes have to be made*)
###Implementation:
* Implementation: (*Describe, what you've changed*)
* Revision: [rXXX]
* Implementation test: (*Describe the type of test, which you performed, and if it was successful*)
###Documentation:
* [ ] ChangesLog updated
* [ ] Code changes commented
* **Documentation articles:**
* [ ] corresponding documentation articles updated
* [ ] new documentation articles created
* [ ] not needed
* **Language files:**
* [ ] corresponding language files updated
* [ ] not needed
###Tests:
(*Describe, which tests you performed and their outcome*)
This will produce the following output:
(THE DESCRIPTION IS HERE)
(Describe, what's the issue and which changes have to be made)
(Describe, which tests you performed and their outcome)
Use [ ] to create the checkboxes in the list and [x] to check them: