Ask HN: What would your ideal issue tracker look like?
51–60 of 128 posts
Re: Ask HN: What would your ideal issue tracker look like?
#52I'd like to have cli be a first class experience. Work offline. GUI for the pointy hairs.
Re: Ask HN: What would your ideal issue tracker look like?
#53It 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…
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?
#54Context: 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…
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?
#55My ideal issue tracker would be able to generate all pages in <1 sec
https://todo.sr.ht/~sircmpwn/todo.sr.ht
Most pages weigh <10 KiB on a warm cache, <30 KiB cold.
Re: Ask HN: What would your ideal issue tracker look like?
#56I 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?
#57Re: Ask HN: What would your ideal issue tracker look like?
#58Something 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…
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?
#59It 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 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?
#60Earlier 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.