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

41–50 of 128 posts

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

#41

Post by phtrivier »

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 splitting the task in smaller chunks, and make it very easy to give dependencies between tasks.

For managers ? Optimize for letting the developpers rank the risk of each task to make it possible to estimate the overall risk of a set of features.

Product Owner ? Aggregate features / tasks into roadmap that compute the percentage of each billable feature that is actually done. Associate a risk to selling something that is in the roadmap, but done done yet. Make it harder fo sales to still sell a feature that had knowingly 2% chance of being done by demo day.

Sales ? Optimize for knowing the assumptions under which they can sell the stuff. Maintain a FAQ and list of caveats for your product ("does it work in China ? How much x do we support ? Etc...)

See a pattern here : every user of a task system expect different things, and it's hard to make a system that transition from a role to another.

Much easier to make another to do list on steroid with a poor text editor, a poor forum, and poor gant chart, etc...

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

#42

Post by vidanay »

alangibson wrote: post #38
vidanay wrote: post #33

Earlier quoted context omitted.

Fogbugz/Kiln had a variation of this. You could easily see which branches a particular commit was in and it was tied back to the ticket as well. It didn't influence ticket state, but it was easily cross-referenceable.

Have you used Fogbugz? If so, what's your opinion of it?

I loved it! Unfortunately, I was overruled about three years ago and against (quite strong) protesting on my part, we left it for Easy Redmine (strong dislike).

I have no idea what it is like anymore since it is no longer under to stewardship of Joel, and it's been quite a while since I used it.

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

#43

Post by sshb »

It should have basic concept of “queues with stuff” which can be integrated with anything.

Examples:

1. Website form → queue with requests from website → human/machine handling them

2. App error happens → queue of errors → developer sees them in queue

3. Something gets inserted to the queue → someone gets called

All this should have some ui above it

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

#44

Post by alangibson »

mcphage wrote: post #36

- it wouldn't assume that problems map 1-to-1 with solutions. A reported problem might require several things to solve, and a solution might handle multiple problems. - it would make it easier to collaborate. Most issue trackers have a single person assigned to a ticket, but I would want multiple: the person working on it, the person testing it. Other people brought in to answer a single question. A person brought in…

> Most issue trackers have a single person assigned to a ticket, but I would want multiple

Totally agree here. Having a single assignee is total nonsense. Makes you wonder if the people building the tool use it.

> rigid set of states and transitions

I think the whole idea of a set workflow is a relic from the 90's that has little basis in reality, especially in an agile development team.

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

#45

Post by slantyyz »

alangibson wrote: post #38
vidanay wrote: post #33

Earlier quoted context omitted.

Fogbugz/Kiln had a variation of this. You could easily see which branches a particular commit was in and it was tied back to the ticket as well. It didn't influence ticket state, but it was easily cross-referenceable.

Have you used Fogbugz? If so, what's your opinion of it?

Fogbugz, now known as Manuscript, is pretty good. It is somewhere between overly simple (Github Issues) and overly complicated (JIRA).

I like it way better than JIRA (having said that, I haven't used JIRA in years).

If you're a startup, you used to be able to get a two-user account for free -- not sure if they still do it, as Manuscript/Fogbugz got acquired by another company recently.

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

#47

Post by alangibson »

mcphage wrote: post #40
alangibson wrote: post #30

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.

> modeled around freetext documents Are "freetext documents" a specific thing here?

No, just unstructured text. The idea is to start out with prose to encourage creative thought (as opposed to robotically clicking at a form) and then enrich it with more structured data later.

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

#48

Post by parallel_item »

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 page would be a place where all the work done could be shared in a clean way and even serve as a quasi-wiki. Like a Jupyter Notebook, I would love to include Markdown and Code along with attachments, analyses, and opinions. Everything would be included, not just the final relevant pieces. Side-analyses stemming from anomalies and potential issues would be hidden but there for those who need them. If something changed in an attachment like an Excel file, these changes would be reflected. Adding dependencies on files and the information contained within them could be linked so that if Account Manager A changes File B, I know that my work on Ticker 123 is now potentially conflicted.

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

#50

Post by bluGill »

alangibson wrote: post #30
bluGill wrote: post #19

Simple to figure out how to fill in all the fields, but not let me get by without adding all the required information. This does not exist and I've concluded it cannot exist. There is too much information that needed that has to be collected for simple to be possible.

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.
Post reply on HN