Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 128 posts

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

#81

Post by larkost »

My biggest problem has been with connections to automated testing systems. Specifically in the ability to keep the two in sync. My professional work in the last decade has mostly been on those automated systems, so I have a somewhat unique view. But here is what I see as missing in most (but hvae seen good parts of at some internal systems):

1. The automated system works on testing multiple configs on multiple branches. When problems arise they are marked in the testing system.

2. In the really good ones a bug can then be filed in the issue tracker that includes one or more "rules". These "rules" cover the failures discoverd in the testing system, with limits on the matrix of configs, branches, and time ranges.

3. So back in the testing system you can distinguish between "covered" and "new" bugs. You also can immediately see when a bug has been fixed, as the system then points out tests that were expected to fail that are not suceeding (flaky tests are a really nasty problem in this).

4. In an ideal system (I was working on this part at one point) the failures would not simply be of the "it failed" variety, but rather look for a fingerprint (e.g.: patterns in the logged output, or in the stack-traces). Then you could see when another bug encoches on the first (sadly common in really large systems), or when two bugs happen to hit the same tests on different configs at about the same time (again, sadly common), and even have the system suggest when old problems re-emmerge to expand the rule coverage.

Sadly there are no testing systems out there (that I have found) that can really support the "configs" model to make this really worth it. Filling that hole is what I would probably do if I won the lottery... but since I have to make a living...

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

#82

Post by fusiongyro »

alangibson wrote: post #71
fusiongyro wrote: post #66

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...

I don't know exactly how it would work. But if I wanted to figure it out, I would start by taking a fairly large project's ticket tracker and sort through every reply on every ticket and try to categorize them into buckets.

For instance, I'd expect you to find "me too" comments, and those should be eliminated, just as "me too" "answers" on S.O. are eliminated.

I'd expect you to find status-update queries and replies. So that suggests you need a mechanism for pinging for an update that doesn't require a bunch of text from user and developer, or else some mechanism by which the freshness of a ticket becomes irrelevant.add new answers to old questions.)

I'd expect you to find people posting workarounds, which would suggest that you want workarounds to be a different "type" than regular commentary, and you probably want them called out separately somehow. It sucks to have to read through three pages of identical me-too complaints to find a workaround and then read through another two pages of people thanking the workaround author for the workaround, as frequently happens on the Ubuntu tracker.

I'm not sure if these are helpful examples or not, but I think when you see a pile of messages that you have to read through to extract content, you are looking at an opportunity to work out the hidden semantics of the thing, and turn those hidden semantics into first-class entities and actions, to make a more structured environment that will save people time.

I have seen too many JIRA deployments where the only plan was, make the state machine larger and require more separate fields from everybody. But those fields and states really just represent the hope that you might not have to read that pile of comments. In practice, most of those fields wind up empty, most of those states wind up skipped over, and you still have to read the whole ticket. Why? Because a JIRA ticket is still fundamentally a chronologically-sorted forum thread.

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

#84

Post by ludwigvan »

PaulHoule wrote: post #75
fusiongyro wrote: post #66

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 Pytho…

Well, the idea that most people forgot or didn't realize (including me) is actually StackOverflow is a wiki so you can edit and fix other people's answers. You might need some reputations points before you can do that though.

The idea was to get the definitive answer as in Wikipedia. It was a good time when SO came out, afterwards it degraded in quality like anything else in universe.

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

#85

Post by ludwigvan »

- Editor integration. VS Code integration is easiest nowadays I guess.

Most programmers hate leaving their editors and dealing with text entry boxes on browsers.

In my projects, we have a wiki and a knowledge_base.md Guess which one I put random tips.

- Separating data entry from data organization.

This is the fatal mistake every web site does, confusing data entry with organization. Data entry should be free, organization should come later. That's a key reason Excel is so popular, you are free to write to any cell. None of the draconian things of forms where you are forced to think in preset boxes.

(somewhat related: compare this with the lambda/kappa architecture and event sourcing vs relational databases)

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

#86

Post by fusiongyro »

PaulHoule wrote: post #75
fusiongyro wrote: post #66

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 Pytho…

It's fine if you don't agree with my analogy or don't like S.O. but I don't think this contributes much to the discussion of how to make issue trackers.

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

#87

Post by cryptonector »

I'd like somewhat less emphasis on closing tickets and more on a big picture.

Not everything is best represented as a ticket, but JIRA has tended to make management think it can get useful data from it, and that the useful data is "tickets closed" or "time logged". Then employees just optimize for that...

Now, one can have tickets open for the purpose only of tracking work towards larger goals -umbrella tickets if you wish- and structure as much work as possible this way. This is cultural, not so much about the technology, but it needs to be widely adopted. Then you can have task, trouble, bug, etc. tickets that you fit (or don't) into these structures.

Customization of various things is important, most notably ticket status. JIRA does have that, but it'd be even better if it came with good statuses to begin with.

CLIs please. REST JSON APIs please. Email->ticket->email please.

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

#88

Post by michaelmure »

alangibson wrote: post #21
smt88 wrote: 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://github.com/MichaelMure/git-bug

I very much welcome any help to make that happen :-)

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

#90

Post by DizzyDoo »

michaelmure wrote: post #89

Shameless plug: I'm building an issue tracker integrated in your git repository, decentralized, fully working offline and from your terminal/web browser. If you want to join the fun, feel free :-) https://github.com/MichaelMure/git-bug

I really like the idea of building an issue tracker into the Git file storage! Would you recommend it for use in real life projects yet?
Post reply on HN