Basically a bug tracker that stores the whole DB in the git repo but separately from the main tree. The tickets get synced when I push/pull, I can interact with them locally without needing an internet connection, without having to filter out projects, authenticate, etc. An open ticket would have my current branch/tag/commit as a default value for tracking, although it could be change.
And I really, really don't want notifications. Just a dashboard where the last things that are important to me are listed as long as I haven't marked them as read, and an access history.
But you can't make money with that I guess.
- FAST web interface, being able to go from issue ID to browsing it, to replying in less than a second.
- Dense, text-centric web interface. Whoever will use the tool will use it often enough that the UI should value utility over style.
- Fast, rich search, with fuzzy full text search and key:value syntax (eg.: author:foo, status:closed, etc).
- Single, flat namespace of issue IDs, preferably numeric, and the ability to follow a single issue ID as it's moved across boards/categories.
- Low friction update/create UX. Users should file issues early and often.
- First class email integration - replying to issues via email should be as good as replying via web UI. No 'write above this line', make it smart. The issue tracker should basically eradicate the need to have private email conversations.
- Unopinionated hierarchical category/component system, with per category customization of authentication. No fixed project -> board -> epic -> story -> task nonsense, let me adapt the tracker to my flow, not the other way around. And especially no fixed code repository / category relationship. And finally, no, tags are not a replacement for this.
- High quality API for automation. Features like kanban boards and other 'higher level' constructs for managers should be implemented using this API, so that users can modify and implement their own 'views' as needed, instead of relying on some fixed functionality.
- On premise, cloud-native deployment, eg. backed in cockroachdb. Cross-region failover/sync for geo redundancy.
I am Avinash, cofounder at https://bugasura.io. We are currently building a bug tracker (and reporter) for Modern teams.
This started as a way for us to track and fix bugs better. The current tools were too generic and more focused on workflows rather than helping the team to close bugs faster before a release.
We are doing this with something called 'Nudges' which is basically reminders at various points of the bug lifecycle. The intention is to remind people to resolve bugs assigned to them - nicely.
Of course there are other things in the product as well, but the idea is to keep it as simple as possible.
Would like to hear your thoughts on this. Is this something that is interesting? Useful even?
What do you think we might be missing?
Would really appreciate the feedback.
Basically, as long as it comes with a self-hostable/on-prem option, is fast, and has Jira-style issue numbers (ABC-123), I'd actually replace my Jira with this.
In the end, it's work to make it work. A bit like personal hygiene. I brush my teeth everyday, not because it helps me now but because I don't want tooth decay.
My 2cts, there is a lot that already works, or works in theory. Here are my biggest pain points.
As a developer my biggest gripes are:
- not having a clear flow open->closed, etc.
- not knowing what it means (open/closed/resolved/etc)
- not knowing what the right way to close the bug via a commit is
- not having the work item and communication separated and no easy flow between the two
- not being able to 'resolve' the issue when there is a checkup down the line
- having to have my own shadow list of bugs I'm responsible for, i.e. when I need input from somebody else and I assign the bug to them, then it's gone from my 'assigned' tickets list.
- not heaving a way to be reminded about bugs
- having to bug people about updating the ticketsThis is a major bugbear I have with jira - there's an interface that lets users create empty tickets that just have a title, but no description. They're basically a waste of time for everyone.
* Offline first and serverless by default.
* Uses a sensible configuration language to manage fields, workflows, etc. that can be versioned alongside the issues.
* Open core.
* Import/Export functionality that's shockingly good - such that migrating, say, from jira to X and back to jira a month later could be almost seamless.
Great overview of code changes related to the ticket.
Less CSS and bars and icons. More visual hierarchy, better grouping and simple call to action. Less dropdowns to do anything.
I don't actually think JIRA's that slow, if you actually run it on decent hardware. It's definitely not fast either, but there are slower things out there. But you want to keep your application snappy.
Many ticketing systems are really bad at actually tracking e-mail conversations. JIRA works for this, but it usually makes a mess out of the original email, gets stuck in loops, redirects mail to who knows where, creates dozens of redundant tickets with no option to merge them, and so on. conflating this feature with actual work tickets is, I think, a mistake. An issue tracker that also features a good way to track external communication would be a godsend. If you are looking to implement anything like this, by all means process the messages, but also store the original unchanged.
There needs to be a means of having bi-directional integration with a CMDB and a documentation platform. Being able to associate work tickets with their related resources in a CMDB is a massive time saver.
Don't allow customizing workflows too much. Certainly don't allow duplicate ticket and field types that do the same thing. Holy crap it's so easy to make a mess out of JIRA, and it's really difficult to undo. I sometimes wish that I could enforce RDBMS-style referential integrity in JIRA and write migration scripts to remove redundancy without losing data...
Implement native checklists for issues. Sometimes work items are too small to deserve their own tickets, but should be tracked nonetheless. Checklists allow you to have standard procedures without having to create a ton of redundant tickets that will just be resolved as "done".
Make it fast. Neither the developers nor QA cares about anything else but the meat. JIRA Cloud is atrocious for basically using a single page web app loaded per ticket. No need for that, absolutely not. I will be much happier if each page loads 60ms even if the price is an occasional reload. Some people have forgotten how much unnecessary junk is loaded for a tiny bit of information. I saw some of your intro gifs included animations. Drop that. Noone needs that. Seriously. We. are. not. here. for. the. bling.
One field that must be required and I have yet to see a bug tracker putting it in the spotlight: URL. If you are working with a web app, almost no bugs can exist without an URL.
Integrate with a screenshot / screencast extension. It should be natural to just show what's wrong. Right now, the workflow is: record the reproduction steps, save it off line (or google cloud at best) and insert. This is too much work. Since we have a URL, a button should open that URL and start recording and end of recording should just immediately insert it into the bugtracker and the ticket. (These movies are not likely to be atrociously big since they are can be very low frame rate and they compress real well.) Same for screenshot.
Do not have many required fields but do allow for optional ones. As Spolsky says, having too many required fields make filing bugs atrocious but not having certain fields make the life of project managers hard. Let the programmers/QA people file tickets quick and easy and let PMs organize.
If you don't have Slack integration, these days, you are dead.
And if I were dreaming... something neither Atlassian nor Google can do properly: make multiple logins just work. If I have authorized with email address A which can access the tickets of client A and also authorized with email address B which can access the tickets of client B then don't make me manually switch accounts! If I open a team A ticket, the app should be able to pick the account which can work with them and ask for a decision only of there are multiple. Freelancers will bless your name for ever. How come Google wants me to pick an account when I click on a meet and can't pick the one automatically the one I am logged in with that has access?? Raskin is spinning in his grave.
• Linear like github sync.
• github like auto links.
• A cli solution that allows me to do frequent tasks from the cli itself.
Right now I use linear[1]. It's easily the most flow preserving bug management solution I have found. It could do with a nicer and faster ui though.
Good and fast search.
APIs enabling good integrations. For example with Git/Gitlab/Github. With this one can support for various branch and release processes. Ie "is a ticket or a patch in what versions" is a different question for different processes.
I want something that control and provides tiered complexity for UI.
I don't want to be given 30 pages of advance options and field for an issue when I need something simple like severity, reproducibility and assignee.
More seriously, how about multiple sets of priorities? And a way to reconcile them. God knows the programmers usually have a second set of priorities based on how much things are at risk of falling apart at any given time and how irritating the problems are to live with. That's not usually aligned with the PM's list of priorities.
Also: the quip list! That's a feature that always brings a smile to my face!
A good scripting/automation api would be nice. Being able to make my editor perform certain issue updates makes my life easier.
Should you dog-food the bugtracker - or while your bugtracker still have bugs, does dog-fooding risk losing info... ;)
In other words commenting on a bug report should not require to login on the instance where the bug was created. In the same way replying on a mastodon toot does not require an account on the mastodon instance on from which the toot originates.
Something to try to detect a duplicate report and link the two reports together.
As many integrations with code repositories and project management tools as possible.
I would like to see the Estimate, Time Estimate and Time tracked for each issues. As well as i would like to Reply for each comment for an issue like how we reply for the comments in Social media or other platforms ( Example : Linkedin )
(I'm using JIRA below, but sub any other tracker I've used)
Generally I'll start with a very rough idea of how something should work. At this stage, I may not even capture a task in JIRA, or perhaps not even tell anybody I'm trying something out, because it is an experiment very likely to fail.
If that works, I'll put together a document (Dropbox paper/Google docs etc.) laying out the basic idea and what needs to happen to fix the problem at production quality.
This will surface a multitude of open questions, some of which are more around code-reading and prototyping, than again, a deliverable that can be captured in JIRA.
In addition, as the project becomes more of a reality, other teams with dependencies or concerns are pulled in, and the scope of my document expands to capture how we are going to solve or work around those problems.
The difficulty I face is that it is really annoying or sometimes even incoherent to create JIRA tasks capturing things in this document. First, because I am now duplicating work that was already captured in the doc. Second, I'm losing the narrative structure that keeps it all coherent in my mind, as well as the minds of readers. Third, it is near impossible to reconcile tasks being closed in JIRA vs keeping the doc itself live. For example, something might come up that forces a change of design, and now I'd like to throw away all JIRA tasks related to a specific section of the doc. But creating that level of specificity while filing tasks is really hard, so now I need to run some kind of triage and manually read and filter those tasks I want to close. This means I'm either procrastinating on updating JIRA to reflect the real nature of the project, or I'm procrastinating on updating the narrative.
Instead, if the tasks were somehow inlined into my narrative structure, and manipulable within that structure, that would be really cool! Something along the lines of Tiddlywiki almost. That way everyone on the project could see what is done and what is pending _as part of the narrative_. I can very easily write sentences to capture a new requirement and do some markup or keyboard shortcut to assign it the semantics of a task.
I guess a related ask here is to make it very easy (thinking of something like Grafana) to create dashboards that show things like "number of open tasks left to finish feature X" and so on.
I hope I'm getting some of my ideas across.
Would love to see this in a real product, so it can be used in project planning, code reviews etc.
The things that I would really like to see are:
1. First class support for dependencies. I want to easily see what a particular issue blocks and what blocks it. I want easy buttons to add a blocking issue or a blocked-by issue. (Also make it super easy to create new blockers which is great for breaking down tasks). I would also love a tool that can tell me what I can work on now, where I can make progress. Basically I want to be able to make a search for my open issues which don't have any open blockers.
2. Performance is very important. It can be fake (do everything in the background and confirm when it is done syncing to the server) but I want to dump things down so I remember them and I can sort them out later.
3. Keep everything flexible. For example I see issue types as an anti-pattern as they restrict what you can do. I often transition issues between types in Jira and end up losing half of the info because it isn't allowed in that schema. I want to track an issue of time so and requirements/plans/priority change over time so I need to be able to change everything about the ticket without losing valuable history.
4. Some sort of simple scriptability. I often have a situation where I run ls, grep or some other quick tool to generate a list then want to file issues for all of the results so I can then work my way through them. So I want an easy way to dump these into the bug tracker (probably as blockers of some other issue).
5. An email interface. I work out of my inbox and the ability to read and respond to issues from my inbox is sooooo convenient. Bonus points if I can do actions such as open/close/add blockers with an email response as well.
6. I also think the concept of "projects" is largely a mistake. Issues switch between project or cut across all of the time. I think tags are generally a more flexible option that satisfies most of the use cases. (A really nice approach that I saw was the ability for anyone to create "lists" which were used a lot as tags. So you can have a "project:foobar" list and a "backlog" list and manage those. This is also more flexible because a ticket can be in as many lists as you want.
7. An amazing feature that I have only seen from launchpad is integration with other bug tracker. My work often depends on other projects which run their own issue trackers. It would be amazing if I could depend on external issues just like internal ones.
Top Ten Tips for Bug Tracking
1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.
3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won’t fix, postponed, not repro, duplicate, or by design.
4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.
5. You’ll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn’t have to retest the bug on a version of the software where it wasn’t even supposed to be fixed.
6. If you’re a programmer, and you’re having trouble getting testers to use the bug database, just don’t accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: “please put this in the bug database. I can’t keep track of emails.”
7. If you’re a tester, and you’re having trouble getting programmers to use the bug database, just don’t tell them about bugs – put them in the database and let the database email them.
8. If you’re a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they’ll get the hint.
9. If you’re a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great “unimplemented feature” database, too.
10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It’s very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs “formally” is too much work, people will go around the bug database.
— Painless Bug Tracking, November 8, 2000 by Joel Spolsky, https://www.joelonsoftware.com/2000/11/08/painless-bug-track...
Many of the posts here echo my own experiences / grievances.
My own wish list:
* Issues should be integrated into git – like @BiteCode_dev asked for above [0]. One of the big advantages of TFS is the tight integration between issues and source control. But the disadvantage is the central server, which isn't available off premises in locked-down systems. In other words, the bug tracker should load all of its data from the repo, with potential pointers given to external big resources like screenshots, dumps, etc. Should have an easy way to pick a commit and associate it with the fixed bug.
* No push notifications. For the same reasons like @BiteCode_dev detailed above. Emails are fine.
* An API that allows building a simple web interface for users to submit bug reports, including a sample page that can be easily customized, with examples on how to auto-fill some of the fields. We have something like that, and it works great. When the app crashes users are immediately taken to this page and it auto-fills for them the type of the bug, their username, a stack trace, screenshot, and a link to the dump file (saved separately).
* Everything @q3k said above[1]. The fast interface, fast search, rich search (according to categories), the flat space of issue IDs (which TFS has and they work great), the customizability of category/component (which TFS also has), the API for automation (ditto for TFS). In fact I will only consider a bug tracking system if it has all those features.
* No pre-defined flows for open->closed, but an ability to define your own. Allow different flows for different type of issues – e.g. requirements vs. bugs.
* An easy way to copy an existing bug and all its fields to a new bug.
* A customizable way to categorize all bugs in order of importance. We have our own way of doing it, using a formula that takes into account the reporter (QA or users or managers or developer), the severity of the bug (crash vs. minor ux issues), the commonness of the bug (how many users encountered it), the estimated time to fix the bug, and the impact of the code change (a fix in a fundamental library vs a ux only tweak). This is helping a lot with prioritization when there are thousands of bugs. This can of course be customized since it's different for every team and every product.
* Can be used offline and on-premise.
* An easy API to migrate issues from other legacy system. Jira, TFS, etc.
* Standard keyboard navigation. E.g. on Windows: tabbing between fields, ctrl+s to save the changes, ctrl+z to undo edits on current field.
* Conversations and mentions with time-tags.
* A seamless way to add attachments, and to automatically store them in the correct location: small attachments (stack traces, other txt files) can be added directly to the repo. Big attachments (dumps, large screenshots, etc) should automatically be thrown in a pre-defined location – network share for an on-premise deployment, or Google Drive / OneDrive etc. I waste a couple of annoying minutes myself each week doing this for customer complaints.
* An easy API that allows integration into project management systems, for PMs.
As for your website:
* Like @chx31 said above, the cute animations are a turn off. If you want to sell this to experienced developers, this raises red flags.
* The use of the word "modern" in your website is another red flag. It's an empty, vacuous adjective that means to me you have no actual features and can't even describe your own system without insulting older systems. It's also somewhat ageist, as if you mean to imply older systems suck, or older developers suck. It's a huge turnoff for me whenever I see it on every landing page, sorry. And if you didn't mean to insult anyone then the word "modern" still has no meaning.