> I'm not sure that's a big issue really. The repository is just a database.

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...

> but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this

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.

I certainly think a UX is possible to make it work. I just don't think it is easy. You need a reporting tool that can potentially manage N repositories with M branches. You need to solve for issues that involve N sub J repositories ("epics"), and you need to solve for issues involved in M sub K branch states (in progress in A, complete in B, complete with extra bug fixes in C, X comments/documentation/attachments scattered across branches A, B, C, D, E, F).

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.

Just to show my homework that I've thought about some of these problems at least a bit more than just surface level, and as an interesting aside to anyone exploring the topic: Starting from UX/workflow as the end goal, at one point I was wondering if branch level issue information should be stored "purely" as CRDT/OT-style deltas accumulating append-log-only in place, and all UIs (including a CLI) building a gestalt from every branch to get individual issue state. Which is a lot harder to build than just "store a database in each branch, query the database as needed, UI is a basic CRUD app". That is, though, closer to the intuition of stakeholders that there's only "one" issue in a constant state of flux/collaboration, rather than one issue per branch (pending merges) per repository.

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.