If you could manifest it just by imagining it, what would your ideal issue tracker look like?
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.
- 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.
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.
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.
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.
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.
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.
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).
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 :-)
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.
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.
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.
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.
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.
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
I have better things to do than labor for the wonks-run-wild at StackOverflow.
If you want to join the fun, feel free :-)
I plan to eventually have the ability to keep reading older version of the data, but it's not there yet.
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'.
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.
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)
The "Edit with Emacs" extension was a game-changer for me. https://github.com/stsquad/emacs_chrome
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 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.
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.
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.
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
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...
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-...)
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.
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.
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.
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
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?
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.
Most important points for me with backlog are:
- impossible to define task/issue additional states. - email notifications are not working sometimes
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.
// [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
So my ideal issue tracker is email. I haven’t used anything better.
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.
I just want a TODO list to glance over occasionally, not a system that can turn into full-time job in its own right.
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.
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`
Ideally the whole thing is in git or sqlite or json.
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
If you have more open bugs than can be listed on a whiteboard, you are in trouble anyway.
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.
https://todo.sr.ht/~sircmpwn/todo.sr.ht
Most pages weigh <10 KiB on a warm cache, <30 KiB cold.