Hacker News Reader

Comment by fusiongyro | Hacker News Reader

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

View on HN

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.

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.

> StackOverflow is a wiki so you can edit and fix other people's answers.

    Your edit was rejected because:

    [x] It deviates from the original intent of the post
    [x] It doesn't preserve the goals of the post's owner

That's what I got for updating an answer that was 3 years out-of-date. I had to post mine as a separate answer. That was 3 years ago, so my answer is now 3 years old (still accurate) and the original is now 6 years old. It has more than twice as many upvotes as mine, which languishes at the bottom of the page.

I have better things to do than labor for the wonks-run-wild at StackOverflow.

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.

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.

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.

Reply on news.ycombinator.com