Hello, I know you're busy and this amazing project is already loaded with things to do. I am just wondering at the feasability of something I would like to do: import a JSON file into a freshly-cloned repo and populate a git-bug issue tracker with that data (which would be exported by git bug ls --format json). Sort of like a bridge, but with JSON instead of a specific git provider.
The background is that I've been having trouble with the bridges, both GitLab (I've tried the dev branch, still having issues), and GitHub (this one I should probably troubleshoot more).
Ultimately, what it comes down to is that I really like the git-bug interface, but my issues in dealing with the bridges led me to the realization that git-bug allows you to export the data as JSON. Because I use the issue tracker as a personal to-do list + notepad (and there are no other lightweight TUI programs (that I could find) that match the git-bug experience), if I was able to take that exported data and import it into a copy of the repo on another machine, then I would be able to use the awesome git-bug interface, with full portability, without any dependence on bridges which could break compatibility at any moment.
I hope this idea makes sense, and I hope it could be implemented without too much effort. :)
Thanks
Steve Moyer (smoyer64) commented
Maybe I'm missing something but I use git-bug on several machines and just use git bug push and git bug pull. The main problem with this technique is that you need to create the identity on only one machine and copy it to the other machines. Ultimately, you're also going to want one identity even across repositories too (like you have at GitHub.) Perhaps a DID?
Except for sharing between machines, I can envision other reasons for what amounts to a JSON bridge!
Nicholas Moen (arcanemachine) commented (edited)
Thanks for the reply. I've just been having issues getting any form of portability working (tried GitLab bridge (even with new dev branch), also tried git bug push/pull), which seem to be related to #1003. I got it working through a GitHub bridge, but I had to set up a repo just for the issues since the original repo is on GitLab.
I do think it would be nice to have a bridge using a protocol that won't break due to uncontrollable changes from external sources (e.g. API changes on third-party platforms), but I understand that this project doesn't have as many contributers as it deserves.
Steve Moyer (smoyer64) commented
I'll have to run some tests but this week is pretty busy. I'm thinking the process of using git-bug on the second machine is probably the critical step and I'll document it if I get it working.
Nicholas Moen (arcanemachine) commented
Well I got git bug push/pull working... Not sure what I did differently this time. I just created a new user, did a git bug pull, and everything worked as one would expect. Glad to have multiple backup options working!
I'm still using the dev build that I compiled myself FWIW.
Matěj Cepl (mcepl) commented (edited)
Maybe I'm missing something but I use git-bug on several machines and just use git bug push and git bug pull. The main problem with this technique is that you need to create the identity on only one machine and copy it to the other machines. Ultimately, you're also going to want one identity even across repositories too (like you have at GitHub.) Perhaps a DID?
JSON files are easier to back up, and also it adds robustness for the situations when git-bug is broken, and it is not possible to migrate from higher to lower version. Like right now.
github-actions (github-actions) commented
This bot triages untriaged issues and PRs according to the following rules:
After 90 days of inactivity, the lifecycle/stale label is applied
After 30 days of inactivity since lifecycle/stale was applied, the issue is closed
I hate this GitHub bot, and it seems hugely disrespectful to your users to use it.
Nicholas Moen (arcanemachine) commented (edited)
I hate this GitHub bot, and it seems hugely disrespectful to your users to use it.
Do you really think insulting the developer is going to encourage them to spend more time on this project? Nobody owes you anything.
Matěj Cepl (mcepl) commented (edited)
And do you think that openly ignoring and disrespecting collaborators on your project will encourage them to help you? Of course, there are probably so endless flocks of collaborators eager to contribute, that the owner of the project doesn’t want anybody else to help. I guess.
There is absolutely no reason for this bot to ever exist. Its only purpose is to hide existing bugs and pretend that the project is in much better shape than it actually is. There is zero cost of having open bugs, we have plenty of integers for new ones, maintainer just wants to show that he/she doesn’t care about their users, and it is more important for them to look like there are no problems than to actually help their users or even to encourage them to help each other.
I hate this GitHub bot, and it seems hugely disrespectful to your users to use it.
...
There is absolutely no reason for this bot to ever exist. Its only purpose is to hide existing bugs and pretend that the project is in much better shape than it actually is. There is zero cost of having open bugs, we have plenty of integers for new ones, maintainer just wants to show that he/she doesn’t care about their users, and it is more important for them to look like there are no problems than to actually help their users or even to encourage them to help each other.
i added the configuration for the stale bot.
this bot is not closing issues. it's more of a "heads up", pay attention to this". the initial configuration was set to automatically close issues, but this was quickly adjusted due to user feedback (i think within 24 hours, but this number is just off the top of my head).
as an example of how it's helpful:
i vaguely recall seeing this title, likely from skimming through the issues a few months ago to see if i wanted to pull anything else into 0.8.1, but the email i got tonight because the bot commented and rotated it brought it directly to my attention - and if i didn't get an email, that'd be fine too - because for planning purposes, being able to search label:lifecycle/stale or label:lifecycle/rotten to see if anything has fallen through the cracks is incredibly helpful.
other, larger projects with corporate backing and larger teams often use issue inactivity to close or even lock issues using stale bot or something else. for them, that can be helpful to reduce the "infinite backlog" that an accumulate -- and that's something that applies to this project, too.
i can only assume that people who are adamantly against this sort of automation have experienced what they perceive as unjust closure of issues they've opened or have an interest in, and that absolutely isn't something that a) will happen, because the bot does not close issues, and b) we will ever intend to do.
as someone with busy personal and professional lives, and without infinite time to dedicate to deeply investigating each and every issue, it is very useful to have this bot, which i treat (at the moment) as a sort of queue. it brings my attention to issues that need to be addressed and triaged. that's especially helpful in this project, because there are issues (like this one) that are several years old, with long threads, and potentially some feature work that has been done. it can take a while to really gain the full context of an issue, and getting batches of 3-4 at a time feels like a manageable way to approach it.
i care very deeply about making git-bug more accessible, error-free, and (maybe, possibly, hopefully) a source of truth for not only people who want to use git-bug, but other issue management platforms as well. that's the future i wish to build, in a nutshell. the statements you've made about the stance of maintainers that implement a stale bot are just plain wrong, at least in this case (and i'd wager, in the bulk of others, as well).
(later) He is not dead yet!
i see absolutely no reason to remove the stale bot configuration: it does not close issues, it simply applies labels to them, which helps the maintainers (or at least, me) figure out where to put my attention the next time i'm looking through issues.
@arcanemachine, to address the original issue comment/feature suggestion, i think @smoyer64 addressed this, but just to weigh in:
git-bug is of the mindset that it, and its issues, are the source of truth. when you pull from a bridge, git-bug creates its own issues, because that's what it shows when you list issues with git-bug's CLI or TUI/WUI client. when you push to a bridge, you're taking the local git-bug issues and doing the inverse: "copying" (or editing) them out to the remote service provider.
to accomplish your goal - getting issues on a new machine - all you need to do is have pushed the issues up to the git remote, and pull those on the local machine. as you indicated in another follow-up comment, yes, currently, the first thing you should do on a secondary machine is adopt your pre-existing identity from the git remote. at the moment, this workflow needs some work, and that's on my plate for an 0.8.x-ish release (there is no timeline i can give you at the moment). i've left comments on https://github.com/git-bug/git-bug/issues/1003 with instructions for how to manually fetch the identity with both the old 0.8.0 release, or if you're building at HEAD (or with the soon-to-come 0.8.1 release) -- it does differ slightly because of changes to git-bug's commands.
i'm not sure i understand your statement here. if the issues exist on any remote (remember, git is a distributed version control system), git-bug could be broken, uninstalled, unavailable to build (including all prior releases), and you could still fetch and push your issues. additionally, if git-bug were broken in two different releases and you were blocked, i'm not sure how a JSON export would help. can you clarify this?
sudoforge
removed label
lifecycle/rotten
sudoforge
added label
kind/feature
sudoforge
added label
triage/needs-priority
sudoforge
added label
triage/needs-information
sudoforge
added label
triage/needs-approval
sudoforge
added label
area/serialization
sudoforge commented (edited)
i thought of a use case i wasn't thinking of earlier: bulk issue creation.
other than importing issues from a third party source (bridge), we don't currently have a way to create issues en masse (without requiring the user to for f in $FILES; do git bug new --file "$f"; done, but we could make it more ergonomic for sure). i'm not sure i think JSON is the right data format for doing this, but i can totally see the need for a bulk import, and since we export JSON, importing it makes sense.
sudoforge
removed label
triage/needs-priority
sudoforge
removed label
triage/needs-information
sudoforge
added label
lifecycle/frozen
sudoforge
added label
priority/backlog
sudoforge
removed label
triage/needs-approval
sudoforge
added label
triage/accepted
Matěj Cepl (mcepl) commented
Just to the issue of the stale bot (and I don’t think we need to elaborate on this further): the only good solution of overloading issue trackers in my opinion is fierce and immediate triage on incoming issue reports. Anything else leads to discarding valuable user experience, or to the death of issue trackers, as described in my other comment.
sudoforge commented (edited)
@mcepl, the bot (rather, the pipeline that does this) is staying.
git-bug is an open source, volunteer-driven project. "volunteer", in this context, means that people are donating their time (sometimes very limited due to other responsibilities), for free, in order to drive a project forward.
things will slip through the cracks. the bot helps prevent this.
you are making statements like this:
the only good solution of overloading issue trackers in my opinion is fierce and immediate triage on incoming issue reports
while not recognizing the fact that without the ability to dedicate one's full attention on a project, this is not possible, especially so in one with a large community and limited maintainers.
i have stated multiple times, as does the bot itself, that it does not close issues. the video you've linked to clearly focuses on automatic closure of issues being the problem, not automatic labeling and commenting (which notifies the maintainers).
to summarize your involvement in this thread:
you aren't offering help
you don't seem to comprehend, or at least have not acknowledged, that maintainers (at least, on this project) are real people with jobs, lives, and still donate their time for free in order to push a project they're passionate about forward
you continue to shift the conversation away from what the original poster needed, and have done so on multiple occasions
you are positioning yourself as an authority without context - as in, "let me tell you how you should run your project"
Steve Moyer (smoyer64) commented 
Matěj Cepl (mcepl) commented (edited)
github-actions (github-actions) commented 
Michael Muré (MichaelMure) commented