Live data from Hacker News

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

news.ycombinator.com

71–80 of 128 posts

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

#71

The 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,…

That's an interesting take. How would it work in practice? I would think that most teams want direct control what gets surfaced via severity, due date, etc. Or at least that's what they're used to...

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

#72

The 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,…

It'd be cool if you could extract from bug reports (or test runs) when an "issue" occurs, and count that as an upvote. I've seen sth like that that up on dashboards at a company, they had an in-house test cluster that was continually running the think, counting exceptions, and showing the leaderboard of exceptions up on a big screen.

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

#75

The 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,…

Funny, I thought Stack Overflow was a spam site.

Frequently I have to barge through ten screenfuls of code that don't work before I finally get to a correct answer.

To add insult to injury SO doesn't allow questions about many important topics such as "how do I eliminate the wheat from the chaff for all the libraries I could possibly use to do this?"

It might be 2035 when they finally add parenthesis to all the Python code examples so they work in Python 3.

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

#78
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…

Maybe you would like bugseverywhere[0] for some inspiration, at least.

[0] http://www.bugseverywhere.org/

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

#79

Something that does not try to treat each "issue" the same way. Bug ? You want to enforce "Steps / Seen /Expected" structure". And maybe hint that people should estimate the severity / criticity / cost to fix. Feature ? You want to optimize for people discussing the spec, and make it damn easy to know which decisions have been made. Bonus point for baking the "five why" in. Task ? For developpers, Optimize for splitt…

That's pretty much how JIRA works--based on issue type, you can define "screens" that expose different workflows and data. It's nice if you have a very clear idea of what you want your workflow to be, but can be a bit overwhelming to set up if you don't. Doesn't help they have a lot of different issue types though. It's a kitchen sink implementation for sure.

One trouble with JIRA is that it doesn't come opinionated, this often means that if one team starts tweaking it, another team gets presented with 30 fields and no idea what to do with them all.

Or you get one location who try to use it while simulataneously another location might use it in a completely different way, and then it becomes even harder to really keep a grip on what's going on.

You also get fights over whether tickets should represent overall state (So they move from TODO/INPROG/DONE) or represent the next step needed (So they move from TODO/IN DEV/IN QA/TO DEPLOY) etc.

Or you try to do both of those and have a state explosion and no clear idea of actual throughput.

After using too many badly run JIRA instances I'd actually like a simpler system to come along and say this is how you use this tool, it's OK if you don't want to use it this way, there are other tools for that.

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

#80
post #4

No one size fits all and there's no ideal. Choice is necessary. There are some universals though. Fast. I hate waiting 10s for page loads in Jira or anything really, if I'm searching for something. Good data export. Jira is very good with this. You can get XML with all the information, IDs, relationships between things, comments, etc in a single call. With this I can create a tool personalized for my particular use o…

[deleted]
Post reply on HN