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...
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.
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.
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.
- 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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?
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.
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.
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.
- 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)
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.
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.
> 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.
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.
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.
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...
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.
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/)
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.
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.
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.
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.
Ah, gotcha. I’ve seen a system like that at my doctor’s office, it always seems really clever. You just type whatever in, and if it means something, the system will link it up or help you complete the value or whatever. That would be much better than Jira’s strict fields.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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`
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.
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