A vision for the future of git-bug #1391

i don't see the idea that we have multiple entities within git-bug as a viable one

There is already two first-class entities: identity and bug. Further, #843 brings another one, and code review would be another.

but identities are not something users are explicitly interacting with. the fact that an identity exists is a side-effect of there needing to be an author for an issue. i'd argue that users don't care about identities. i'd call this an "internal entity" -- it definitely isn't the focus of git-bug from the user's perspective.

similarly, i don't envision that a good implementation of boards would require users to push/pull them independently from issues. i haven't deeply reviewed that PR, so i don't remember what the intended sync mechanism was.

There is exactly as much arguments to support (or not) code review as supporting issues in git-bug (if you ignore the name just a second): working offline, archiving, independence from platforms, data ownership ... I would personally love for that to happen.

sure, and believe me, i'm on board (pun intended, i guess) with contributing another change review/management platform to the FOSS space is a great idea, but this gets infinitely more complex than git-bug can currently support, and yeah, if we do indeed move in this direction, a project rename would be almost necessary.

when it really gets down to it, i'm not of the opinion that git-bug can currently position itself as a first-class issue management platform or issue tracker (we have a lot of work to do on the individual level, and more on the team/corporate level), and while with the DAG it is possible to support numerous different concepts and workflows, i think it would benefit us to really focus on one workflow (issues/bugs) and make it really solid.

Sending notifications has the exact same need for bugs as for code review, that doesn't differentiate them. Running a pipeline is indeed a very large project but (1) that's not a requirement to support code review and (2) that could be done by interfacing with another open source solution (which means it would run locally or on a server the exact same way).

while pipelines aren't a technical requirement for a code review platform, i think you'd struggle to find someone that wants to use some CR tool that doesn't support them :P

integrating with some other pipeline project is probably the approach i'd recommend, but this requires being able to send some webhook on push, which again necessitates that git-bug is either (1) running as the git server, which makes sense for the CR platform, or (2) the git server a user/team is using supports adding custom server-side hooks (something that cloud platforms just don't do).

Alright, let's agree that git UX is a mess.

i mean, fair :P but my point remains that it's primarily verb-driven. i'll circle back to my claim that git-bug, from a user's perspective, really only has one entity: the issues/bugs. the other entities are a side effect that the user doesn't operate on directly.

maybe this isn't true if/when we support code review -- but if we're planning to require users to run git bug bug push, git bug board push, git bug change-review push` to sync the status of these different entities independently from one another, i think that would result in a desire for improvement.

You bring good points from a UX perspective and it's worth pursuing, but none of that require a client/server architecture. For example, the webUI almost support operating on multiple repo at the same time (IIRC only some UI work is missing). You can track down in the code with NewMultiRepoCache().

You could implement all that by improving the UIs (which you'd need to do anyway) and a smarter locking.

yes, any number of clients could be refactored to implement those features, but delegating to a server simplifies the codebase.

    CLI              TUI           WEB
     |                |             |
      \               |            /
       \              |           /
        \             |          /
        +-------------+-------------+
        |           Server          |
        +-------------+-------------+
              /        |         \
             /         |          \
            /          |           \
     Repository   Repository     Repository

but identities are not something users are explicitly interacting with. the fact that an identity exists is a side-effect of there needing to be an author for an issue.

The usage might be light for now but it's bound to become more complex when keypair management is added. I suspect other things would come.

similarly, i don't envision that a good implementation of boards would require users to push/pull them independently from issues
but if we're planning to require users to run git bug bug push, git bug board push, git bug change-review push` to sync ...

All entities are already push/pulled all at once. It's orthogonal to the question at hand.

i think it would benefit us to really focus on one workflow (issues/bugs) and make it really solid.

That can be reasonable, but even if that's the focus, there is already two entities (identity, bug) and we'd likely want to add another one: some form of project config, for example to record user roles.

Those have vastly different verbs, and organizing the CLI with "verb operand" would make little sense.

The usage might be light for now but it's bound to become more complex when keypair management is added. I suspect other things would come.

for managing the keypair(s) associated with an identity, that won't be part of someone's daily workflow. again, that's an irregularly-typed-command to change "some configuration for my identity" from the user's perspective. i don't think this turns identities into something that users think of as a first-class citizen (whether or not it is within the application). as such, i don't think it lends much credence to the argument that the CLI should be entity-based.

i'm not sure what other things you're thinking of. i know that "boards" have come up -- addressing that, as you note:

All entities are already push/pulled all at once. It's orthogonal to the question at hand.

so users won't even be thinking of boards as first-class citizens.

please understand that i completely understand the concept of an entity, and that we have multiple entities within git-bug. what i am talking about, however, is that the "central entity", or "primary entity", is an issue -- this is what the user is using git-bug for. this is the thing they create, reference, discuss, and interact with. they don't (regularly) think about their identity once it has been created. keypairs won't change that.

That can be reasonable, but even if that's the focus, there is already two entities (identity, bug) and we'd likely want to add another one: some form of project config, for example to record user roles.

