> A good practice is to fix defects before adding new features, as far as possible
This is the approach I describe as "bug is a proxy for priority", where you are essentially saying it's "highest". It is a good approach in theory, but just ignores business realities.
It also means people will try to disguise feature requests as bugs in order to get a priority.
> Assigning a priority makes sense because it helps setting the ticket's position in a queue
Except if it's numerical, then over time, you can safely ignore everything that's not P1 and you have few dozens/hundreds of unprioritized tickets.
> Severity is not the same as priority.
I know. Why is it important to make the distinction though?
> 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.
Agreed.
> 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.
Well, if dev is a factory worker turning inbound tickets into outbound features, yeah, cool, this works.
I am yet to see this in practice. Team (or at least team lead) is taking active role in the managing cycle and this is exactly what renders a lot of your points at least duplicit.
(But you have a lot of good points about assumptions about team organization that should be mentioned)