Wiki Diff WhatAreTickets, revision #4 to tip
This subsystem is a way to lodge a formal request for service that is tracked and accountable.
The term //Ticket// comes from manual systems in which a customer/client comes up to a service counter and receives a numbered 'ticket'. That //ticket// is then used as an identifier to group together all documentation and other interactions between the customer and service organization, and between different people within the organization.
In our case, the term used to record a request for one of a number of specific services:
# Bug Fixes
# Feature Requests
# Assistance Requests
=== Using Tickets ===
For the most part the ticket system is self explanatory. However, there are some aspects such as Severity, Status and even Assigned To that requires a little bit of explanation.
==== Type ====
There are three ticket types:
||Name || Description ||
| Bug Report | A bug has been found and here are the details |
| Feature Request | Not a bug but an enhancement... "It would be nice if..." |
| Task | Not a bug or a Feature Request, it's just something that has to be done |
An example of a Task is with the release of each version of Euphoria, someone has to build the Windows Installer, the Debian Package, the FreeBSD binaries, the OS X package, etc... Those are all tasks.
==== Status ====
The life of the ticket is defined by its status. When first created its status is "New." From there it can go thru any number of paths. Before some examples, here are a list of the statuses and their meaning:
||Name || Meaning ||
| New | Brand new, no determination of its validity |
| Is Valid? | Validity is under question |
| Accepted | Is valid and is accepted as such |
| Blocked | Is valid but another ticket must be completed first before this one can be worked on |
| On Hold | Is valid but on hold for an undetermined length of time for reasons stated in the comments section |
| Fixed, Please Confirm | Is fixed but the developer doing the work wants someone to confirm it's fixed, preferably the person who submitted the ticket |
| Fixed | Is fixed and closed, no longer active |
| Invalid | Was found to not be valid and is closed, no longer active. Reasons are to be stated in the comments section |
| Duplicate | A previous ticket exists that is for the same task |
| Won't Fix | Feature or "fix" that has not been accepted for reasons stated in the comments section |
===== Examples =====
Ticket: "'Common' misspelled as 'Commn' on page XYZ" Work flow: New -> Accepted -> Fixed. There is no Fixed, Please Confirm as it was an easy confirmation for anyone.
Ticket: "gets() erases my desktop folder" Work flow: New -> Is Valid? - Invalid. It just so happens the user called gets() right after they bumped the Delete key while all Icons were selected. They assumed it was the gets() function.
Ticket: "driveid() returns an invalid letter for my W: drive" Work flow: New -> Accepted -> Fixed, Please Confirm -> Fixed. Developer could not accurately test the fix applied so requested the user confirm the fix. When the user confirmed the fix they moved it from "Fixed, Please Confirm" to "Fixed" and added a comment.
==== Severity ====
This is a field that is often abused. People believe that if it has a higher severity level then it will be worked on and fixed sooner. This is not at all the case. Developers can gauge severity pretty well and will often times alter the severity upon acceptance of a ticket. Using a higher than realistic severity just upsets people. Choose accurately. If severe, make it so, if it's not a big deal, make it so. Be honest.
||Name || Description ||
| Textual | Text error, not breaking anything but should be fixed. For example, a spelling mistake. |
| Minor | Not a big problem, I can easily work around it and it does not have widespread impact |
| Normal | I can work around it but it needs to be fixed soon, it might have widespread impact |
| Major | I can work around it but I have to rewrite 1/2 my program. Almost everyone is going to have to do the same thing as well |
| Blocking | I cannot work around it, my project is on hold until this is fixed |
It should be noted that blocking has nothing to do with an assigned Milestone. It could be thought that a status of "Blocking" means that a Milestone cannot be released until the given ticket is fixed. This is not the case. If a ticket is assigned to a Milestone then that ticket **must** be fixed **regardless** of its severity before the milestone can be completed. If it comes down to the date the milestone is to be released and there are still a few tickets, the team can decided to postpone the milestone or move the remaining tickets to the next milestone. Severity has nothing to do with milestone but everything to do with how badly the ticket affects the reporter's project.
==== Assigned To ====
This lists possible developers that will be working on the ticket. The only thing worth mentioning here is that the ticket can be placed into the "Accepted" status without a developer being assigned. One developer may look at a bug and make the determination that it is indeed valid but not be comfortable in fixing the bug. Thus, to save others the analysis time, they mark it as "Accepted" and leave the "Assigned To" blank. Other developers can decide if they can fix the bug and if so they can then choose their name as the "Assigned To" developer.
=Ticket Subsystem=
This subsystem is a way to lodge a formal request for service that is tracked and accountable.
The term //Ticket// comes from manual systems in which a customer/client comes up to a service counter and receives a numbered 'ticket'. That //ticket// is then used as an identifier to group together all documentation and other interactions between the customer and service organization, and between different people within the organization.
In our case, the term used to record a request for one of a number of specific services:
# Bug Fixes
# Feature Requests
# Assistance Requests
The term //Ticket// comes from manual systems in which a customer/client comes up to a service counter and receives a numbered 'ticket'. That //ticket// is then used as an identifier to group together all documentation and other interactions between the customer and service organization, and between different people within the organization.
In our case, the term used to record a request for one of a number of specific services:
# Bug Fixes
# Feature Requests
# Assistance Requests
=== Using Tickets ===
For the most part the ticket system is self explanatory. However, there are some aspects such as Severity, Status and even Assigned To that requires a little bit of explanation.
==== Type ====
There are three ticket types:
||Name || Description ||
| Bug Report | A bug has been found and here are the details |
| Feature Request | Not a bug but an enhancement... "It would be nice if..." |
| Task | Not a bug or a Feature Request, it's just something that has to be done |
An example of a Task is with the release of each version of Euphoria, someone has to build the Windows Installer, the Debian Package, the FreeBSD binaries, the OS X package, etc... Those are all tasks.
==== Status ====
The life of the ticket is defined by its status. When first created its status is "New." From there it can go thru any number of paths. Before some examples, here are a list of the statuses and their meaning:
||Name || Meaning ||
| New | Brand new, no determination of its validity |
| Is Valid? | Validity is under question |
| Accepted | Is valid and is accepted as such |
| Blocked | Is valid but another ticket must be completed first before this one can be worked on |
| On Hold | Is valid but on hold for an undetermined length of time for reasons stated in the comments section |
| Fixed, Please Confirm | Is fixed but the developer doing the work wants someone to confirm it's fixed, preferably the person who submitted the ticket |
| Fixed | Is fixed and closed, no longer active |
| Invalid | Was found to not be valid and is closed, no longer active. Reasons are to be stated in the comments section |
| Duplicate | A previous ticket exists that is for the same task |
| Won't Fix | Feature or "fix" that has not been accepted for reasons stated in the comments section |
===== Examples =====
Ticket: "'Common' misspelled as 'Commn' on page XYZ" Work flow: New -> Accepted -> Fixed. There is no Fixed, Please Confirm as it was an easy confirmation for anyone.
Ticket: "gets() erases my desktop folder" Work flow: New -> Is Valid? - Invalid. It just so happens the user called gets() right after they bumped the Delete key while all Icons were selected. They assumed it was the gets() function.
Ticket: "driveid() returns an invalid letter for my W: drive" Work flow: New -> Accepted -> Fixed, Please Confirm -> Fixed. Developer could not accurately test the fix applied so requested the user confirm the fix. When the user confirmed the fix they moved it from "Fixed, Please Confirm" to "Fixed" and added a comment.
==== Severity ====
This is a field that is often abused. People believe that if it has a higher severity level then it will be worked on and fixed sooner. This is not at all the case. Developers can gauge severity pretty well and will often times alter the severity upon acceptance of a ticket. Using a higher than realistic severity just upsets people. Choose accurately. If severe, make it so, if it's not a big deal, make it so. Be honest.
||Name || Description ||
| Textual | Text error, not breaking anything but should be fixed. For example, a spelling mistake. |
| Minor | Not a big problem, I can easily work around it and it does not have widespread impact |
| Normal | I can work around it but it needs to be fixed soon, it might have widespread impact |
| Major | I can work around it but I have to rewrite 1/2 my program. Almost everyone is going to have to do the same thing as well |
| Blocking | I cannot work around it, my project is on hold until this is fixed |
It should be noted that blocking has nothing to do with an assigned Milestone. It could be thought that a status of "Blocking" means that a Milestone cannot be released until the given ticket is fixed. This is not the case. If a ticket is assigned to a Milestone then that ticket **must** be fixed **regardless** of its severity before the milestone can be completed. If it comes down to the date the milestone is to be released and there are still a few tickets, the team can decided to postpone the milestone or move the remaining tickets to the next milestone. Severity has nothing to do with milestone but everything to do with how badly the ticket affects the reporter's project.
==== Assigned To ====
This lists possible developers that will be working on the ticket. The only thing worth mentioning here is that the ticket can be placed into the "Accepted" status without a developer being assigned. One developer may look at a bug and make the determination that it is indeed valid but not be comfortable in fixing the bug. Thus, to save others the analysis time, they mark it as "Accepted" and leave the "Assigned To" blank. Other developers can decide if they can fix the bug and if so they can then choose their name as the "Assigned To" developer.
