There Are No Bugs, Just TODOs
In general tickets describe change requests, and they are sometimes referred to as such (CRs): Someone wants the software&#x2F;system to change in some way.<p>A ticket type makes sense because bugs and new features are not the same and we should care about the difference. A bug is a defect in the implementation of a feature that should be fixed. A good practice is to fix defects before adding new features, as far as possible.
A defect is discovered on a specific software version so it then makes sense to indicate that. Even with continuous delivery it is useful to know exactly what build exhibited the issue.
Having explicit information on whether a ticket is a defect or a new features is also helpful for QA (as is severity): I need to keep track of the number of defects found in order to somehow measure the quality of my software and of my testing and to improve it.<p>Assigning a priority makes sense because it helps setting the ticket&#x27;s position in a queue (which can be called TODO list).<p>Severity is not the same as priority. Severity is the impact of a defect. A defect that causes the application to crash and delete all data is very severe. A typo is likely not a severe defect. Again that helps in assigning a priority and thus how to insert the ticket in the TODO list.<p>The position in the TODO list is not an input it is an output of the task that consists in analysing and managing the pending tickets.<p>You could say that a dev is a worker task that picks the next ticket in the TODO list in a loop, while a (project) manager manages the tickets and insert them in the TODO list.