i hope the above clarifies what i'm talking about. i understand that we have internal entities with clear separation, but for the user, these are ancillary to an issue, and only exist because issues exist, and are not things that they need to interact with regularly.

i don't think git-bug should aim to become a change/review management platform -- that's well beyond the scope of "issue management", and IMO is best left to other tools that exist today (email, gerrit, reviewboard, etc?). this isn't just because i'm a diehard unix philosophy fan (and i'm not, really, i like systemd!), but rather because there are aspects of other things like

change review platforms that require a central authority

I don't think they do: case in point: email.
I think git-bug is in a great position to become the non-central code review tool

• sending notifications (arguably something the server could handle with background automatic fetching)

notifications for pull requests should be no different to pull requests for issues

• running pipelines (for small projects doing this locally might be okay, but this isn't scalable at the corporate level, and if it's local, users can bypass rules put in place; the story around secret management gets tricky; etc etc etc).

I see pipelines/CI as orthogonal: they are in essence a bot reviewer. To build out that ecosystem they should follow a similar flow as a user review:

• on a webhook or schedule: pull for new/updated PRs
• run the job
• post a status result similar to a user posting a comment on a PR

i could very well be wrong, but i think a larger part of the idea that we should support "pull requests" comes from users requesting this, which (from what i've seen) has mostly been for archival purposes. if that is correct, i'd direct those users to other tools, or in the case of archive-only workflows (which appears to be a common use case for people using git-bug today), teach them about ref namespaces and how platforms like github work with refs/pulls -- all PRs can already be archived!

if that isn't a correct assumption, i'd love to hear the reasoning behind that, and what you think about the concerns i'm raising here.

I don't think it is: it's coming from a "what do I replace github PRs with" perspective, because once you're using github PRs, you might as well use github issues.
I think people are looking for a decentralised solution to pull requests that doesn't involve email, and hopefully built into the push+pull flows of git itself.

I think people are looking for a decentralised solution to pull requests that doesn't involve email, and hopefully built into the push+pull flows of git itself.

Just as a note: I came here while searching how to combine git-bug and email... 🤷 like ... piping a email thread to git-bug for example.

For me it is really important that the commands are simple, natural and elegant, at least those commands that I will be typing a low of times like those three I gave aliases to.

i think this is one area of divergence with the current design (and the idea that its better) and my proposed approach. the current modus operandi for the design of the different clients is that usually, git-bug expects people to be using the TUI or WEB clients, and only use the CLI sometimes.

this is not my experience, or how i use git-bug today, and is at the root of my issue with the current CLI.

I only use git in the command line and I want to think about and use this tool as a natural extension of git, as if it was an integral part of git. I like termui and webui but I feel more comfortable using CLI directly for a lot of tasks, so that a natural and simple design in this matter is very important to me as a user.

if js is your jam, we'd love to see some contributions to the current web app.

issues tagged with area/ui/web are all still relevant, and a couple of those are fairly low-hanging fruit -- if you see something that strikes your interest, feel free to tackle it.

I'm not really seeing much in the way of planning or discussions around what would be the best to look at.

frankly: there isn't much. you'll find comments about larger aspirational things (like adding support for "PRs"), but those all require schema and API changes, and might not be the best "first issue" to tackle.

other things that come to mind are:

• updating dependencies to resolve npm audit warnings
• QOL things missing from the web interface, like improving the UI (wider?), settings for the table (e.g. show X bugs), keybinds to navigate through the UI
• removing dead links (the "this feature doesn't exist yet" stuff; that's been there for years and is imo extraneous noise, since we don't have a design plan for them)

there's nothing set in stone, really - these are all one-off ideas for (minor) adjustments to the current UI. if there's something you think is missing, or would like to see changed, PRs are always welcome :)

@lygaret HO YES PLEASE

Besides those points, I'd say:

• general UI/UX improvements, so much is clunky, plenty of ways to make it nicer
• add support for external OAuth, to turn the webUI from a personal portal to a public portal (that would be huge)
• add support for a kanban style board (see project board #843, the graphql is mostly ready IIRC)

Sweet, ok, I'll take a look around and see what I see!

I just found this project and was poking around. I see there's mention here of rewriting the webui out of JS, but was any specific alternative considered? Would something like go templ with htmx be a good candidate here? It would move the frontend to a server-rendered structure, but that seems like the direction you're alluding to if I'm understanding correctly. I'm interested in trying my hand at migrating one or two routes of the webui frontend to see how that goes. I'm looking for some guidance on what type of solution you're looking for before I get too far into it.

it's my understanding that the MPL-2.0 is not compatible with GPL-3.0, so i don't think we can use hashicorp/go-plugin (but yes, the design of the future bridge integration that i see as useful would follow this general pattern).

Pretty cool, and very nice to see this framework being used elsewhere!

@MichaelMure Honestly, once I got my head around it it was a moment of 🤯. I used it way back but I couldn't get wide adoption. I think that our new agentic world may become an excellent driver for this type of situation.

I'm going to see if I can experiment with getting kref to the point where an automated knowledge base can be kept that migrates around with the repo instead of being bound to user systems.

Many thanks to all of you for re-invigorating the project 🎉