Working on a ticket tracker myself. Taking notes... Some of my key design decisions are: Implement internal features like moving tickets between queues in an

Working on a ticket tracker myself. Taking notes... Some of my key design decisions are: Implement internal features like moving tickets between queues in an abstract way which can be leveraged for custom workflows via the API. For example, if you write a git commit which references a ticket, the "Joe Bloe referenced this in a [commit](link)" note which gets added to the ticket is implemented to leverage an API that you can leverage as well, to add any kind of notes on tickets. This works backwards, too, you can annotate commits with arbitrary information. Implementing other workflows on top of more fundamental features also addresses a lot of things. An agile/kanban-style queue of pending, in-progress, completed tickets, for example, (will be) implemented with a generic queueing mechanism, which you can use to implement any other kind of queues. Someone mentioned emailing someone when a ticket enters one queue, notifying Slack on another queue, etc - easily done with webhooks and a generic task dispatcher I'm working on, which is also where the code that links tickets to commits lives. Someone else mentioned being flexible about state transitions and such, which really annoys me about Jira (we use it at $dayjob). My ticket system accordingly treats the humans as smarter than it and lets you do any state changes you want, whereas Jira will get pissed with me if I try to move a ticket backwards in the lifecycle. Also, Jira is slow as hell. My software is much faster and requires no JavaScript. Someone also mentioned multiple assignees: check. https://sr.ht https://sr.ht