Live data from Hacker News

Ask HN: What would your ideal issue tracker look like?

news.ycombinator.com

21–30 of 128 posts

Re: Ask HN: What would your ideal issue tracker look like?

#21
post #2

The problem with Jira is not that it's slow or crusty. It's not slow anymore, and any crustiness is hidden under the hood. Its real problems are a polarizing UI (I like it, others hate it) and flexibility that leans toward bloatware-level complexity. But you can configure it to look/feel as simple as Trello, of course. To beat Jira for me, you'd have to do something revolutionary, like having the entire issue tracker…

> entire issue tracker hosted/versioned in git

I've been mulling over something like that. I don't see why issue tracker, documentation store (wiki, etc), and source code repo need to be separate. Seems more like path dependency more than reasoned choice.

Re: Ask HN: What would your ideal issue tracker look like?

#23
It would look like: My manager emails me something to do. I respond to that email to update them. I can easily search, tag, star, and export/backup our “tasks”. It loads instantly, and everybody has access to email everywhere they go, on any device. There’s an archive of communication, it supports attachments, multiple languages, and screen readers. It also has the best uptime.

So my ideal issue tracker is email. I haven’t used anything better.

Re: Ask HN: What would your ideal issue tracker look like?

#24
post #6

A tool that all teams involved can effectively work in, or at least every stakeholder from each team can work in. Communication is incredibly vital, and if a tool gets in the way of that, or creates friction in clearly documenting what the next step is, it’s not worth the money or time.

That sounds like a vote for simplicity and an out of the box configuration that most won't feel the need to customize.

Re: Ask HN: What would your ideal issue tracker look like?

#27
post #2

The problem with Jira is not that it's slow or crusty. It's not slow anymore, and any crustiness is hidden under the hood. Its real problems are a polarizing UI (I like it, others hate it) and flexibility that leans toward bloatware-level complexity. But you can configure it to look/feel as simple as Trello, of course. To beat Jira for me, you'd have to do something revolutionary, like having the entire issue tracker…

fossil does this integration

Re: Ask HN: What would your ideal issue tracker look like?

#28
I'd want issue state to be tied to branch state. I want an issue to be able to capture that it's fixed in branch A but not branch B, and if I merge A into B, it recognizes that it's now fixed in B as well.

Some systems have very rudimentary versions of this: an issue is globally open or globally closed, but gets auto-closed when a commit is merged into one specific branch (master or whatever), but I'd want this to be much more generalized: fixed in a feature branch but still broken in dev and master, then fixed in dev once the feature branch gets merged, then fixed in master once the dev branch gets merged, etc.

Re: Ask HN: What would your ideal issue tracker look like?

#29
post #2

The problem with Jira is not that it's slow or crusty. It's not slow anymore, and any crustiness is hidden under the hood. Its real problems are a polarizing UI (I like it, others hate it) and flexibility that leans toward bloatware-level complexity. But you can configure it to look/feel as simple as Trello, of course. To beat Jira for me, you'd have to do something revolutionary, like having the entire issue tracker…

> entire issue tracker hosted/versioned in git I've been mulling over something like that. I don't see why issue tracker, documentation store (wiki, etc), and source code repo need to be separate. Seems more like path dependency more than reasoned choice.

https://www.fossil-scm.org/index.html/doc/trunk/www/index.wi...

Re: Ask HN: What would your ideal issue tracker look like?

#30
post #19

Simple to figure out how to fill in all the fields, but not let me get by without adding all the required information. This does not exist and I've concluded it cannot exist. There is too much information that needed that has to be collected for simple to be possible.

I'd like to see a system that is modeled around freetext documents rather than forms. You could start with prose, and add in more controlled data via things like hashtags, @-ing other users, etc.
Post reply on HN