I really like that Issues / PR are centralised. The last thing I want is merge conflicts with issue comments... just the thought of that is horrible...
I agree, I wouldn't want to have merge conflicts in issues/PRs either, but I don't think just because it's decentralized, means that it would have conflicts. A quick thought would be to have issues/PRs only editable by the author via signing for example. Not allow any edits and just modifications on top of other modifications.
Is there a reason you prefer centralization that is not about conflicts?
If issue tracking was decentralized, you don't know if everyone else sees the same thing as you do. With Github there's a chance that they are down ("degraded service" as they call it), but if it works, you press refresh, and you know you're on the same page as everyone else.
Yeah, true that it could be an obstacle. I wonder if the UX of any application for this could solve that by showing indicators of when the last data was fetched/sent, so users could know about possible stale-content.
I guess the problem of "everyone else sees the same thing as you do" is also a part of Git, where everyone keeps their own copy + a link to upstream. Seems to work well, wonder if we could possibly do the same with issues/PRs.
There is also a project (probably many) for managing patches and/or issues in a git repository, but I can't find any links to it right now (can't access my github stars...)
Edit: there is also a alternative to git that has much of the same functionality of github embedded in the SCM itself, Fossil. https://www.fossil-scm.org
Edit2: GitHub back, think the project I was thinking about above was https://github.com/MichaelMure/git-bug which describes itself as "Distributed bug tracker embedded in git"
The nice thing about BE compared to the more recent ones, is that it's VCS agnostic - it's just files in the repo, rather than e.g. using some special metadata feature of git/etc to track the issues.
I've yet to see a web UI for it tough (to expose it to non-technical users).
> Unless most of us are stupid enough to use GitHub issues and PRs instead of having that data in the repository itself.
When I looked into this years ago, I couldn't find any good tools for using the repository itself as the data storage layer for bug tracking, PRs, etc. So (at least then) Github was the best option.
Also, you can init/clone and host a repo on pretty much any system with SSH access for multiple users. That was my internal goto before git was more common for internal dev.
