
Ask HN: What would your ideal issue tracker look like? - alangibson
Issue trackers are something every development team needs, but no one ever seems happy with. Jira is slow and crusty, Trello doesn&#x27;t scale well for large organizations, and so on.<p>If you could manifest it just by imagining it, what would your ideal issue tracker look like?
======
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...

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

~~~
eterm
One trouble with JIRA is that it doesn't come opinionated, this often means
that if one team starts tweaking it, another team gets presented with 30
fields and no idea what to do with them all.

Or you get one location who try to use it while simulataneously another
location might use it in a completely different way, and then it becomes even
harder to really keep a grip on what's going on.

You also get fights over whether tickets should represent overall state (So
they move from TODO/INPROG/DONE) or represent the next step needed (So they
move from TODO/IN DEV/IN QA/TO DEPLOY) etc.

Or you try to do both of those and have a state explosion and no clear idea of
actual throughput.

After using too many badly run JIRA instances I'd actually like a simpler
system to come along and say _this is how you use this tool, it 's OK if you
don't want to use it this way, there are other tools for that_.

~~~
jasonpeacock
This is a JIRA management failure - why is the same workflow being imposed on
different teams?

Either the company has agreed that all teams will follow the same workflow,
then you do as described above, or each team owns their own workflow
definitions.

~~~
cybrexalpha
>each team owns their own workflow definitions

JIRA actively makes this hard. To modify a workflow a user has to be a Global
JIRA Administrator.

The whole design of JIRA is based around management. It's not really _for_
developers, as much at is is for your boss. This explains why Atlassian can
get away with the user experience being so bad - it doesn't matter because
developers aren't the ones choosing it.

~~~
mwarkentin
I think the “new” JIRA project is more self management focused. Of course it
only supports a small subset of overall features right now.

------
mcphage
\- 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 to do code review. Playing pass-the-baton about
who's currently assigned to the ticket is frustrating.

\- it would have a more loose issue life cycle. Sometimes a ticket is in a
clean state—in progress, finished, deployed. Sometimes it's not. Maybe it got
deployed then reverted. Maybe it's waiting on something else. Maybe it's in
branch somewhere. Most systems either offer nothing, or require you to set up
a rigid set of states and transitions.

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

~~~
Karunamon
I have to disagree with multiple assignees here for two reasons:

\- Accountability. If it’s everyone’s job, it’s nobody’s job. This is project
management 101, every task needs a single person who is responsible for
ensuring that task is done.

\- Scope. If you feel like you need multiple assignees, this can be a signal
that your task is too high-level and needs broken down into smaller units of
work (which will generally have one assigned). Something like Jira offers
epics, stories, and any other custom issue type you can imagine for doing
this.

~~~
mcphage
> every task needs a single person who is responsible for ensuring that task
> is done.

Indeed. But "done" means different things to different people—to the
developer, to QA, to deploy engineers, to devops, to the stakeholder. And more
goes into a ticket than done/not done, that needs other people to chime in.

------
CoolGuySteve
A native desktop client would be nice. It's really the only thing I miss about
Apple's issue tracker, Radar.

The main thing a native client can do well that a web client cannot without
extraordinary wizardry, is handle click and drag, list views, and multiple
windows properly instead of highlighting a bunch of random text.

Radar was based around 2 kinds of windows, a list of issues, and a particular
issue's details. It could do stuff like "shift select many issues, drag the
whole block to another project or parent issue", "ctrl-click multiple
unrelated issues, right click, open selected issues in new window, select all,
change priority, add parent issue", "drag issue from list view and drop in
duplicate issues pane of current window".

Despite being ugly and filled with a million textboxes, using Radar was a
breeze compared to JIRA or Github.

------
Sir_Cmpwn
Working on a ticket tracker myself. Taking notes...

Some of my key design decisions are:

Implement internal features like moving tickets between queues in an abstract
way which can be leveraged for custom workflows via the API. For example, if
you write a git commit which references a ticket, the "Joe Bloe referenced
this in a [commit](link)" note which gets added to the ticket is implemented
to leverage an API that you can leverage as well, to add any kind of notes on
tickets. This works backwards, too, you can annotate commits with arbitrary
information.

