I think the biggest problem is always going to be the "Stakeholder" issue, and just about everyone else is touching on this too. Issue databases solve a number of different problems for a number of disparate roles of people. As much time as developers spend embedded in an issue tracker, you also have PMs, Managers, Executives, Clients, Customers, Testers, and sometimes a panoply (or even panopticon) of all sorts of other "stakeholders" with one reason or several to be in and out of an issue database scattered across a wide variety of technical acumen.
For anything more than a small team of only technical people, one or more systems of reporting (in either direction) becomes generally required. Can Clients or Customers submit new issues easily? Can PMs (or Managers or Executives) get the reports they need? Can Testers accept issues as completed or file new bugs on them?
There's so much more workflow than just the Developer side of things, for better and sometimes for a lot worse. (The "Jira Effect" where nearly every issue tracker eventually seems to succumb to becoming a super-configurable business workflow engine with a built-in CRM and a support desk ticketing system and a hideous kitchen sink with terrible load times.)
There's probably still a chance to find a really good sweet spot for distributed issue tracking that has just the right amount of bidirectional reporting to fill an average development team and their stakeholders' needs, but it's probably going to take a smart UX team to do it. A CLI-only approach seems unlikely to work, again just given the huge swath of technical acumen to be found with fingers in an issue tracking pie.
There's nothing that would stop you from putting a full blown jira-like UI which interacts with that database. Well... Apart from that UI not existing yet. But in theory, you can have both. With a centralised main head in the same way people use central repository for git.
in large non-tech companies i see a pattern where the company adopts standard open source tools arguably better suited to open source distributed development (many small git repos, github/gitlab) -- but then there can be pressure to present information for ease of central governance and control
at $current_job there's pressure for 100-200 people to use a single jira project so auditing and risk can be done via that one jira project, whereas at the same time there are an increasing number of git repos containing code for different systems (or ci/cd/build scriptery for different systems)
the jira project everyone is forced to use has about 100 different states a ticket can be in (many synonyms) and about 30 different custom relationships defined between pairs of tickets - so it is challenging to sanely encode or track the state of tickets (lowest-common-denominator meaning that it cannot be a fair approximation of the reality of an individual team's process) while also being absurdly slow.
i am not quite sure what my take away is but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this. a sufficiently entrenched bureaucracy can destroy the value of any technology...
I think it could actually prevent bureaucracy from destroying the value. They can have whatever reporting, enforced flows, business states, etc that live in the repo. You get all of that info locally - so you can create a minimal, lean interface for only the small part of it that matters to you. One of the problems I had with JIRA where I used it was that it grew into a monster, even though I only needed maybe 3 functions out of it. It could be simplified from my side, but... the API was not exposed because corporate rules and the number of requests that would require to enable, made it useless to try.
There are ways to solve those problems, but yes a good UX team needs to be brought to those problems, and I think that is a big issue. There's lots of little distributed bug trackers that stop at CLI, but few to none that have even attempted a UI, and I've yet to see even a proposal of a full workflow system with non-technical "stakeholders" in mind.
Again, all of that is theoretically possible. (We've got CRDT/OT-based collaboration apps all over the place today.) It's certainly not easy though.
But also, behind the times in one important way. GitHub has created an expectation that anyone in the world can open an issue against and collaborate with a project. That's incompatible with requiring Git push access to make changes to issues.
I created another project -- GitTorrent -- which also tried to increase the decentralization of software production, and this tension of collaboration benefitting from centralized spam fighting and access control mechanisms was there, too.
Hopefully one day there'll be magic spam fighting blockchain decentralized identity dust that makes everything work with p2p.
Joining mailing lists and configuring your SMTP client not to mangle patches seems like an art that everyone just decided to forget how to do.
(As an ex-maintainer of the Linux kernel I'm aware that they still do it there. Just.. mostly no-one else.)
If you aren't already familiar, you might dig Secure Scuttlebutt. Dat is also in a very similar space.
This is exactly right, and is one of the main reasons we still use GitHub for issue tracking. There's some internal Git + issues + npm registry infrastructure that some of us use, but it only works when other contributors are within your web of trust. It also depends on SSB working, which means that broken SSB installations can't report bugs (!).
The main implementation defaults to downloading content from people you follow and people that they follow, but this could (and should (in my opinion)) be increased once we've finished partial replication and off-chain content. I'd prefer to download a public message addressed that's 5 hops away over a private message from 4 hops away, but right now we don't have infrastructure to do that.
Potential friends that are connecting to the network for the first time and are experiencing bugs should probably have some public bug tracker that they can report to, but I'd imagine that once someone confirms your issue that it'd be moved from purgatory into the formal bug tracker.
Bias disclaimer: I'm very skeptical of GitHub-style issues, where anyone can add items to your todo list, and I'd really like to experiment with systems that require maintainer consent before an issue is hosted on the bug tracker.
Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy.
If an instance of the system is in use by many, debugging a problem experienced by a particular user might involve personally identifying information which should not be checked in with the source.
Also issue trackers sometimes deal with multiple branches of development. In a sane place you might have 4.8 and 4.9 in production and a 5.0-dev, fix a bug in 4.9, then port the fixes to the other branches. To do this you are thinking about the tree as a whole and that's easier done from outside rather than inside the tree.
IME it's best not to have non-technical people entering bugs, they should be submitting through email, a simple form, automated crash tracker or something along those lines. Most issue trackers will contain so many fields that will make zero sense for someone outside (or even inside) your organisation. They won't know the priority, the won't know the component, they can't find relevant logs to attach, they don't know the internal workflow, they aren't familiar enough to search for similar issues. And that's before you get to the corporate mandated fields, there's some on our issue tracker I don't know, I have no idea if something is capitalizable. Similarly I don't think I've ever put in a successful request to our internal desktop support system, I have no idea what their division of responsibilities are and somehow always select the wrong team.
I've become quite religious about creating issues on behalf of people when we get support requests or relevant lunch room chats, otherwise nothing makes it up their side of the corporate org chart and back down ours.
git-bug try to improve over the previous iteration of this idea in several ways. To answer your question, those are what I think prevented them to catch on:
- it doesn't pollute your project: no files are added alongside your code, no mess during a merge, bugs are stored in your repository but decoupled from your code workflow
- it doesn't impose an interface: as you prefer, you can use the CLI tools, the interactive terminal interface or even a webUI. You could also integrate it to your editor, CI system ...
- it allows outsider of the project, client, users ... to browse and open bugs, without asking them to install anything. Admittedly, git-bug is not there yet, but the goal is to have the webUI work as a public portal that a project could host easily, accepting authentication from outside system (github OAuth ...).
One benefit of that method was that it was truly linked with the code, no need for additional push/pull commands or hooks. This also meant that you could tell the state of a case on a given branch without having to look through commit/merge history - it would become closed on master alongside the code merge.
That was also its downside though, since a case could have different comments/status on master vs branches where they started, you had to actually check each branch to see if someone else had already begun or not. Not having a grand centralized view was that one's downfall.
I was originally interested in BugsEverywhere, but noticed that the website linked to a demo at http://bugs.bugseverywhere.org/ which was... not a demo. This gave me the impression that the project was completely dead, so I moved on.
Recently I've been looking at git-bug, which is similar, but I've been hesitant to use it because the readme talks about how it's alpha software and I'm not super excited about the demo web interface.
I'd be interested to hear what others think.
As for the alpha status, yes, the data model will likely change before becoming stable, but i suppose i have enough user to warrant a migration tool if that happen.
I feel this is directionally the same win as the offline capability of a VCS like Git itself. If we have it, we come to expect it. And if someone took it away for some reason, we'd have a better conception of just how useful it can be.