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/system to change in some way.

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.

Assigning a priority makes sense because it helps setting the ticket's position in a queue (which can be called TODO list).

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.

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.

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.

I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's stopping others from doing their work. In that case, the right response is to drop what I was or wanted to be working on and fix the issue.

An extra case of all of the above is planning work around big releases and the like. Regardless of how solid your CI pipeline is, if there's a bigger change set released, it's good to have someone who's designated on call. They're free to work on their stuff if they please, but their main priority for that whole day is the delivery. If anything is fishy, they're the guy who picks it up first.

None of the above happens without good communication. To get to good procedures you need to take the time, discuss with your team, and agree on what your plan of operation is. Make sure it's clearly communicated both inwards and outwards. If anyone internal or external comes to you with a fire, you can point them to your plan. It may be urgent to them, but that doesn't mean it overrides your team's agreements.

With all of the above in place, the scenario you described changes considerably: instead of asking whether you can finish your task, you will instead inform the other side that you're going to finish your task, and if it fits your plan, then deal with their problem. At the end of the day, it's a matter of mutual respect — it doesn't matter what the org hierarchy is, they're asking you for help, they can't demand it.

As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied. You don't have ground to stand on, and even if your input is right, and well reasoned, it can't come _from you_ because your voice has no weight.

By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.

> 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.

I would love if you could expand on that. Do you really need it? Is this more important than production metrics or customer feedback?

> One way to recover is to automatically close tickets after a certain period of time.

Just be thoughtful about how you do this otherwise it can easily come across like "we don't really care about your issue".

Google has had two rounds of auto-closing old Android bugs and their message is really bad. Something like "Our product team is prioritising other things.".

Similarly Github's stale bot is way over used. One project I submitted a bug to closed it because there was no activity for only a month.

If you must close old bugs automatically, word it nicely, and don't close it instantly and ask people to reopen it. Something like this is best:

> We're trying to clean up our bug tracker. This bug is older than 5 years and has had no activity for 2 years. Is this still an issue?

Compare with Google's message:

> Thank you for your feedback. We have tried our best to address the issue reported [they hadn't], however our product team has shifted work priority which doesn't include this issue [what does that even mean?]. For now, we will be closing the issue as "Won't Fix (Obsolete)" [great, thanks]. If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.