Implementing other workflows on top of more fundamental features also
addresses a lot of things. An agile/kanban-style queue of pending, in-
progress, completed tickets, for example, (will be) implemented with a generic
queueing mechanism, which you can use to implement any other kind of queues.
Someone mentioned emailing someone when a ticket enters one queue, notifying
Slack on another queue, etc - easily done with webhooks and a generic task
dispatcher I'm working on, which is also where the code that links tickets to
commits lives.

Someone else mentioned being flexible about state transitions and such, which
really annoys me about Jira (we use it at $dayjob). My ticket system
accordingly treats the humans as smarter than it and lets you do any state
changes you want, whereas Jira will get pissed with me if I try to move a
ticket backwards in the lifecycle.

Also, Jira is slow as hell. My software is much faster and requires no
JavaScript. Someone also mentioned multiple assignees: check.

[https://sr.ht](https://sr.ht)

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

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

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

~~~
jasonpeacock
^this. You get what you measure.

To design a better issue tracker, figure out what you need to measure for
success and then design a tool to measure that track changes that drive
improvements in those metrics.

For example, "feature completeness". When you achieve N of M features complete
then you have an Alpha release - now build something to track the progress of
those features.

The same for bugs - they're really an aspect of your overall product quality.
Figure out what quality metrics are important and build something to track the
progress of improving those metrics.

------
smt88
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 hosted/versioned in git (so issues are inherently tied to
code in some way).

I haven't thought that concept all the way through, but it seems like the only
way Jira fails me -- when I need to manually tie issues to commits (even
though it can be as easy as using a hashtag).

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

~~~
liveoneggs
[https://www.fossil-
scm.org/index.html/doc/trunk/www/index.wi...](https://www.fossil-
scm.org/index.html/doc/trunk/www/index.wiki)

~~~
myownlittlworld
I wish there was some way to modify fossil data from within the repository
itself. Like, if fossil's bug list were duplicated as files in the issues/
folder, and I could edit the bugs individually as files.

Yeah, if there were some way to combine fossil and org-mode, that would be
perfect. As it is, fossil by itself comes pretty darn close for me.

------
ken
Two things I always want, which I'm amazed aren't commonplace yet:

1\. One of the fundamental operations, for all of software development, is
taking a big task and dividing it into smaller tasks. The smaller tasks should
inherit the relevant fields (e.g., assignee, and target milestone) from the
original one, and the original issue should aggregate the relevant fields
(e.g., sum the time estimates, and let me see one mega-diff of all the
constituent changesets) of all of its sub-issues. Of course, sub-issues in
turn need to be able to be broken down further.

Most bug trackers are able to create dependencies between issues, so it's
possible to create such a thing out of a dependency tree, but I've never used
a system that made it _easy_.

2\. It should be Git-based. The state of the issue tracker is just data, and I
should be able to work on that without a special web-only interface that
requires me to be online (though it should still have a web UI). I want to use
my own tools -- I would have saved a ton of time over the years if I could
have just grepped the whole issue database for what I was looking for. This
would also make it easy to write programs to operate on the issue data -- I
don't want to learn your issue tracker's special API. Or do the same thing to
20 issues by having to click 200 times.

On GitHub, everything is a repo (source code, project wikis) _except_ the
issue tracker. So close! It's almost like they were intentionally trying to
make this one type of data difficult to work with.

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

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

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

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

------
michaelmure
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](https://github.com/MichaelMure/git-
bug)

~~~
DizzyDoo
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?

~~~
michaelmure
It might still be a little too early, I might still make non-compatible
changes in the data model. But that's not too far.

I plan to eventually have the ability to keep reading older version of the
data, but it's not there yet.

------
noir_lord
Pure API with a trello like level of attention to the API (there API is
fabulous).

Give devs the primitives to build their own without starting from scratch, my
problem (me as sole programmer supporting software that 70 people use) is not
the same as yours.

~~~
alangibson
I like the idea of letting people roll their own with a set of primitives, but
I'm not convinced that people really want that when it gets down to it. Devs
like the freedom to change their tools, but wouldn't most rather be getting
real work done than iterating on their issue tracker?

