There's https://github.com/MichaelMure/git-bug (I haven't tried it out yet, but looks very promising).

You are my hero today.

EDIT: just tried it, still very basic, but already does the job for a small project. I'm considering contributing.

Yes please :)

Edit: consider having a look at the development version. While the core feature hasn't changed much, the webUI definitely improved. Also, the core became more robust and ready to accept more features easily.

Working with it for some years already. Recently the UI part got much better, but the console part with or without bridge is good enough already.

Not very promising, it is written in a language which:

- is controlled by Google.

- doesn't support generics. Do we really want people to constantly rewrite basic data structure classes in 2021 and thereby reinvent bugs constantly (and waste time which could be spent on more meaningful purposes)?

Damn, these are some stupid arguments. Go is open source. Even if Google went rogue, there's nothing they could do. Go would just get forked by the community and that's it. As for generics, they're just nothing more than a developer convenience, they don't matter at all regarding what a product can do. Also they're planned in Go for next year.

> Go is open source. Even if Google went rogue, there's nothing they could do.

Have you ever used a library where the company who paid the development went "whoops, not our product anymore! poof goes the paid team, website, the community forums, the knowledgebase" ?

Usually nobody continues to maintain these after 90% of the workforce behind them gets fired and the surrounding infrastructure disappears.

Software is almost worthless without the brains behind it.

> As for generics, they're just nothing more than a developer convenience,

So you propose people write the 100,000th implementation of linked lists, maps, etc. because what they want to stick into it is not class A but class B?

> Also they're planned in Go for next year.

The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.

It might have been nice as a toy to teach aspiring programmers. It shouldn't have ended up in production software.

> Damn, these are some stupid arguments.

Thanks. I consider yours as stupid too. How much progress exactly have we achieved with this wording now?

It's pretty clear you're trolling now, but FWIW:

- slices and maps are already generic in Go

- Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners

- Go is a language, not a library

> The fact it took years to plan them instead of including them right away is a nice proof of how ill-conceived Go is as a language.

It's not. Really.

> It's pretty clear you're trolling now

I am not. I genuinely think Google is evil and should be dismantled.

> - slices and maps are already generic in Go

So people are supposed to not rewrite 2 of the possibly infinite types of data structures and classes, and constantly rewrite all the rest of them?

> - Go has great performance, great readability and write ability, and that's valuable for everyone, not just beginners

Enough other languages do as well.

> Go is a language, not a library

If Google abandons the funding it does not matter what it technically is. No money, no developers.

I don't care, I want to use it not dev in it.

If the people working for free to give me FOSS are happy with this stack, more power to them. No complaining.

> Do you use the same argument when purchasing consumer products from shady countries which abuse workers?

This analogy makes no sense. You are comparing a product made through coercion and abuse of workers to a product willingly made with tools that you happen to have differing preferences on.

My point is NOT that Go would be made primarily through forced labor (although usage of money earned through the yield of the forced labor from ReCaptcha is rather likely).

My point is that Google is an evil company, and we shouldn't support evil entities by using their stuff.

And to make that point apparent, I mentioned other instances where people would think it is pretty obvious that "producer is evil = don't use their stuff", hoping that you would see there is no reason to act any different on Google just because they produce products which are of a type different from those that evil entities normal produce.

Because it really doesn't matter whether it is software or clothes or diamonds, if you use something publicly of someone you support them, and Google should not be supported.

Comparing people taste in language with slavery.

That's... bold.

Very valid points about recaptchas. Now, what does that have to do with the Go programming language that is FOSS?

Or are you calling for developers to essentially put restrictive sanctions on any and all Google products/projects?

And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?

Because you seem to be demanding such a standard from the rest of us.

> Or are you calling for developers to essentially put restrictive sanctions on any and all Google products/projects?

Yes.

> And if so, are you actually holding yourself to the same standard? Never using a recaptcha? Never visiting a site that uses Google Analytics? Never watching a YouTube video? Never using a device which runs the Android operating system? etc., etc.?

I intentionally enter a large percentage of invalid data into recaptchas to spoil their dataset.

Google Analytics is blocked by my ad blocker.

Same goes for ads on youtube.

