My ideal issue tracker would be able to generate all pages in <1 sec
It says a lot about the state of the art that sub second rendering times is a big ask.
Ask HN: What would your ideal issue tracker look like?
61–70 of 128 posts
Re: Ask HN: What would your ideal issue tracker look like?
#62I basically want something that's not associated with any service (eg. I shouldn't have to create a Git repo on GitHub just to use their simple issue tracker), is easy to use for non-devs, and doesn't have any complexity: I want a form (possibly with some templates) where I can type text, the ability to comment, and maybe labels for organization and search. I've actually been working on something like that, but it's not quite ready for prime time; even if I never launch it as a stand alone product I'll hopefully keep it around for my own issues.
Re: Ask HN: What would your ideal issue tracker look like?
#63Working 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.
Re: Ask HN: What would your ideal issue tracker look like?
#64I basically want something that's not associated with any service (eg. I shouldn't have to create a Git repo on GitHub just to use their simple issue tracker), is easy to use for non-devs, and doesn't have any complexity: I want a form (possibly with some templates) where I can type text, the ability to comment, and maybe labels for organization and search. I've actually been working on something like that, but it's…
you mean like taskwarrior?
Re: Ask HN: What would your ideal issue tracker look like?
#65It should be as invisible as possible. I discuss an issue with someone on Slack or over email or whatever. I can invoke some magic command in band to capture the surrounding conversation and create a reference number. I can then cite that reference in code comments or commit messages. When my CI server deploys the fix, it automatically informs the other participants in the same channel the issue was created from. The…
> I can invoke some magic command in band to capture the surrounding conversation I just read about a tool that does this for documentation. I really wonder how this would work in reality because the information you want in the issue will probably be spread across dozens of messages.
So capture dozens of messages. Better yet, capture dozens of symlinks to make it trivial for me to review the messages in the original context.
The point is, I've already had a long, sprawling, disjointed conversation with the interested party. Don't expect someone to do manual data entry that will never actually be kept current enough to be useful, and don't force me to have the same conversation twice.
Re: Ask HN: What would your ideal issue tracker look like?
#66The main problem with issue trackers is similar to the problem of programming forums before Stack Overflow. Issue trackers become a chronological pile-up of crap. Stack Overflow is an incredible leap from earlier programming forums because it isolated what was valuable (questions, answers) and moved the chaff out of the way (comments, revising the question).
JIRA is basically the most sophisticated programming forum, for issue tracking. What we need is the Stack Overflow of issue tracking, that figures out what the real entities and actions are and eliminates the chronological pile-up.
Re: Ask HN: What would your ideal issue tracker look like?
#67Pure API with a trello like level of attention to the API (there API is fabulous). Give devs the primitives to build their own without starting from scratch, my problem (me as sole programmer supporting software that 70 people use) is not the same as yours.
[deleted]
Re: Ask HN: What would your ideal issue tracker look like?
#68Re: Ask HN: What would your ideal issue tracker look like?
#69A native desktop client would be nice. It's really the only thing I miss about Apple's issue tracker, Radar.
The main thing a native client can do well that a web client cannot without extraordinary wizardry, is handle click and drag, list views, and multiple windows properly instead of highlighting a bunch of random text.
Radar was based around 2 kinds of windows, a list of issues, and a particular issue's details. It could do stuff like "shift select many issues, drag the whole block to another project or parent issue", "ctrl-click multiple unrelated issues, right click, open selected issues in new window, select all, change priority, add parent issue", "drag issue from list view and drop in duplicate issues pane of current window".
Despite being ugly and filled with a million textboxes, using Radar was a breeze compared to JIRA or Github.
Re: Ask HN: What would your ideal issue tracker look like?
#70[deleted]