~~~
noir_lord
I don't know, I've not seen it tried.

However of the bug trackers I've used they all make it hard to set up custom
workflows because the UI is a poor 'DSL'.

------
iamdeedubs
I'd like to have cli be a first class experience. Work offline. GUI for the
pointy hairs.

~~~
parf02
what's the pointy hair reference?

~~~
xinsight
dilbert

~~~
parf02
thanks!

------
contingencies
The main problem with issue trackers is they treat everything the same way
(bug/issue, task, goal, project, milestone, team, etc.). Where they break out
of the one size fits all mold their abstractions generally start to break down
and using them requires mental hoop jumping and too many clicks.

Key feature: Disparate views. View as self. View as department. View as
project. View as team. View as team member. All views should work across an
arbitrary number of repos.

As a manager I frequently have to context switch like this and I want to see
three things: what's being worked on, what has changed, and where we are
headed. For the latter, a clear distinction between abstract/relative
prioritization between tasks and a timeline view (GANTT or critical path or
inter-project/inter-issue relations) would be good.

The ability to summarize what's gone on today/this week (visually), eg. send
me roughly what each team member achieved, status of their goals, what is
blocking them, and what they're refocused on, where the time and money went.
Critical when I am out of the office and don't want to spend time re-
interpreting git commits across 10s of repos.

Basically keep the need for human effort out of the loop wherever possible -
remove the reporting cycle, just use git history, any other system history
(wiki, issues, etc.) and auto-compile a comprehensive view.

The fact that github only recently added beta org dashboards and they still
have a long way to come shows there is demand here. However, you are
effectively racing against github.

Also, we do hardware so ordering or acquiring parts is a huge issue that
affects speed of iteration. I would want connectivity to accounting, purchase
order, order tracking and inventory management systems. The key feature there
is order status transparency, largely driven by third party platform order
identification and subsequent logistics provider tracking number lookup
integration for realistic ETA.

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

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

