Bridges are a useful feature of git-bug, which allow synchronizing the internal state with an external issue management platform, such as GitHub issues. While bridges are useful as a tool for interopability, they distract from development of the core feature set.
Each bridge adds to the maintenance burden of git-bug: imagine a scenario in which a bridge exists for every other issue management platform - yikes! Instead, we could implement a system which looked for other binaries, such as git-bug-bridge-<name>, which implemented a common bridge interface maintained within git-bug. These other binaries could be maintained by the community, instead of adding the source code directly into git-bug.
Pros
Distributed workload for managing bridges
Reduced risk of introducing code into git-bug that goes stale (unmaintained)
Better ability to focus on core feature set instead of third party, sometimes proprietary integrations
Can you think of another benefit? Please add a comment below.
Cons
Installation might become more complex for users who want to use a bridge, because they'll need to find a bridge. We might maintain a central list of bridges, or support a sort of "plugin registry" to ease that effort.
Can you think of another con? Please add a comment below.
Technical design TBD; although I think the existing architecture is close to being able to support this; will aim to get a functional POC out in the next month or two
Do you have ideas or the beginnings of a plan for this? Is it the sort of thing that's likely to get any more traction than the current approach? My concern is that while I agree that this will improve separation and reduce maintenance burden on git-bug core, it would likely involve a significant interface/API design and reimplementation of the 4-5 existing bridges, which is a lot of initial up-front work that could take significant effort (especially on volunteer time).
(EDIT: To be clear, I'm in favour of the approach in general, aside from its potential effort/timeline)
Moving the discussion here in order to keep the conversation in one place.
I reasoned about this today, while combing through the backlog of issues and PRs from the past several years, so we're pretty early in the process, to be sure. Yes, it will take some time, but if the question is "should we focus on doing this", or "should we focus on implementing new bridges that comprise ~20-30% of the issues that have been opened over the past few years"... my answer is that this is what should be focused on, because it unlocks the ability for arbitrary bridge implementation, and frees up all of that time for improving the core feature set and making git-bug a viable project management tool.
I don't think this will require too much refactoring of the existing interface. Mostly, the design here will be around the communication between git-bug and $SOME_BRIDGE. As an initial design idea, one approach could be that bridges are manually configured in git configuration, e.g. git-bug.bridge.github.cmd = /usr/bin/git-bug-bridge-github, and on git-bug-bridge-* operations, the config option can be iterated through, calling each bridge CLI with a request that it processes to send/receive data from the upstream source. This would be functional, and not actually require too much refactoring -- bridges would just need to be turned into a CLI, but the interface could largely remain the same.
That's just a thought. There are other, perhaps more robust options, such as forking a background server on git-bug invocations and letting bridges self-register at runtime. I'm still mulling over what a POC looks like. If time permits, I should have something up in the next month or two.
Michael Muré (MichaelMure) commented
Imho, while the intention makes sense (I do agree on making the development more permission-less and disconnected from the core), actually splitting the bridges into separate binaries would be a massive effort, with little benefit. This is because the interfacing required between the bridges and git-bug core is massive:
All this is roughly 2/3 of git-bug core, and it's going to be close to impossible to reduce that ratio, because bridges by nature needs not only a wide range of features, but often more specialized than usual (for example, specifying a date of an event rather than using Now()). Please note: I've been trying to well define and reduce the APIs scopes, reduce coupling and so on already.
My advice would be to split the bridges into different codebase in the git-bug org (or elsewhere if someone wants to start it on its own). This gives you all the upsides you are looking for, yet requires very little work.
For importing the bridges, I'd simply statically import the bridges as go modules, but if you want something more configurable, you could have a list in a file where people could add/remove what they want, and a go:generate rule to generate the corresponding import.
In any case, I think it's really important to ship the quality bridges (github, gitlab, jira) by default. Git-bug should be a one stop binary that gives you the tool you need for your project. I don't see the point of shipping without those most important bridges.
it's really important to ship the quality bridges (github, gitlab, jira) by default.
That is a relevant point.
Also important is the single binary deployment with default bridges compiled in.
Can you think of another benefit?
Pros:
A plugin interface makes it easier to use git-bug in ways we did not anticipate. You could easily write a bridge-plugin that synchronizes git-bug with a TaskWarrior database or Google Calender, for example.
Also plugins can be implemented in any language you like.
[...] would be a massive effort, with little benefit.
This is because the interfacing required between the bridges and git-bug core is massive
That is true. Simply translating existing interface into an API would not bring much value. To make this thing rock, we'd have to export only the minimum needed for the bridges to operate.
If there's a good minimum, I am not sure. I would love to do some experiments, though.
Michael Muré (MichaelMure) commented 
Matthias Simon (5nord) commented