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)?
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?
> 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.
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.
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.
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.
- 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.
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. :)
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?
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.
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.
* 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.
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.
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 ;)
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
So, I'm just going to dump some things that bother me about JIRA and other options, mainly from an Ops person perspective.
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".
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.
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.
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 ;-)
Please make it as ugly as Bugzilla so the project mangler types don't spend all day trawling through it and reprioritizing bugs we've already started working on.
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!
> More seriously, how about multiple sets of priorities? And a way to reconcile them
This is a really interesting idea. I'm thinking something like Trello where each list is different teams priorities. Teams assign weight to each priority, and you also weight the relationship between the different teams and what the business wants to focus on as a whole. Then when the planning stages are done, you can hit "Reconcile/Generate roadmap" or something, and get a somewhat balanced and shared view of what's to be done.
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.
Something I haven't seen yet: good control over the emails I receive. It is 14:45 local time, and I have 86 emails in my bug tracker folder. Also in this area is approaching the emails the issue tracker sends from the perspective of "how would I make a rule for emails like this?".
A good scripting/automation api would be nice. Being able to make my editor perform certain issue updates makes my life easier.
How about thinking through how bias in algorithms should be tested, discovered, and fixed and building that in? Some types of testing might be statistical for example, and involve trying software on a large group of people with a variety of backgrounds. The bugtracker could be designed to be integrated with those testing and discovery methods. How to fix such bugs may not be clear, and normal methods of who to assign them to might not work (perhaps some have to be assigned to teams or outside parties?) In general a bugtracker that integrates with all the tools used in development, testing, and fixing would be more efficient and useful. Automatic import of statistics and graphs, maybe built in running of test code to reproduce the bug for the developer who has to fix it, some indication of the impact of each bug in terms of audience (which customers does it affect? What is the public relations impact if it is not fixed and causes problems later? How might it affect sales?) Seems like an integrated system could explore a lot of new possibilities.
Please make sure it has federation features built in.
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.
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).
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'.
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 )
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.
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 :)
Is there a software platform that more accurately tracks how software is actually developed?
(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.
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.
I think you should keep it simple but flexible. For example I loathe Jira because their model doesn't mesh with how I work at all. I end up trying to map my processes into their tool mostly for reporting.
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.
Flexibility is what made Jira into the monster it is! Jira can model any workflow so that any company can purchase it. If you are running into problems because transitioning issue types loses fields, why not make all types have the same fields? or have only one type? In a lot of teams, the answer is - “because that’s what the person who configured Jira made it do”.
And fulfilling laundry lists of feature requests will turn your system into a Jira - can do anything if you have someone whose job it is to configure it. Which is fine if you want to be another Jira, but that might be a tougher challenge than being an opinionated alternative.
I think Jira is flexible on a different axis than what I was trying to convey.
I want it to be flexible to the end user. Jira is about flexibility in how you restrict the end user.
I think this means that it won't require much flexibility as the users can do a lot of what they want, leaving teams to organize themselves with the workflows that work for them.
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.
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 landing page, sorry. And if you didn't mean to insult anyone then the word "modern" still has no meaning.
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' :)
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.