The "Edit with Emacs" extension was a game-changer for me.
[https://github.com/stsquad/emacs_chrome](https://github.com/stsquad/emacs_chrome)

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

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

~~~
vec
So capture dozens of messages. Better yet, capture dozens of symlinks to make
it trivial for me to review the messages in the original context.

The point is, I've already had a long, sprawling, disjointed conversation with
the interested party. Don't expect someone to do manual data entry that will
never actually be kept current enough to be useful, and don't force me to have
the same conversation twice.

------
hakfoo
To me, it would look a lot like Basecamp with tickets.

You'd open a thread like a typical nested message board-- say "Red Widgets
Project -> 2019 release 2 -> [Maintenance Team] Support Blue Widgets". There
would be a series of posts, probably the first one being "We need blue widget
support for customer xyz". At the bottom of the post would be links to one or
more tickets for the described task. Then there'd be followup messages,
discussing the feasibility of blue widgets, clarifying what blue widgets need
different, or noting things they discovered in the process. Maybe late in the
process, they add other tickets for "fix blue widgets turning yelliw" or
"prevent SQL injection on the blueness value", and each one appears at the
bottom of the message that spawned it.

The tickets can have individual lifecycles, but the discussion threads would
move back and forth based on activity like message boards do. Importantly,
they remain both browsable and searchable, even if you have to click through a
bunch of pagination. Maybe the threads can be flagged as "task complete" or
other statuses to improve searchability.

The discussion that goes around a ticket-- how to reproduce, the decision
making process, context associated with the issue-- has long term value. In a
ticket-centric system, this all gets attached to the ticket, which disappears
into the void when it's marked complete. This model leaves i intact, and
treats the tickets as decoration.

------
megous
No one size fits all and there's no ideal. Choice is necessary.

There are some universals though. Fast. I hate waiting 10s for page loads in
Jira or anything really, if I'm searching for something.

Good data export. Jira is very good with this. You can get XML with all the
information, IDs, relationships between things, comments, etc in a single
call.

With this I can create a tool personalized for my particular use of the issue
tracker, and only go to the issue tracker's website for non-routine tasks.

~~~
alangibson
Totally agree on Jira's speed. Watching it creep toward a fully rendered page
is what got me thinking about this.

I also find customization to be way more trouble than it should be. You
basically have to hack it to add a template to the description field.

~~~
brayhite
Our team has been pondering a move from Github’s issue tracking and projects
to JIRA, and taking a peak at it has given me similar impressions; incredibly
powerful but ultimately too large of an app for its own good. The paid
integrations are also a frustrating reality to live with.

~~~
alangibson
It's really capable, but you can feel it getting ready to collapse under its
own weight. Same goes for Confluence.

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

------
porphyrogene
GitHub Issues is nice and simple with sufficient tools to assign and
categorize issues. Many similar tools are built on top of GitHub Issues and if
they work independently they usually do so with an API that is a carbon copy
of GitHub Issues’. If you commit to using GitHub then you can always build
your own GUI or let people use Trello on top of it if they choose to do so.

------
LaundroMat
Just a side note, but one way of sifting through the features commenters have
been suggesting and prioritizing them should you be wanting to create a
product out of this is the Kano model. (I'm not affiliated, but here's a great
guide to the model: [https://foldingburritos.com/kano-
model/](https://foldingburritos.com/kano-model/))

I just wanted to share this because I've only discovered it recently (although
it's been around quite some time already) and because it's been very helpful
to me. I did a quick write-up of one project on Medium:
[https://medium.com/@monsieurthieu/before-spending-any-
money-...](https://medium.com/@monsieurthieu/before-spending-any-money-ask-
your-customer-whether-itll-be-worth-it-5a686e23c822))

~~~
alangibson
Thanks for the links. I'm not planning on building anything right now, but the
frustration that lead to me starting this thread might push me in to it one
day.

As for the Kano model, I'd take it further and do what I call the Buffer
model: price people want something by collecting payment details before you
even start building the product.

------
CuriousSkeptic
I’ve always wanted something with a unified tag,list,tree,status approach. In
one view I might want to represent an issue status as a kanban. In another the
same status is an icon, color, size, checkbox, progress bar or what have you.

F.ex let’s say I want to do a quick t-shirt sizing of a large set of issues. A
quick way to do that in a workshop is a mute mapping into size bins.

Also quick an free hierarchies are important. Workflowy style outlining,
perhaps again with some additional labeling assistance depending on nesting
level. F.ex if you want to structure things with impact mapping or story
mapping and the whole ATDD thing.

If I’m completely free to dream I’d much rather work with real pens, papers
and walls though. So the dream is to simply fix the annoying physical
limitations of that. Can I have unlimited, indexed wall space please? Also
make it easy to rearrange groups of cards.

------
zzo38computer
Currently I use Fossil (which is not bad, but there could be a better way
(possibly even modifying Fossil to support such thing), I think).

If it is on a remote server, support using a SQLite virtual table to access it
(this does not mean the server needs to use SQLite to store the database, but
only that it supports the equivalent of xBestIndex) (for local data you can
just use a SQLite database without a virtual table), then you can make up your
own queries (although you may need authorization to post messages, to view
them shouldn't need authorization). A command-line interface to file issues
(as well as to view/download them) is also helpful, and perhaps a HTML
interface too. Use whichever interface works best for your use, or all of
them, if needed.

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

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

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

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

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

------
TXV
I'm using Nulab's Backlog. This is sort of a shameless plug since I work for
that company. However I must say that after several years of clunky issue
trackers, this one feels very very refreshing. I won't waste your time with
marketing speech, which you can find plenty of on the official website. But
actually easiness of use and moderate configurability, plus a decent-looking
UI, are the points our advocates praise most often.

The company is very strong in Japan, where it was founded, but rather low-key
in the rest of the world. I never heard of it myself before I joined, but
after starting to actually use the product, I really wish I had.

~~~
jesterson
I switched to Backlog too. Despite it being rigid (wee, being japanese product
says for itself) and having small issues here and there, I can't complain
much.

Most important points for me with backlog are:

\- impossible to define task/issue additional states. \- email notifications
are not working sometimes

------
apendleton
I'd want issue state to be tied to branch state. I want an issue to be able to
capture that it's fixed in branch A but not branch B, and if I merge A into B,
it recognizes that it's now fixed in B as well.

Some systems have very rudimentary versions of this: an issue is globally open
or globally closed, but gets auto-closed when a commit is merged into one
specific branch (master or whatever), but I'd want this to be much more
generalized: fixed in a feature branch but still broken in dev and master,
then fixed in dev once the feature branch gets merged, then fixed in master
once the dev branch gets merged, etc.

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

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

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

------
SamWhited
I basically want something that's not associated with any service (eg. I
shouldn't have to create a Git repo on GitHub just to use their simple issue
tracker), is easy to use for non-devs, and doesn't have any complexity: I want
a form (possibly with some templates) where I can type text, the ability to
comment, and maybe labels for organization and search. I've actually been
working on something like that, but it's not quite ready for prime time; even
if I never launch it as a stand alone product I'll hopefully keep it around
for my own issues.

~~~
nurettin
you mean like taskwarrior?

~~~
SamWhited
I also want it synced across all of my machines, so probably with some sort of
cloud service, and want to be able to share it with other people (so as much
as I like a good TUI, I probably can't convince my coworkers in marketing or
sales to use it); but that does look really nice still.

~~~
nurettin
I use it with a self-hosted nextcloud. Integrated with jira so I can open
issues really fast (thanks to pro: flag) boss is happy and collegues have no
idea how I use jira so efficiently.

------
nwmcsween
Git with:

    
    
        // [tag]: for inline issues and 
        .issue/issues/issue-slug-name.{md,adoc,rst,etc}, 
        .issue/tags/tag/issue-slug-name -> ../../issues/issue- 
        slug-name
        .issue/tags/tag/file#lineno -> 
        ../../../some/tree/file/with/tag
    

For something advanced I would want a language like Gherkin but for bugs so
users/developers could easily show the issue given some sort of state in a
declarative language

------
simplecomplex
It would look like: My manager emails me something to do. I respond to that
email to update them. I can easily search, tag, star, and export/backup our
“tasks”. It loads instantly, and everybody has access to email everywhere they
go, on any device. There’s an archive of communication, it supports
attachments, multiple languages, and screen readers. It also has the best
uptime.

So my ideal issue tracker is email. I haven’t used anything better.

~~~
alangibson
Email is a nearly ideal version of a surprising number of things. The only
places it really falls apart is with hierarchy (i.e. epics which contain
issues which contain tasks) and in generating reports.

~~~
matfil
I'd argue that "generating reports" is quite possibly an anti-feature in an
issue tracker. It's a strong indication that whoever is building this thing is
on the side of the managers, not the doers.

------
whalesalad
I think it's Trello with an automation and management layer on top. Templates
for preconfigured boards, workflows to add custom actions to a list or card,
such as 'archive list to xyz board and rename to foo'.

Then combine that with some kind of inception where a card itself can be a
board that you can "enter". This way when a single card gets too heavy, it
becomes a board without all of the ceremony around that.

~~~
alangibson
I love the card-to-board idea. I don't know why more tools don't have a way to
'drill in'. Workflowy is basically built around the idea.

------
matfil
Titles, optional _brief_ descriptions, and an absolute minimum of other stuff.
Not lots of structured fields. _Definitely not_ custom states and flow-charts.
If there's extensively discussion to be had, put that elsewhere. Ideally,
e-mail.

I just want a TODO list to glance over occasionally, not a system that can
turn into full-time job in its own right.

------
edoceo
We use one system for triage, others for tracking. Support phone, email and
social drop in there, mostly closed right away, others then route to the
proper system GitHub Issue, Trello, etc. Triage was our biggest pain point.
And i wish for a system that forced WIP limits and only one P1

~~~
alangibson
You make a good point about the need for triage. One of the things that In or
just setup at work, all bugs get the bug label and a severity, even if someone
just saw something odd and we're not even sure if it's a bug. Since everything
goes on the same pile, you end up with a lot of junk mixed with the important
stuff

------
brayhite
A tool that all teams involved can effectively work in, or at least every
stakeholder from each team can work in. Communication is incredibly vital, and
if a tool gets in the way of that, or creates friction in clearly documenting
what the next step is, it’s not worth the money or time.

~~~
alangibson
That sounds like a vote for simplicity and an out of the box configuration
that most won't feel the need to customize.

------
pbedat
There is a really neat JIRA plugin called "structure". That allows you to put
issues into a hierarchy. We use these a lot to create roadmap, or breaking
down very complex use cases and track the big picture. Would be a first class
citizen in my ideal issue tracker.

------
laurynas-s
Moved away from Jira to GitLab and it is almost perfect.

Some features are missing, but I hope the GitLab team will add sooner or
later.

In Jira, there was too much customisation which made it difficult to configure
properly and as many times I tried to come up with perfect workflow, I have
failed to do.

~~~
mdaniel
For my curiosity, do you have one issue repo, or are the issues split up by
repo?

We have the latter, and it's monster annoying to try and discover in which
repo folks filed tickets, because there's nothing in GitLab that validates the
ticket belongs in the repo.

Given a magic wand, I would actually just switch off the issue tracker for
every repo we have, and create `the-org/issues` or maybe even `the-org/the-
org` so I can have `the-org/the-org/wiki` and `the-org/the-org/issues`

------
sneak
A definable FSM with a fixed set of transitions. Webhooks for each. Tagging,
integrated or not into the state machine. Integration with branches and commit
messages. GitHub issues is close.

Ideally the whole thing is in git or sqlite or json.

------
alexchamberlain
I'd like a system that can track things on different levels. Whether it be the
business plan or the sprint stories, it's the same thing at a different level
and translating between them can be tough.

------
bryan2
Two thing. 1) native supported cli. Something like terjira but it hooks in
natively and it should be supported by who-ever makes it. 2) All data in an
easy to read format for easy migrations, searching, etc

