Hacker News Reader

Stalebot is awful. Issues don't stop being real if you neglect them!

Use a voting system or explicitly prioritize work instead.

> Issues don't stop being real if you neglect them!

Debatable.

Issues don't stop being real if someone out there runs into them and can't find a solution because the issue has been closed. Issues very much stop being real if the only person in the world who cares about them decides that they don't care or solves it themselves without sharing their wisdom. The former hurts the people whose problems are considered unimportant, while the latter hurts the developers of the project who now have an essentially dead issue in their tracker.

The solution? Close stale issues, but with the possibility of letting people say: "Hey, this is closed but is now relevant to me, so let's reopen it."

That way, there are never open issues that no one cares about, while the ones that someone starts caring about can be reopened, until they're either fixed or no one cares about them yet again.

That's how you get a 4 year old issue comment thread that looks like this

- stalebot: closed due to inactivity

- reporter: still an issue

- stalebot: reopened

- stalebot: closed due to inactivity

- reporter: still an issue

- stalebot: reopened

- stalebot: closed due to inactivity

- reporter: still an issue

- stalebot: reopened

- stalebot: closed due to inactivity

- reporter: still an issue

- stalebot: reopened

better than a list of stale issues?

In my eyes that's a good thing, it would immediately let you know that:

  - the problem persists and hasn't been solved to date
  - no one actually cares enough to solve it because the discussions just die out until someone runs into it
  - the problem is also unimportant enough for it not to warrant either a resolution, or getting closed by the devs as a "won't fix"

If i saw an issue like that, i'd just reconsider what i'm doing and would look for another technology/library for my needs. Essentially, seeing the above would just be a red flag.

Sometimes an issue gets fixed in a new release and nobody bothers to close the ticket, it may even go unnoticed altogether. Stalebot is just about the only way to get rid of that clutter. If the issue still applies, it can be reopened and maybe it will get some renewed attention.

Or you can just read through all your open issues once in a while?

It only becomes a problem if you leave so many issues untouched that that becomes a chore.

A big part of it is that GitHub Issues has essentially been the same product for the past like, 10 years, and even 10 years ago it was still seriously behind contemporary alternatives in a number of ways. The only reason people tolerate it is basically the social inertia, obviously. I bet if you ask any maintainer of a major GitHub project what pain points they have, Issues will be a top contender.

If you've ever worked on a project with 1,000+ issues, you'll know how big a difference small stuff makes when it comes to efficiency, especially for people who maintain the project. GH Issues really is lacking in so many ways, and as a result people come up with all kinds of crazy automation strategies to help make the issue database more "useful" to the developers, even if it's basically second class automation. Stalebot is one of these. The idea is really (at heart) that you just want to keep the open ticket count low because that's one of the simplest Signal-to-Noise ratios you can use as a search filter or mental criteria. If you have better tools (more powerful search, customized forms, powerful tagging, etc), this isn't true, but you have to play the hand you're dealt.

I don't think it's a good strategy, mind you. But I think understanding these recent trends as an effect of older, more fundamental causes is worth pointing out. This is all based on my experience, mind you. But it helps understand the thought process. And people see these tools being used on their big projects, so they kind of naturally gravitate (or at least try them) out of curiosity.

Two issue trackers that are substantially better than Issues are both Maniphest (Phabricator) and Trac, for curious people. Trac was a bit annoying to run and I think effectively unmaintained now, but as a bug tracker it's actually still really good. (It was also small and easy enough to hack that we were able to make modifications to fit our workflow, and maintain them for a long time.) I still miss both of them a lot every time I open a big project on GitHub and have to start searching for issues... Here's hoping "GitHub Issues 3.0" will get some things right and they won't wait another 10 years before doing major updates.

I'm happy to see news about RxDB. I really want them to do great but have the same concern with the inactivity of underlying tech. Both PouchDb and CouchDb have existed for ages and are such a great fit for modern web apps. They just lack the adoption and connection to newer frameworks.

An activily maintained SvelteKit/RxDB starterkit with built in auth might might get RxDB some new fans.

https://github.com/neonfuz/rxkit perhaps?

RxDB maintainer here.

I am aware of that problem. Pouchdb got some good love in the last weeks where some people made good PRs with fixes for the indexeddb adapter. But still it is mostly unmaintained and issues are just closed by the state bot instead of being fixed.

So in the last major RxDB release [1] I abstracted the underlaying pouchdb in a way that it can be swapped out for a different storage engine. This means you could in theory use RxDB directly on SQLite or indexeddb. In practice of course someone has to first create a working implementation of the RxStorage interface.

[1] https://github.com/pubkey/rxdb/blob/master/orga/releases/10....

> feet of engineering

Thanks for the chuckle.

Yeah, I can't believe they haven't switched to the metric system!

I use PouchDB. It works pretty well.