Live data from Hacker News

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

news.ycombinator.com

51–60 of 128 posts

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

#53

It should have a proper bidirectional email interface. I guess you were more thinking about the view of a developer of the product or project, but what I hate with a passion is when other people expect that I create an account on their issue tracker and then use their user interface for what for all intents and purposes is writing them an email. Even more fun when that includes the need to enter into a contract with…

> proper bidirectional email interface

This reminds me somewhat of a helpdesk trouble-ticketing system. I wonder if the reason issue trackers don't tend to support email gateways is to increase engagement with the tool, or if they just aren't talking to their customers' external collaborators.

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

#54

Context: I am a data analyst who previously was an auditor. JIRA was a game changer for me and I would have loved to have used it during my Audit career. As such, I want an Issue Tracker that works for technical and non-technical individuals. I would want my Issue tracker to be deeply integrated with the company's Shared File System and Developer tools so all team members have a place to share their work. The Task pa…

> The Task page would be a place where all the work done could be shared in a clean way and even serve as a quasi-wiki.

This is something sorely missing from Jira. There's Confluence, but why should you have to create a wiki page to repeat a modified version of what you already have in a ticket.

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

#56
It 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 last thing I want is yet another browser tab with another separate inbox to maintain. Interact with me entirely over the channels that I already budget attention to.

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

#58

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.

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

#59
post #56

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

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

#60
post #50

Earlier quoted context omitted.

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.

The problem is if I allow freetext someone will forget critically important information - like what product they were having problems with. Not to mention version numbers, and other details of their setup that are important.

Yea, you would probably have to have a sieve that only allowed issues with the minimal required data to transition into 'in progress' or something.
Post reply on HN