[pc86]

> Tracking in external system adds overhead not only for filing the issue, but also for triaging it, backlog management, re-triaging to see if it's still a problem, and then closing it when it's finished.

Which is already what you're doing in that system, and what the system is designed for.

Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this.

We add TODOs during development, and then during review we either add a ticket and remove the TODO, or fix the issue as part of the PR and remove the TODO.

[lmm]

> Which is already what you're doing in that system, and what the system is designed for.

No it isn't. The system is designed to get managers to pay for it and it does that very well, it's very ineffective at tracking or triaging issues.

> Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this.

Most things that people build systems for managing outside of the source code repo end up being less effective to manage that way.

[pc86]

This is just intellectually lazy IMO. "Ticket management software isn't good at managing tickets, it's just good at getting stupid CTOs to pay for it because execs are stupid didn't you guys know?"

I'm sure that's true for enterprise bloatware, but there are dozens of excellent open source and/or low cost issue trackers. Hell, Trello will do about 90% of what you need out of the box if you're operating with 1-3 people.

[lmm]

> This is just intellectually lazy IMO. "Ticket management software isn't good at managing tickets, it's just good at getting stupid CTOs to pay for it because execs are stupid didn't you guys know?"

Far more intellectually lazy to assume that because people pay for it it does something useful. Have you actually tried working without a ticketing system, not just throwing up your hands as soon as anything went wrong but making a serious attempt?

[aaronbaugher]

The main problem I have with ticketing (and project management) systems is that I can't get the people asking me to do things to use the system. I'll set it up and show them how to use it, and then they tell me about issues via email or text message or voice call. I end up entering the tickets/tasks myself, at which point I might as well be using my own org-mode setup.

[CRConrad]

From all I've seen, heard, and read about that problem over the decades (yup, I think it's not mere years any more):

The only solution is to be rock-solid in refusing to do anything if there isn't a ticket for it. Your nine-thousand-percent-consistent reply to those emails, text messages, and voice calls needs to be "Yeah, make a ticket about it. I've shown you how, and that's the way we do it. No ticket, no action from me."

If you can't be that "mean" about it, you'll have to be a make-my-own-tickets doormat forever. In that perspective, doesn't feel all that "mean" any more, does it?

[Sohcahtoa82]

Where I'm at, we have a bot that automatically creates a ticket for IT any time someone posts a message to the #it-help channel on Slack. It even automatically routes the ticket based on the content of the message with decent accuracy.

[pc86]

Oh well you use emacs, that's the problem. /s

Perhaps I've been spoiled having worked almost exclusively in organizations where it's completely acceptable to get a message on Slack, or Teams, or email, or whatever, with some bug or issue, and respond with "please create a ticket" and the person... creates a ticket.

Yeah if nobody uses the system, or if you have to expend organizational capital to get them to do it (they view it as doing something for you instead of just doing their job), the system will by definitely be worth less and be less helpful.

[lan321]

Has anyone ever made a language or extended a language with serious issue tracking? I can definitely imagine a system where every folder and file can have a paired ticket file where past, future and current tasks are tracked. Theoretically, it could even bind to a source management extension for the past ones. It won't ever be as powerful and manager-friendly as JIRA, but it would be good enough for many projects.

[OJFord]

There are various things built on git (the issues don't need representation in the current state of the source necessarily after all) but I'm not aware of any with any traction - it's a hobby Show HN thing, it appeals to us, but not to product.

[lan321]

I think it'd be cooler to have it as part of the source and kind of build incrementally. So you'd have the bits in code that get added to the pair file that will then be added to the directory file... Then you can add other pairs for things like test results, and it could be decent. Some Lego Logseqesue thing :)

I wouldn't use git as a basis for it since then management is completely out. Hell, I'm probably out as well since I see git as a necessary evil.

[limagnolia]

Fossil has project management features built-in- https://fossil-scm.org/home/doc/trunk/www/index.wiki

[motorest]

> Source code is not designed to track and management issues and make sure they get prioritized, so you shouldn't be using your source code to do this.

Indeed. Who in their right mind would think it is reasonable to track relevant tasks purposely outside of a system designed and used explicitly to get tasks done?

Also, no one prevents a developer from closing a ticket before triaging it. If you fix a TODO, just post a comment and close it. I mean, will your manager complain about effortlessly clearing the backlog? Come on.