-
-
stale
Discontinued A GitHub App built with Probot that closes abandoned Issues and Pull Requests after a period of inactivity.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
IMO NixOS has the right stalebot settings[0]. It was discussed thouroughly in the RFC, as to choose the right information text and other actions by the bot. For example, the bot will only mark the issue/PR as stale and will never close the issue or lock it. Issues are only ever closed by humans.
The information text they came up with is quite a bit longer than the ansible one[1]. I think this is a very important point when adding such a bot, otherwise the user will be left helpless.
[0]: https://github.com/NixOS/rfcs/pull/51
[1]: https://github.com/NixOS/nixpkgs/pull/92254
> Thesis: Stalebot -- in dutiful service of current human resource constraints -- feels like it unthinkingly prioritizes discard of past contributors' time resources, over the mobilization of new human resources.
https://github.com/probot/stale/pull/107#issuecomment-379021...
I've had a beef with Stale since early on. It's a very old-world view of solving the problem of open source capacity. A better tool would instead try to find and encourage new resources (new contributors), whereas stalebot drives them away, and so kinda cuts the project off at the knees
It save cognitive and emotional resources of current contributors (in the short-term view), but driving future contributors away (in the long-term).
> Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like.
Agreed.
But GitHub is also slowly fixing this.
For example the "Discussions" feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions.
It's only available on a small subset of repos tho. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions.
I hope the Discussions feature becomes generally available soon.
I think it’s irresponsible to let bugs languish like this. The way I handle bug reports is to say “Hey, look, I just can’t fix this right now because I’m working full time and don’t know when I’ll be able to get around to fixing this without getting paid for my work.” E.g. https://github.com/samboy/MaraDNS/issues/84
I can see why a lot of people don’t do that: It’s a little rude, and there’s a small but significant chance it’ll become a flame war. I have only once had someone get rude in a ticket when I told them “That’s not a bug report, but a support issue”; I ended up deleting the ticket. GitHub also allows you to edit or delete other people’s comments in your tickets, as well as locking the conversation.
I submitted a PR to make a small improvement the libuv documentation... [0] and the stale bot wants to close it on me.
I think closing PRs as stale is particularly annoying.
[0] https://github.com/libuv/libuv/pull/3076