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?
When would I use this instead of Jira or Github Issues?
Github sync would be nice.
Zendesk integration would be nice.
The few scenarios in which I imagine it would make sense to track bugs outside of Jira or Github Issues are when the bug reports arrive to a customer support desk and the bug needs to be linked to 1 or more customer tickets and tracked within Zendesk, and yet the actual work against the bug item is being tracked in Github Issues (or Jira, etc). Whereby some property on the issue can be modified to indicate severity and impact (i.e. fixing this would close n customer tickets of which the highest severity is x), so that something is gluing together the disparate systems that exist around a bug.
A bug tracker by itself... doesn't feel as valuable as the integration that enables the smooth management of a bug for all those who interact with it.
A mature bug system might even have complex routing rules, so that Zendesk automation can apply, if tagged as X, create an issue against this repo and link these two things together, and to even allow the moving of the downstream ticket between systems of differing types, i.e. "this ticket doesn't apply to this Github repo, move the ticket to Jira as it does apply to that other team".
Then as the master view of bugs and debt across the company (even spread across multiple repos, systems, issue trackers) a bug tracking tool now makes a lot of sense.
Your landing page talks all about workflows, so I'm unclear how this meets your own stated goal of being focused less on workflows and more on helping the team close bugs faster. From reading your page, I don't see a single feature that isn't already in Jira. I also have no ideas why reminding people to do their work is an issue to be resolved by software - sounds like a cultural problem, not a tech problem.
In any case, I don't think your problem is that you are missing features. It is that you are aiming for table stakes, and aren't showing us anything new and exciting.
If you want to truly change how teams operate and present us with a new model for managing and closing bugs, then you need to live up to your own description, move away from workflows and "my bugs" listed on pages, and show us something completely new.
We are trying to be less workflow focused and more closure focused. I do see how it might not be clear on the landing page.
You are right, we have limited features. That is because we are a small team and we want to have only the minimum features required for bug tracking (and not everything JIRA has). But, what we do intend is to go deep into this space and really question how we have all been building software and managing bugs.
The nudging people to move issues is indeed a culture thing. And the intention is to bring in culture building as part of the platform. This will reinforce and make resolving issues a much needed thing in our space.
The wrong culture is a bug, and maybe bugasura will help fix it. :)
Here's something that bugs me: Whenever I release a new version of something, non-closed bugs should be tagged as "review", to check if the problem has solved itself (e.g. by updating to a new library that was used somewhere else)
On the surface, it sounds like a good idea. When thinking about it further, I think this is solving the wrong problem. Bugtrackers usually (in my experience, after 1-2 years on a project) end up with thousands of tickets, too many of them open. If after every release, you have to re-check all of them, the QA department (or whoever will do the review) will spend all their time reconfirming bugs that the engineers could easily have said "Yes, still an issue" or "Nope, fixed" after just glancing on it, compared to a tester who might not understand all the code changes.
Instead, aggregating information and making your bug tracker "clean" should help engineers knowing what's open and what's been fixed, and when doing a new release version, they should know exactly what has been fixed already.
You can do stuff like that with jira automations. Yes, I know, I too despise jira for its 20MB pageloads, horrible UX and hundreds of main-thread blocking requests. But that's not the point here. So, if you happen to use jira - as unpleasant as it may be - it's probably best to just deal with it and use it to its fullest potential ;-)
I'd like to have a serverless bug tracker, like Fossil, but for git.
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.
Edit: consider having a look at the development version. While the core feature hasn't changed much, the webUI definitely improved. Also, the core became more robust and ready to accept more features easily.
Not very promising, it is written in a language which:
- is controlled by Google.
- doesn't support generics. Do we really want people to constantly rewrite basic data structure classes in 2021 and thereby reinvent bugs constantly (and waste time which could be spent on more meaningful purposes)?
Very valid points about recaptchas. Now, what does that have to do with the Go programming language that is FOSS?
Or are you calling for developers to essentially put restrictive sanctions on any and all Google products/projects?
And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?
Because you seem to be demanding such a standard from the rest of us.
> Or are you calling for developers to essentially put restrictive sanctions on any and all Google products/projects?
Yes.
> And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?
I intentionally enter a large percentage of invalid data into recaptchas to spoil their dataset.
Google Analytics is blocked by my ad blocker.
Same goes for ads on youtube.
With regards to using their stuff, I don't demand anyone should stop privately using it if they need it. You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.
> I intentionally enter a large percentage of invalid data into recaptchas to spoil their dataset.
So do a few others. You are easily selected out as anomalous data, just fyi.
> Google Analytics is blocked by my ad blocker.
Great. Are you also blocking Google Fonts? Are you sure that Google is not hosting anything you are touching on a website?
> Same goes for ads on youtube.
But advertisers pay YouTube based on the viewership reputation of YouTube. You are merely providing a reduced amount of value to Google in this way.
> You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.
Very honest question: Do you think you would have actually said this same thing about the C programming language in the 70s, 80s? Maybe you would have.
All in all, I am not sure that your stance justifies writing no code in Go which provides less value to Google's bottomline than even Google Fonts.
Perhaps some advertiser somewhere in the tech industry benefits from Google's public-facing Go packages proxy data for reaching a developer audience to sell to? Who knows? But, developers can turn that off and/or use self-hosted proxies.
Also, lone wolf retaliation is fine but not nearly as effective as just running for political office and being anti-Google.
> Do you use the same argument when purchasing consumer products from shady countries which abuse workers?
This analogy makes no sense. You are comparing a product made through coercion and abuse of workers to a product willingly made with tools that you happen to have differing preferences on.
My point is NOT that Go would be made primarily through forced labor (although usage of money earned through the yield of the forced labor from ReCaptcha is rather likely).
My point is that Google is an evil company, and we shouldn't support evil entities by using their stuff.
And to make that point apparent, I mentioned other instances where people would think it is pretty obvious that "producer is evil = don't use their stuff", hoping that you would see there is no reason to act any different on Google just because they produce products which are of a type different from those that evil entities normal produce.
Because it really doesn't matter whether it is software or clothes or diamonds, if you use something publicly of someone you support them, and Google should not be supported.
Forced labor is also tried and tested and doesn't pertain to the resulting product, yet you wouldn't willingly purchase products made by it, would you?
A malicious producer can taint their products solely by being the producer.
This is such an oversimplification. Microsoft, Apple, Amazon, etc. are all guilty of ecosystem lock-in. Google in many ways is the most generous when it comes to open source and most of the hardware utilizing Google is by other manufacturers.
Damn, these are some stupid arguments. Go is open source. Even if Google went rogue, there's nothing they could do. Go would just get forked by the community and that's it. As for generics, they're just nothing more than a developer convenience, they don't matter at all regarding what a product can do. Also they're planned in Go for next year.
> Go is open source. Even if Google went rogue, there's nothing they could do.
Have you ever used a library where the company who paid the development went "whoops, not our product anymore! poof goes the paid team, website, the community forums, the knowledgebase" ?
Usually nobody continues to maintain these after 90% of the workforce behind them gets fired and the surrounding infrastructure disappears.
Software is almost worthless without the brains behind it.
> As for generics, they're just nothing more than a developer convenience,
So you propose people write the 100,000th implementation of linked lists, maps, etc. because what they want to stick into it is not class A but class B?
> Also they're planned in Go for next year.
The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.
It might have been nice as a toy to teach aspiring programmers. It shouldn't have ended up in production software.
> Damn, these are some stupid arguments.
Thanks. I consider yours as stupid too. How much progress exactly have we achieved with this wording now?
You are absolutely right! And this is why I avoid any and all software written in C due to AT&Ts prior evil monopolistic practices of the mid-20th century. /s
Yes but all those tools share one common problem: they leak their implementation or want to do too much.
The ruby one ask to gem install, the python one to pip install, the one in bash assumes Unix, the one in perl tells you to "make install" (!), radicle wants to replace my entire stack.
As a Python dev, I don't want to ask my front end experts or worse, my testing team, to setup an entire python env just so they can fill tickets. I just want to donwload an executable, and then fill in my tickets.
gitbug gives us binaries. You just execute it, and you are good to go.
Maybe one day, Python devs will take the time to use nuitka to produce binaries for their users.
Because as a dev, my attention is precious. To be productive, I prefer to pull information, than to be pushed information to.
E.G: HN doesn't push information on me. I can answer to you now because I know that at this very moment, I don't need to focus on something hard. But this afternoon, I will, and so I don't want to be disturbed and will just close this tab. Voilà, no distraction.
I don't need to be notified bugs: I don't work on them in real time. In the morning, I select the ones I will work on. New ones have little relevance to me until the next morning, which a dashboard will show me.
I need notifications on things like my clients calling me or my server failing. Those are the stuff that I need in real time.
The very first thing I do when registering with a new service, especially corporate/social ones is to go to the notification settings and disable everything but the direct message stuff.
I leave them enabled but email only, then I set up filters for each service to move it to */automated/jira directories automatically.
That way my inbox stays clear but I can speed run through first thing to make sure I’ve not missed anything, I also ruthless cull anything unrelated to my work, so any notification a project I don’t work on gets deleted.
This reduces several thousand emails a month to about 6 I actually need to see in my inbox.
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 )
Automatically tracking time of an issue as it moves from Doing to Done and maybe then predicting (a default) Time Estimate based on the textual description and past issues would be nice :)
Time and time estimates are the least important things imo. If someone bills by the hour, there are ample good ways to do that already, and estimates are always inaccurate (something like story points are a better system). You should track effort and status, not time.
You should look into Azure DevOps Boards, it seems quite flexible from what I could see when using the templates other people have done. It can be made for custom workflows, custom fields, custom forms, etc.
The main problem we have with GitHub issues is that it's pretty overwhelming for some of our clients - especially as GitHub has no concept of "issues only users". Our clients set up a GitHub account to open a ticket and suddenly find themselves looking at source code, commits, pull requests, CI stuff - just endless noise around the one thing that's actually important to them. On GitHub, for someone to be allowed to move a ticket from one column to another in a project kanban board you have to give them full write access to the entire repository, it's madness. GitHub issues is great for developers, but an absolute mess for anyone that has to work with the developers.
That's such a great observation. I think everyone has seen non developers added to git repos only to see their accounts sitting around unused for exactly that reason
Agree. We are putting out a public projects option where you can get feedback from users (instead of internal teams). Very similar to github issues.
But the what we need to get over is - how can we ever replace Github Issues. I mean, it is 'integrated' into github and will be a natural place for people to report issues. Like MS bundling IE or Google calendar adding Google Meet links into calendar invites automatically.
Good question, and something I did actually start writing about in my original post but worried it was diluting the point. I think it would need to sync seamlessly with GitHub so issues referenced in commit messages link the commit to the issue - possibly even two way sync with GitHub issues - for it to still be usable and useful for the dev team.
But, GitHub has really only sown up the issues part for developers, for everyone else it's a mess - so if your differentiator is building something that's useful to everyone _else_ on the project, you could be on to a winner. On our projects, the everyone else typically outnumber the developers by about 3 to 1, sometimes even more. These are designers, project managers, client-side stakeholders etc. All of these people need to interact with an issue system, all of them need to be able to track progress, all of them need visibility on how a project is going.
Jira will tell you that that's what they do, but of course it isn't, Jira is a crime against humanity.
Github does seem to have a marketplace that we could get into. Maybe something we can explore.
Sync is simple to sort out.
We were thinking of two kinds of projects
1. Private - for the internal dev teams to work on
2. Public - for external folks like end users to work with internal teams
Now I see another one which is CLIENTS only - for a restricted set of external users.
Thought: Make a free marketplace extension that allows a one-click "configure this user's subscriptions to different event types to make it into an issues-only user from that user's POV".
Both useful and if done right would hopefully be much more of a way to get people to engage with your product/brand than it would be "enabling a competitor" (I think ... or at least: I'm not trying to convince you to do something against your own interests for my own gain here, but that does not at all mean I'm not completely wrong ;)
A couple of years ago I spent a while researching issue trackers and could never find one that had everything I wanted. We settled on GitHub issues, which has a nice design, public access, labels, assignment, and new issue templates. But it's still missing private issues in public repos, and issues that are blocked on/depends on other issues. It's also clearly designed around repos rather than specific to issue tracking. We make do anyway.
This is very true. Before we started building we looked around and didn't find anything good.
Githib issues was the nearest, but it was linked to repos and it didn't make sense for us to create repos just to use bug tracking.
Our current product has only private projects, but we are going to be bringing out public projects to get feedback from end users (similar to github issues).
This is to infact help us manage our user/customer feedback and issues.
- 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.
> Single, flat namespace of issue IDs, preferably numeric,
This has always annoyed me about existing open source alternatives to Jira. I actually like ticket numbers with a project slug, because they add far more context. A five-digit number is far less readable than ABC-123, because you know it associates with project ABC.
Interesting, because in my experience issue references are always in context (eg. in code comments, or in prose with context explained), so I more often felt that the slug part was outdated/pigeonholed than actually helpful in establishing some extra information.
Would something like the ability to optionally have slugs, but still a single numeric namespace be a good compromise for you?
For example: FOO-123 takes you to the same issue page as BAR-123 (everything before the number is ignored when actually routing the web interface), but when seeing internal references in the tracker, a per-component slug is prepended if configured (eg. the infra component could be configured to always refer to its issues as INFRA-nnn). This would let issues be moved around components while a maintaining a greppable, constant ID, but for users to use slugs if that helps them.
I tried this approach with Taiga.io, but it doesn't address another bonus of having slug-based ticket numbers - namespace separation is a feature which helps to keep the number of digits down, because each slug starts with its own counter.
One of the problems with flat-namespace numbers is that the numbers are so long that eyes start to glaze over them. A three-digit number is pretty easy to tell apart from another just from the "shape" (if that makes sense) of the digits, wherease this "shape" is completely obscured once the counter exceeds 4 digits.
Ideally, a system like this would just have a toggle to configure whether one wants to use a flat namespace (with or without slugs), or multiple namespaces with slugs. It's not that difficult from a technical perspective, since the primary key for the ticket will be some internal linear number anyway, and the separate namespaced slugs are just human-oriented handles.
The single numerical namespace, from a technical perspective, is a double-edged sword. On one hand, you need to have a single, monotonically-increasing-ish number in your model, which is annoying when trying to design a globally distributed system. On the other hand, when users are (subconsciously) taught to not look that much into the actual numbers, there's opportunities to cheat, as an extra hundred here and a few missed numbers there won't be noticed but help with technical implementation details (you can pre-allocate number ranges, encode some technical details in the number, even just use snowflake ids, etc).
With namespaced 'small numbers', as you said, per-slug numbers will be scrutinized by users - if they file FOO-223 now and FOO-105 later, they will notice and they will be confused / surprised / unhappy. However, with per-namespace numbers you're at least given an opportunity to shard and have a less contested model.
Approaching this as optional handles is probably a good future extension and would fit in the existing model. I'll keep this in mind when I get back to developing bugless. Thanks for your input!
> namespace separation is a feature which helps to keep the number of digits down
I'm probably a minority as I think I have pretty bad memory but as soon as your tickets hit double digits I am failing to remember which ticket is which. So I don't really care if it is 3 digits or 7 digits. If I am trying to remember I'll probably just look at the last 2 digits anyways.
My major issue is that tickets move between projects or affect multiple projects so you get the situation where this slug is often correct, but often isn't. Or worse you move the ticket between projects and the slug changes, breaking links.
Ideally, moving a ticket from one project to another means that the old slug is just the alias for the new one. If that's the case, the link would remain unbroken if the redirection was transparent (ideally with an info message to inform the user that the ticket now has a new slug).
Looked at bugless, it is wonderful you started it but bummed that it needs more. The list you have is good and we are attempting to make things simple with https://bugasura.io
Unlike bugless, it ain't open source but nevertheless, we should look deeper into your work, get inspired, borrow some stuff and pass on some credits to you.
I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug, and many are already there. If you feel like pushing your own project is too much to bear, maybe consider contributing to git-bug to make it your own?
I know of git-bug, it's a great idea and I watch its development carefully, but I'm explicitly looking to leverage benefits of a centralized system with bugless. I'm not targeting open source software projects that need a decentralized system that works well with an existing Git repository, but communities and organizations that already run infrastructure, including SSO/authz.
What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.
-- per-issue/component authorization (secrecy!):
git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise.
-- ease of access to non-git users:
the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling.
-- history rewriting/sanitizing:
not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...).
-- built-in large attachment hosting:
Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below.
-- gigabytes of issue data and generally large scale deployments for large organizations:
The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.
For secrecy and access, just relying on end-user keys and encryption is not good enough for me - e2e encryption UX is tricky (key management, backup, access from multiple devices, onboarding), and tends to turn less technically minded users away (or they lock themselves out by not properly backing things up).
For history rewriting and sanitizing: I mean, someone posted something that needs to be removed before it's seen by a wider audience. I don't know, customer PII in the wrong component, abusive content (eg. dox) on a public tracker or internally by a disgruntled employee, server logs in an attachment that should be removed a year after having been posted (in accordance with a privacy policy), etc. I want to ensure that content can be nuked, and access to sensitive data revoked. This is also another reason why secrecy via e2e encryption in a fully decentralized system doesn't work for me: if a user's key gets compromised, all secret data that this user had access to is forever accessible to the attacker. With server-side access, it can be revoked, which helps if the data has not yet been downloaded. Plus you can keep an audit trail to detect any attempts at data exfiltration, while data exfiltrated by key compromise might never be detected.
That's fair, those are indeed hard to do right or impossible (although I hope we can collectively solve the "people use crypto keys properly" problem at some point).
Just a note though, you could centralize git-bug. Standardize/build on what git-bug is doing, and just don't expose the bug data in the same repo as the code. You then just need the extra bits of centralized administration.
* Scriptability built in from the ground up and a plugin architecture that is used to build all non-fundamental features. I don't mind buying plugins from a store if I get source code and it's a seamless process.
* 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.
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.
As a product owner:
- not heaving a way to be reminded about bugs
- having to bug people about updating the tickets
- 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
Maybe a visual representation of the flow and a text desc of what each stage means might help?
- 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
What does this mean?
- 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.
This is already available. It was a major thing for us as we both build the software and also find issues when we use it. So we needed a way to take care of both. The dashboard gives you a view of issues assiged to you and reported by you.
- not heaving a way to be reminded about bugs
Not having 'to' remind others or to be reminded? If its the former, then we have nudges that gently nudges people assigned to move the bug. If its the later, maybe a way to switch off nudges would help.
I did think of putting this in 'show hn', but since we are very early and still building, I thought its good to actually listen to what can be done better.
Maybe next time, we will be in a better shape and can go on 'show hn' :)
I want a faster Jira. Atlassian's current offering is very slow, and they just withdrew support for on-prem without an expensive Data Centre license which was problematic for me.
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.
I applaud your focus on performance. Most SaaS is garbage-slow in this area. Unfortunately, bugasura is not a replacement for my specific use case, since there's no on-prem/self-hosted option. Do you have any plans to support this deployment mode, via Docker or otherwise?
It needs to be impossible to create an issue that has no description.
This 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.
They could, but at least then it'd be obvious to the reporters that they were doing something stupid and annoying, as opposed to the current situation in jira where there are workflows that conceal the issue description field to reporters entirely.
Joel Spolsky had some things to say about this back in 2000:
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.
Thanks for sharing this. I never read this article of Joel. Must be because I never thought I will end up building a bug tracker of all things!
Very useful pointers there.
1. Make sense, maybe add some CANNED FORMATS for steps to reproduce will make sense.
2. true, but its now a question of FIXED RESTRICTED WORKFLOWS vs FLEXIBLE WORKFLOWS (like trello)...
3. this is already there
4. yes
5. already available
6. we have added in a 'report/respond to bugs via email' feature that lets you email in the report. Couldn't get some of our team members to change their 'emailing bugs' habit
7. yes, agree
8. Absolutely true. There needs to be a PM who does remind them though, otherwise we will have stale bugs at the end of the sprint
9. A thought might be to group a set of bugs into a feature. Maybe that can be a feature of the bug tracker
11. This is our greatest blocker as of now. Every user wants a new field to track.
I use Github with clubhouse.io. Having a story for tracking the progress of work on a bug automatically move across columns on the kanban board means everyone who isn't a developer knows what the state of it is without needing to learn to use Github and development langauge. It makes talking about the progress of work much simpler.
Essentially I view integrations as a way to automating translating information between developer's focus and understanding of something, a product/project manager's understanding of it, a client's understanding of it, etc. I don't need to explain that a bug has progressed past PR and deployed to a test server if the product manger can see the story move from Development to QA on their view of a project. Also, as people are fallible, it means no one has to manually update the status of a story. Everyone is up to date by 'magic'.
Fast. Something like max 100 ms page rendering time. Even when your computer is bogged down by screen sharing on a telecon. It just makes everybody anxious on a meeting when they have to look at the presenter's Jira loading up. If you need to implement a progress bar, the game is already lost.
I think one could have a CI test for this right from the start, otherwise it will just gets worse and worse with feature addition.
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.
Well, I'm not familiar with your product but for example, if there's a bug #bug-789 reported that affects version 1.2, a developer does a fix to that version with commit message like "fixes:#bug-789", automation in the CI can use the bug tracker API and send information to the bug tracker: version 1.2 contains a fix for #bug-789 now. Or it could even say 1.2 was fixed in patch 1.2.435.
Users then could for example ask, I have version 1.2.322, what bug fixes do I get if I upgrade to 1.2.435 (latest). With this information, you could answer that with a view in the bug tracker.
But some companies might use a different versioning or patching scheme. So the bug tracker would need to be general enough to support those different processes. The key is integrations.
First class off line experience is a must. As more and more of us move to remote only (huzzah!) you can't always expect to have connection. Some of the best, most productive environments are exactly productive because they have no Internet connection. Make this seamless. While using git is desirable to some extent, making it just work from the browser whether online or not IMO is way more important.
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.
Thanks for taking the time out to write a detailed list. It really helps.
Offline, this is something a few people have been asking. It is a nightmare though with all its sync issues and conflicts :) But something we will look into.
Fast, definitely yes. We want a < 100ms for each load, everytime. Point taken about the gifs.
URL - yes. We did have that when creating a project, but we dropped it eventually. Might be a good idea to add it a the report or bug level.
Custom fields - this is a hard choice. We need to balance between flexibility and simplicity.
Slack - already integrated. You can get updates on your project on slack and in a few weeks respond back as well
Dream come true - we already have that. Its called Mult-Teams and you can be in different teams all on the same dashboard. The view is tailored for YOU and not the project/team.
Copy/paste images. I'm now spoiled enough by other services to find separately saving, uploading, linking images super tiresome. Resizing and placement options (putting images besides each other) would be nice (either via UI or markup attributes, depending on your audience).
Background:
We have at work an internal bug tracking system based on a heavily customized TFS (aka azure devops) template, with an internal workflow against QA and customers. Both the template and the workflow were partially developed by me, and partially by my managers over the years.
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 la...
140 comments
[ 2.9 ms ] story [ 202 ms ] threadI 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.
Github sync would be nice.
Zendesk integration would be nice.
The few scenarios in which I imagine it would make sense to track bugs outside of Jira or Github Issues are when the bug reports arrive to a customer support desk and the bug needs to be linked to 1 or more customer tickets and tracked within Zendesk, and yet the actual work against the bug item is being tracked in Github Issues (or Jira, etc). Whereby some property on the issue can be modified to indicate severity and impact (i.e. fixing this would close n customer tickets of which the highest severity is x), so that something is gluing together the disparate systems that exist around a bug.
A bug tracker by itself... doesn't feel as valuable as the integration that enables the smooth management of a bug for all those who interact with it.
A mature bug system might even have complex routing rules, so that Zendesk automation can apply, if tagged as X, create an issue against this repo and link these two things together, and to even allow the moving of the downstream ticket between systems of differing types, i.e. "this ticket doesn't apply to this Github repo, move the ticket to Jira as it does apply to that other team".
Then as the master view of bugs and debt across the company (even spread across multiple repos, systems, issue trackers) a bug tracking tool now makes a lot of sense.
Does that make sense?
In any case, I don't think your problem is that you are missing features. It is that you are aiming for table stakes, and aren't showing us anything new and exciting.
If you want to truly change how teams operate and present us with a new model for managing and closing bugs, then you need to live up to your own description, move away from workflows and "my bugs" listed on pages, and show us something completely new.
You are right, we have limited features. That is because we are a small team and we want to have only the minimum features required for bug tracking (and not everything JIRA has). But, what we do intend is to go deep into this space and really question how we have all been building software and managing bugs.
The nudging people to move issues is indeed a culture thing. And the intention is to bring in culture building as part of the platform. This will reinforce and make resolving issues a much needed thing in our space.
The wrong culture is a bug, and maybe bugasura will help fix it. :)
Instead, aggregating information and making your bug tracker "clean" should help engineers knowing what's open and what's been fixed, and when doing a new release version, they should know exactly what has been fixed already.
While its important to fix these issues, I don't think it actually happens anywhere.
Another approach might be to 'carry over' the CRITICAL or HIGH issues only. This way, there is lesser carry over and the team won't be bogged down.
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.
EDIT: just tried it, still very basic, but already does the job for a small project. I'm considering contributing.
Edit: consider having a look at the development version. While the core feature hasn't changed much, the webUI definitely improved. Also, the core became more robust and ready to accept more features easily.
- is controlled by Google.
- doesn't support generics. Do we really want people to constantly rewrite basic data structure classes in 2021 and thereby reinvent bugs constantly (and waste time which could be spent on more meaningful purposes)?
If the people working for free to give me FOSS are happy with this stack, more power to them. No complaining.
"I only want to use it, I don't want to produce it"?
We shouldn't support bad things by giving them publicity through using them.
The least harm it will cause is disincentivizing someone else from creating something better, which is annoying enough already.
That's... bold.
- to then profit off by using them to train their AI which leaks into nobody-knows-how-many products.
So I think it's pretty fine to put them into the bucket of entities which benefit from forced labor.
They merely don't coax people into it by physical force but rather by locking them out of most of the Internet if they don't comply.
Or are you calling for developers to essentially put restrictive sanctions on any and all Google products/projects?
And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?
Because you seem to be demanding such a standard from the rest of us.
Yes.
> And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?
I intentionally enter a large percentage of invalid data into recaptchas to spoil their dataset.
Google Analytics is blocked by my ad blocker.
Same goes for ads on youtube.
With regards to using their stuff, I don't demand anyone should stop privately using it if they need it. You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.
So do a few others. You are easily selected out as anomalous data, just fyi.
> Google Analytics is blocked by my ad blocker.
Great. Are you also blocking Google Fonts? Are you sure that Google is not hosting anything you are touching on a website?
> Same goes for ads on youtube.
But advertisers pay YouTube based on the viewership reputation of YouTube. You are merely providing a reduced amount of value to Google in this way.
> You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.
Very honest question: Do you think you would have actually said this same thing about the C programming language in the 70s, 80s? Maybe you would have.
All in all, I am not sure that your stance justifies writing no code in Go which provides less value to Google's bottomline than even Google Fonts.
Perhaps some advertiser somewhere in the tech industry benefits from Google's public-facing Go packages proxy data for reaching a developer audience to sell to? Who knows? But, developers can turn that off and/or use self-hosted proxies.
Also, lone wolf retaliation is fine but not nearly as effective as just running for political office and being anti-Google.
This analogy makes no sense. You are comparing a product made through coercion and abuse of workers to a product willingly made with tools that you happen to have differing preferences on.
My point is that Google is an evil company, and we shouldn't support evil entities by using their stuff.
And to make that point apparent, I mentioned other instances where people would think it is pretty obvious that "producer is evil = don't use their stuff", hoping that you would see there is no reason to act any different on Google just because they produce products which are of a type different from those that evil entities normal produce.
Because it really doesn't matter whether it is software or clothes or diamonds, if you use something publicly of someone you support them, and Google should not be supported.
A malicious producer can taint their products solely by being the producer.
We should not use Go, Java, C#, Angular, React, Objective-C, Swift, Kotlin, Dart, .... ?
I merely know that specifically Google needs to be anti-trust'ed into shreds and pieces and then some more.
They control way too many parts of the public Internet, software and hardware.
Giving them even more control by letting their programming languages permeate the fabric of the software ecosystem is a bad idea.
Have you ever used a library where the company who paid the development went "whoops, not our product anymore! poof goes the paid team, website, the community forums, the knowledgebase" ?
Usually nobody continues to maintain these after 90% of the workforce behind them gets fired and the surrounding infrastructure disappears.
Software is almost worthless without the brains behind it.
> As for generics, they're just nothing more than a developer convenience,
So you propose people write the 100,000th implementation of linked lists, maps, etc. because what they want to stick into it is not class A but class B?
> Also they're planned in Go for next year.
The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.
It might have been nice as a toy to teach aspiring programmers. It shouldn't have ended up in production software.
> Damn, these are some stupid arguments.
Thanks. I consider yours as stupid too. How much progress exactly have we achieved with this wording now?
- slices and maps are already generic in Go
- Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners
- Go is a language, not a library
> The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.
It's not. Really.
I am not. I genuinely think Google is evil and should be dismantled.
> - slices and maps are already generic in Go
So people are supposed to not rewrite 2 of the possibly infinite types of data structures and classes, and constantly rewrite all the rest of them?
> - Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners
Enough other languages do as well.
> Go is a language, not a library
If Google abandons the funding it does not matter what it technically is. No money, no developers.
https://news.ycombinator.com/item?id=22833037
The ruby one ask to gem install, the python one to pip install, the one in bash assumes Unix, the one in perl tells you to "make install" (!), radicle wants to replace my entire stack.
As a Python dev, I don't want to ask my front end experts or worse, my testing team, to setup an entire python env just so they can fill tickets. I just want to donwload an executable, and then fill in my tickets.
gitbug gives us binaries. You just execute it, and you are good to go.
Maybe one day, Python devs will take the time to use nuitka to produce binaries for their users.
But it does make sense. Can be offline, will be redundant and fast (as its local).
Question is how many folks out there will be at home with this?
We really thought the platform nudges (compared to a PM following up) would make a difference...Why don't you want notifications?
E.G: HN doesn't push information on me. I can answer to you now because I know that at this very moment, I don't need to focus on something hard. But this afternoon, I will, and so I don't want to be disturbed and will just close this tab. Voilà, no distraction.
I don't need to be notified bugs: I don't work on them in real time. In the morning, I select the ones I will work on. New ones have little relevance to me until the next morning, which a dashboard will show me.
I need notifications on things like my clients calling me or my server failing. Those are the stuff that I need in real time.
The very first thing I do when registering with a new service, especially corporate/social ones is to go to the notification settings and disable everything but the direct message stuff.
Thanks for point this out, this will help us rethink 'nudges'.
That way my inbox stays clear but I can speed run through first thing to make sure I’ve not missed anything, I also ruthless cull anything unrelated to my work, so any notification a project I don’t work on gets deleted.
This reduces several thousand emails a month to about 6 I actually need to see in my inbox.
The default is insanity though I agree.
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.
What does overview of code changes mean?
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 )
The multi level comenting makes sense.
Should you dog-food the bugtracker - or while your bugtracker still have bugs, does dog-fooding risk losing info... ;)
You won't believe how much fun it is to log bugs of the bug tracker, into the bug tracker which has the bugs :))
But the what we need to get over is - how can we ever replace Github Issues. I mean, it is 'integrated' into github and will be a natural place for people to report issues. Like MS bundling IE or Google calendar adding Google Meet links into calendar invites automatically.
But, GitHub has really only sown up the issues part for developers, for everyone else it's a mess - so if your differentiator is building something that's useful to everyone _else_ on the project, you could be on to a winner. On our projects, the everyone else typically outnumber the developers by about 3 to 1, sometimes even more. These are designers, project managers, client-side stakeholders etc. All of these people need to interact with an issue system, all of them need to be able to track progress, all of them need visibility on how a project is going.
Jira will tell you that that's what they do, but of course it isn't, Jira is a crime against humanity.
Github does seem to have a marketplace that we could get into. Maybe something we can explore.
Sync is simple to sort out.
We were thinking of two kinds of projects 1. Private - for the internal dev teams to work on 2. Public - for external folks like end users to work with internal teams
Now I see another one which is CLIENTS only - for a restricted set of external users.
Thought: Make a free marketplace extension that allows a one-click "configure this user's subscriptions to different event types to make it into an issues-only user from that user's POV".
Both useful and if done right would hopefully be much more of a way to get people to engage with your product/brand than it would be "enabling a competitor" (I think ... or at least: I'm not trying to convince you to do something against your own interests for my own gain here, but that does not at all mean I'm not completely wrong ;)
Githib issues was the nearest, but it was linked to repos and it didn't make sense for us to create repos just to use bug tracking.
Our current product has only private projects, but we are going to be bringing out public projects to get feedback from end users (similar to github issues).
This is to infact help us manage our user/customer feedback and issues.
This has always annoyed me about existing open source alternatives to Jira. I actually like ticket numbers with a project slug, because they add far more context. A five-digit number is far less readable than ABC-123, because you know it associates with project ABC.
Would something like the ability to optionally have slugs, but still a single numeric namespace be a good compromise for you?
For example: FOO-123 takes you to the same issue page as BAR-123 (everything before the number is ignored when actually routing the web interface), but when seeing internal references in the tracker, a per-component slug is prepended if configured (eg. the infra component could be configured to always refer to its issues as INFRA-nnn). This would let issues be moved around components while a maintaining a greppable, constant ID, but for users to use slugs if that helps them.
One of the problems with flat-namespace numbers is that the numbers are so long that eyes start to glaze over them. A three-digit number is pretty easy to tell apart from another just from the "shape" (if that makes sense) of the digits, wherease this "shape" is completely obscured once the counter exceeds 4 digits.
Ideally, a system like this would just have a toggle to configure whether one wants to use a flat namespace (with or without slugs), or multiple namespaces with slugs. It's not that difficult from a technical perspective, since the primary key for the ticket will be some internal linear number anyway, and the separate namespaced slugs are just human-oriented handles.
The single numerical namespace, from a technical perspective, is a double-edged sword. On one hand, you need to have a single, monotonically-increasing-ish number in your model, which is annoying when trying to design a globally distributed system. On the other hand, when users are (subconsciously) taught to not look that much into the actual numbers, there's opportunities to cheat, as an extra hundred here and a few missed numbers there won't be noticed but help with technical implementation details (you can pre-allocate number ranges, encode some technical details in the number, even just use snowflake ids, etc).
With namespaced 'small numbers', as you said, per-slug numbers will be scrutinized by users - if they file FOO-223 now and FOO-105 later, they will notice and they will be confused / surprised / unhappy. However, with per-namespace numbers you're at least given an opportunity to shard and have a less contested model.
Approaching this as optional handles is probably a good future extension and would fit in the existing model. I'll keep this in mind when I get back to developing bugless. Thanks for your input!
I'm probably a minority as I think I have pretty bad memory but as soon as your tickets hit double digits I am failing to remember which ticket is which. So I don't really care if it is 3 digits or 7 digits. If I am trying to remember I'll probably just look at the last 2 digits anyways.
Unlike bugless, it ain't open source but nevertheless, we should look deeper into your work, get inspired, borrow some stuff and pass on some credits to you.
What I want, for example, that would be difficult/impossible to achieve with git-bug's current distributed model (if I understand it correctly): per-issue/component authorization (secrecy!), ease of access to non-git users, history rewriting/sanitizing, built-in large attachment hosting, gigabytes of issue data and generally large scale deployments for large organizations.
-- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise.
-- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling.
-- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...).
-- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below.
-- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.
For history rewriting and sanitizing: I mean, someone posted something that needs to be removed before it's seen by a wider audience. I don't know, customer PII in the wrong component, abusive content (eg. dox) on a public tracker or internally by a disgruntled employee, server logs in an attachment that should be removed a year after having been posted (in accordance with a privacy policy), etc. I want to ensure that content can be nuked, and access to sensitive data revoked. This is also another reason why secrecy via e2e encryption in a fully decentralized system doesn't work for me: if a user's key gets compromised, all secret data that this user had access to is forever accessible to the attacker. With server-side access, it can be revoked, which helps if the data has not yet been downloaded. Plus you can keep an audit trail to detect any attempts at data exfiltration, while data exfiltrated by key compromise might never be detected.
* 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.
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:
As a product owner:Maybe next time, we will be in a better shape and can go on 'show hn' :)
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.
Fast is something we are striving to have in bugasura. One metric we are thinking of is - every page <100ms.
Would that make sense?
• 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.
[1] https://linear.app/
Thanks for the suggestions. Will definetly consider the hem.
What kind of tasks do you want to do from the CLI? Are you looking at logging bugs from your catch blocks?
Another question, what else would you like to see in linear?
This 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.
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...
Very useful pointers there.
1. Make sense, maybe add some CANNED FORMATS for steps to reproduce will make sense.
2. true, but its now a question of FIXED RESTRICTED WORKFLOWS vs FLEXIBLE WORKFLOWS (like trello)...
3. this is already there
4. yes
5. already available
6. we have added in a 'report/respond to bugs via email' feature that lets you email in the report. Couldn't get some of our team members to change their 'emailing bugs' habit
7. yes, agree
8. Absolutely true. There needs to be a PM who does remind them though, otherwise we will have stale bugs at the end of the sprint
9. A thought might be to group a set of bugs into a feature. Maybe that can be a feature of the bug tracker
11. This is our greatest blocker as of now. Every user wants a new field to track.
Would love to see this in a real product, so it can be used in project planning, code reviews etc.
We want to be 'A bug tracker'.
But yea, maybe a place to add estimates might make sense.
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.
What kind of integrations will help and why would you need those integrations?
Essentially I view integrations as a way to automating translating information between developer's focus and understanding of something, a product/project manager's understanding of it, a client's understanding of it, etc. I don't need to explain that a bug has progressed past PR and deployed to a test server if the product manger can see the story move from Development to QA on their view of a project. Also, as people are fallible, it means no one has to manually update the status of a story. Everyone is up to date by 'magic'.
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.
The bigger problem as we have more folks using it will be to KEEP it that simple.
Shopify has done a great job of keeping their initial platform clean and simple and moving all the 'advanced features' to plugins/apps.
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.
Progress bar - had never thought of a loader like this. Good suggestion.
Search - right now we are directly hitting the db, maybe we can look at redis/solr as read only mirror going forward.
Integrations - can you elaborate on this? How would integrations help?
Users then could for example ask, I have version 1.2.322, what bug fixes do I get if I upgrade to 1.2.435 (latest). With this information, you could answer that with a view in the bug tracker.
But some companies might use a different versioning or patching scheme. So the bug tracker would need to be general enough to support those different processes. The key is integrations.
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.
Offline, this is something a few people have been asking. It is a nightmare though with all its sync issues and conflicts :) But something we will look into.
Fast, definitely yes. We want a < 100ms for each load, everytime. Point taken about the gifs.
URL - yes. We did have that when creating a project, but we dropped it eventually. Might be a good idea to add it a the report or bug level.
Screenshot/Recorder - here is a secret - we are building something here for Android and Chrome that records your flow and you can directly report bugs from. Android app - https://play.google.com/store/apps/details?id=com.appachhi.b... Chrome ext - https://chrome.google.com/webstore/detail/bugasura/eheemiidl... Do have a look and let us know what you think.
Custom fields - this is a hard choice. We need to balance between flexibility and simplicity.
Slack - already integrated. You can get updates on your project on slack and in a few weeks respond back as well
Dream come true - we already have that. Its called Mult-Teams and you can be in different teams all on the same dashboard. The view is tailored for YOU and not the project/team.
Collapsed fieldsets based on roles are a potential solution.
> Its called Multi-Teams and you can be in different teams
The "you" is a problem, different clients have different emails and so I need to be logged in with different accounts.
Resizing and alignment also possible as we use a WYSIWYG editor.
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 la...