alt Hacker NewsWhile I like the idea of tool consolidation, bug trackers aren't just a tool for the engineers. At most companies I've worked at, the support team, designers, QA team, managers, etc. all use the bug tracker on a daily basis.
It sounds like you can "bridge" to somehow show the tracker outside Engineering, but then you're having to do work around the consolidation, and I'd imagine the result won't be as nice as a full-featured tracker designed for everyone to use.
But, I am curious to hear from someone who has actually used this thing.
Replies
hey! maintainer here.
git-bug has a web ui that you can run on your git server, for example, that can be accessed through a browser.
it's fairly limited in functionality right now (create, comment on, and manage issues), but one of my goals is to refactor it to improve coverage of the existing features, and to add support for things like:
- authenticated access
- unauthenticated/anonymous access (e.g. a public, external contributor/user)
- issue privacy levels
- sprints, projects, report generation
Improved user interfaces can always be added on top of the CLI/library functionality, and that’s the more flexible approach. Everyone can use and/or build their favorite UI, like people do with Git itself.
The monolithic web-first (often web-only) systems are a bit of a modern bane, you’re stuck with whatever user interface the one company/maintainer deems appropriate.
All those users are why bug trackers are annoying. I don't care about those fields "those other people" are demanding, why do I need to fill them out. Mean while they don't care about the fields that are critical for me and don't want to fill them out.
This is a bug tracker. What you are describing is much closer to a project management tool, just to make the difference clear.
I think that is more useful for communities whose members don't have reliable, always-on networks, rather than workflows within companies.
Designers, QA, support and managers are typically already using a VCS, and usually it's Git. And if they don't, this is as good as ever a chance to start.
From QA perspective, which is the one the closest to me: I wanted such a tool for many years, and even though I haven't tried this specific one, I endorse the idea with both of my hands.
In the context of QA, it's always a problem to coordinate between test development, feature development, feature description, and tracking the work progress. All bug trackers I used to date are awful at it. This has a potential to solve at least part of the problem by being physically connected to the work done by either development or QA, or, ideally, both. The holy grail here is the ability to determine what tests to run in response to a commit without making it too much of a burden on the committer.
Tests can easily be the most expensive ongoing activity a development company may undertake. In this context, being able to avoid running useless but expensive tests is very desirable.
Maybe the tool isn't intended for use in commercial environments. There is plenty of work done outside a those environments where this tool might be a better fit. E.g. most free software projects don't have all those other teams interacting with the bug trackers. To put it another way, this seems to fill a similar niche as Github's bug tracker and not Jira.
P.S. The GitHub readme for this project desperately needs a "Why?" (... would anyone use it, ie. what benefits does it offer vs. say Jira?)
Fossil[0] has bug tracking as a standard feature, and through the HTTP role-based authentication, you are able to set up users with different privileges; for instance, being able to read and write the bug tracker without the ability to push new code.
[0]: https://fossil-scm.org/home/doc/trunk/www/index.wiki