Ask HN: What would your ideal issue tracker look like?
Issue trackers are something every development team needs, but no one ever seems happy with. Jira is slow and crusty, Trello doesn't scale well for large organizations, and so on.
If you could manifest it just by imagining it, what would your ideal issue tracker look like?
127 comments
[ 2.7 ms ] story [ 159 ms ] threadIts 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).
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.
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.
I very much welcome any help to make that happen :-)
[0] http://www.bugseverywhere.org/
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.
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.
> When your team grows to 25 devs, its an almost certainty that at any point of the day, one of them is adjusting a JIRA workflow
- https://twitter.com/deedubs/status/880819973488340992
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.
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'.
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.
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
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.
Are "freetext documents" a specific thing here?
So my ideal issue tracker is email. I haven’t used anything better.
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.
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.
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.
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.
- 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.
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.
- 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.
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.
Ideally the whole thing is in git or sqlite or json.
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.
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...
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.
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.
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.
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.
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
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.
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.
https://todo.sr.ht/~sircmpwn/todo.sr.ht
Most pages weigh <10 KiB on a warm cache, <30 KiB cold.