Awesome for personal projects or those startups with teams composed primarily of developers. But I wonder if the nature of embedding the bug reports in the repo makes it largely inaccessible to your typical QA and support personnel who tend to open the most tickets at larger organizations?
There are two sets of people who want to track programmer tasks, and they're quite different already.
The most successful company I worked for used two systems. There was an "external" user-friendly one, where customers could file issues and track changes and tie them back to contractual requirements and such, and there was an "internal" developer-friendly one, where programmers could talk about what line of the source code forgot to add one and which changeset hash introduced the bug.
Our partners wanted to file issues at the level of "I need to have some way to be able to do XYZ", and they shouldn't have visibility into source code and programmer assignments and internal roadmaps. Our programmers broke these into "Write a function to do X()" and "Add a database table for Y" and "Z.c crashes when you leave the title field blank", and they shouldn't be exposed to customer data that was part of the request.
It worked tremendously well, and I'm surprised this split approach isn't more popular. git-bug looks like it could be a great solution for the internal one.
IBM's old PMR system was their front-end, and they used CMVC as the back-end until it got replaced [1]. The two combined did what you described, and was the earliest example I know of as a commercial offering of version control tightly bound to bug reports. Very satisfying to see this concept get more traction with git and various bug trackers. I wish a public open interchange standard would evolve so the different integration combinations wouldn't be so brittle, though.
The web UI is designed to, in the future, be used as a public interface as well. It would need to have some kind of authentication to identify users though.
The population you desire to be able to update tickets is... shall we say, "larger" ? ;) than the population you desire to be able to update code.
For any project where the bug-updaters and the code-updaters are plausibly the same set, this could be a useful thing.
But even for modest projects I'm doing for customers, it'd be awkward.
I also think the type of data your bug-updaters or bug-reporters would generate would be very different. Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
My kneejerk is that the bug metadata is a different _kind_ of data than the source, and trying to shoehorn them into the same container will be stuffy in most cases.
Each bug is stored independently and in particular independently of the source code, so older bugs could be archived or simply left on the git remote.
I don't see your point about the permission model.
You will have access permission for the code as you normally do for your git remote as well as an extra user for the web UI that will store bug edits as one of the "public" user with whatever external authentication system you want.
>Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
A really good point. I'd say you should use something like this for internal bug tracking, and link to external bug reports instead.
Whether you accept an external bug report as an actual bug is a question in itself, which should be dealt with beforehand. I'd say this is good for notetaking for the team and for seeing which bugs are resolved in which version.
> Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
There's a whole bunch of ways to handle large files in git nowadays without bloating the size of the repo. Hopefully the distributed bug tracker would work with those...
IMO It should be feasible to build data bridges for integrating or syncing with related systems.
That said, as a developer I'd love it if I could track my more technical thoughts & needs without having to go to my enterprise tools where BA's run wild & confused. The trade-off of course being more dissonance and potentially a failure to advocate for this work in planning, unless you synchronize data somehow.