------
PaulHoule
The scary thing is that there are so many issue trackers out there and they
are all bad. If you want to start a new one you'd better have a plan to avoid
the traps that everyone seems to get stuck in.

------
krupan
It would look a lot like Emacs org-mode

~~~
anotheryou
The basics should be simple enough to sync cleanly to org-mode and it should
have the api for it at least!

Kanban, assigne (maybe as tag), tags, custom text-fields, custom date fields
and that should be it.

I'm slave to atlassian, but for you trello folks: [https://github.com/org-
trello/org-trello](https://github.com/org-trello/org-trello)

------
rtitle
A whiteboard.

If you have more open bugs than can be listed on a whiteboard, you are in
trouble anyway.

------
rammy1234
a simple wiki would be my kind of issue tracker. But some simple email when
your name is mentioned or your team name mentioned will be something of an
simple but effective issue tracker

------
carter_harwood
Addition of offline/sync support would be great.

------
sashk
Fast, good search and stable UI.

------
kyberias
It would be empty.

------
iblaine
Not pivotal

------
zAy0LfpBZLC8mAC
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 a third party (like
GitHub) and you would have to read pages and pages of legalese first.

If you want to have some UI for managing bug metadata, great, I don't mind,
but don't expect me to use your UI. A bug tracker in some regards is a sort of
specialized electronic messaging program. If you use Thunderbird, you don't
ask me to "create an account with Thunderbird" or to install Thunderbird, you
simply hand me your email address, and I use my MUA to send you an email--
which you can read and archive and whatever in whatever MUA you prefer. It
makes no sense to handle issue trackers fundamentally differently.

But the same at least to a degree also applies for the developer side of
things. While some of the issue tracker functionality probably is not a good
fit for email, a lot of the day to day stuff very much is, and that even
includes some of the management of metadata, so a good issue tracker should
also have at the very least a bidirectional email interface, optimally with
the possibility to manipulate bug meta data via email as well--see the Debian
bug tracker for an example of a very powerful email issue tracker interface.

An issue is essentially a thread, and as such, it should be mapped to an email
thread, where you can reply to previous messages just as you can to any other
email, without the need to switch to a different user interface.

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

------
tql
My ideal issue tracker would be able to generate all pages in <1 sec

~~~
Sir_Cmpwn
You would like mine :)

[https://todo.sr.ht/~sircmpwn/todo.sr.ht](https://todo.sr.ht/~sircmpwn/todo.sr.ht)

Most pages weigh <10 KiB on a warm cache, <30 KiB cold.