With regards to using their stuff, I don't demand anyone should stop privately using it if they need it. You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.

> I intentionally enter a large percentage of invalid data into recaptchas to spoil their dataset.

So do a few others. You are easily selected out as anomalous data, just fyi.

> Google Analytics is blocked by my ad blocker.

Great. Are you also blocking Google Fonts? Are you sure that Google is not hosting anything you are touching on a website?

> Same goes for ads on youtube.

But advertisers pay YouTube based on the viewership reputation of YouTube. You are merely providing a reduced amount of value to Google in this way.

> You just shouldn't encourage any further people to use Google stuff by filling their ecosystem with more new software.

Very honest question: Do you think you would have actually said this same thing about the C programming language in the 70s, 80s? Maybe you would have.

All in all, I am not sure that your stance justifies writing no code in Go which provides less value to Google's bottomline than even Google Fonts.

Perhaps some advertiser somewhere in the tech industry benefits from Google's public-facing Go packages proxy data for reaching a developer audience to sell to? Who knows? But, developers can turn that off and/or use self-hosted proxies.

Also, lone wolf retaliation is fine but not nearly as effective as just running for political office and being anti-Google.

So anything made by tech controlled by a big corp is not promising?

We should not use Go, Java, C#, Angular, React, Objective-C, Swift, Kotlin, Dart, .... ?

This is such an oversimplification. Microsoft, Apple, Amazon, etc. are all guilty of ecosystem lock-in. Google in many ways is the most generous when it comes to open source and most of the hardware utilizing Google is by other manufacturers.

Neither of those criticisms pertain to the actual product itself. Go is a tried and tested product, used daily in critical infra and is FOSS

There is no moral component in a dev choosing a language for themself, what are you even talking about?

There is most certainly a religious component :p

You are absolutely right! And this is why I avoid any and all software written in C due to AT&Ts prior evil monopolistic practices of the mid-20th century. /s

For interest sake: what language carries your blessing instead?

There are a number of tools for distributed bug tracking:

https://news.ycombinator.com/item?id=22833037

Yes but all those tools share one common problem: they leak their implementation or want to do too much.

The ruby one ask to gem install, the python one to pip install, the one in bash assumes Unix, the one in perl tells you to "make install" (!), radicle wants to replace my entire stack.

As a Python dev, I don't want to ask my front end experts or worse, my testing team, to setup an entire python env just so they can fill tickets. I just want to donwload an executable, and then fill in my tickets.

gitbug gives us binaries. You just execute it, and you are good to go.

Maybe one day, Python devs will take the time to use nuitka to produce binaries for their users.

Since no one else said it, why not just use Fossil? It's precisely what you want already, and it's well made.

a git based bug tracker, thats a new one!

But it does make sense. Can be offline, will be redundant and fast (as its local).

Question is how many folks out there will be at home with this?

We really thought the platform nudges (compared to a PM following up) would make a difference...Why don't you want notifications?

Because as a dev, my attention is precious. To be productive, I prefer to pull information, than to be pushed information to.

E.G: HN doesn't push information on me. I can answer to you now because I know that at this very moment, I don't need to focus on something hard. But this afternoon, I will, and so I don't want to be disturbed and will just close this tab. Voilà, no distraction.

I don't need to be notified bugs: I don't work on them in real time. In the morning, I select the ones I will work on. New ones have little relevance to me until the next morning, which a dashboard will show me.

I need notifications on things like my clients calling me or my server failing. Those are the stuff that I need in real time.

The very first thing I do when registering with a new service, especially corporate/social ones is to go to the notification settings and disable everything but the direct message stuff.

I leave them enabled but email only, then I set up filters for each service to move it to */automated/jira directories automatically.

That way my inbox stays clear but I can speed run through first thing to make sure I’ve not missed anything, I also ruthless cull anything unrelated to my work, so any notification a project I don’t work on gets deleted.

This reduces several thousand emails a month to about 6 I actually need to see in my inbox.

The default is insanity though I agree.

Makes sense. The PM and the tester might want the devs to be notified, but as devs that does break our focus.

Thanks for point this out, this will help us rethink 'nudges'.