I got to similar conclusions and I think I figured out why: The ticketing software is not made to make developer life easier. It is designed to keep the rest o

I got to similar conclusions and I think I figured out why: The ticketing software is not made to make developer life easier. It is designed to keep the rest of the company involved in the process and it's there to show the manager whatever semi-meaningless metric they want to track this week. I don't care about the exact type of the issue, or the arbitrary priority of it. "This is security bug that needs to be fixed now" and "this goes next release" is about as much granularity as I need. What's even the difference between "trivial" "low" and "minor" ? I do care about dependencies but in a "unless X is done don't even show Y in my list" way. I do not care about tracking time at all I do not care about assigning a ticket to a "component", I put the ticket number in commit anyway, obviously that already shows which component code I needed to change to fix it Obviously many of those are useful (or are imagined to be useful) to other roles in project but as developer I just want to see the reported bugs/features and write the code for it.