STOP Using Stale bot

[allanlaal]

all the arguments: https://blog.benwinding.com/github-stale-bots/

[cocokola]

Agreed. Moving along to where my time is better spent

[arvidn]

@allanlaal the arguments made in that blog post seem to be against the stale bot locking issues. I haven't seen github's stale bot lock any issues in this repository. If you have, please point me to it, there may be some configuration that can be changed.

[master255]

@arvidn Just turn that bot off. He' s shutting down problems that need to be solved.

[allanlaal]

@arvidn Stale bot also spams issues with offtopic messages, requiring offtopic messages for it to shut up for a while and post an offtopic event for that issue :|

example 1 of 400+:

#6690 (comment)

[arvidn]

@arvidn Stale bot also spams issues with offtopic messages, requiring offtopic messages for it to shut up for a while and post an offtopic event for that issue :|

Only on issues that you (and other people) care about. The majority of issues don't have this problem, they are closed.

The question is; does the value of closing issues that nobody cares about, and that may very well have been fixed outweigh the cost of keeping issues people care about open?

If you only see issues you care about, there's a risk you have a selection bias in your estimation.

[arvidn]

@arvidn Just turn that bot off. He' s shutting down problems that need to be solved.

Keeping issues open that have no champion doesn't help anyone as far as I can tell. It doesn't matter whether they need to be solved or not.

Problems aren't solved by keeping issues open, they're solved by people investigating them and submitting patches to test and fix them. Having people that can reproduce the issue and verify that it hasn't been fixed yet is a prerequisite.

[AllSeeingEyeTolledEweSew]

@arvidn but stalebot does lock threads. It will close an issue despite me (the author!) bumping it, and I can't reopen it once closed. Seems locked to me.

Its timeout is also too short. There's lots of stuff that should definitely be changed in libtorrent. It's hard to keep track of it all when stalebot closes all my issues. Yes, some issues persist for months, or even years, until someone can look at it. That's the FOSS game.

#6532 #6531 #6447 #6385 #6198 #5333 #5154

I recognize you get a lot of low-quality bug reports and stalebot helps filter them, but if it can't be configured in a better way, then I'm +1 for disabling it

[arvidn]

Seems locked to me.

I take it you don't have the "reopen" button available then, do you?
I do (but that might be because I own the project). I would have expected there being a message about it being locked, rather than just the normal "closed" message. I assume that if you close one of your tickets, you can still reopen it, right? Does it matter who closes the ticket?

Its timeout is also too short. There's lots of stuff that should definitely be changed in libtorrent. It's hard to keep track of it all when stalebot closes all my issues. Yes, some issues persist for months, or even years, until someone can look at it. That's the FOSS game.

The timeout should probably be increased. I think one problem is that the tickets here are not a great place to keep long-term todo-items. In fact, it's quite terrible, especially given all the noise. Most people that open tickets don't close them, even when they are resolved.

I suppose I could add a "todo" tag that disables stable bot. But that's still just items I think would be good to get to eventually, and I might change my mind down the road. In that case there still would need to be someone else championing it.

[arvidn]

#6858

[arvidn]

@allanlaal ticket #6690 is a perfect example of what stale-bot is for. That ticket should be closed. It was kind of a "drive-by" bug report, that probably isn't a bug. The champion of it didn't respond for months. In fact, I suspect the stale-bot flagging it brought it to the posters attention to respond to it. (which is a great feature).

[cocokola]

Disclaimer: I am a 30-year automation specialist for windows/active directory architect/Project/Program Manager who created Project Management Offices for fortune 100 companies. I script, I don't really develop full time, so take my opinion with the seasoning I provided..

From what I understand, locking an issue translates to the same thing that happens here, without activity issues expiring and falling off. The best thing that comes of this for real issues is you get issues created/closed/reopened/closed/reopened until it gets fixed or the poster gives up. Let me be clear, this is TOTALY YOUR CHOICE to keep it if you know the downsides and it will encourage users to NOT report issues and instead switch to another product if the issue is severe enough. Not world-ending per see.

Perhaps it is my lack of expertise, but closing issues that don't get attention seems at first to be a great way to eliminate work. But how many folks search for the problem, find an issue logged, and move on? The only way to capture that metric is to add upvotes so others can tag it so you know there ARE others that have the issue, but nothing to add unless you want all folks to comment Yeah ME TOO.. which is not the best way to add weight to issue tracking inho.

If you use issue tracking as a task list, then yes it can help eliminate workloads. It would be better to see if something is still in issue, if you cant reproduce it, the poster doesn't return (here is where having a ME TOO/Upvote/might help others to respond who are active and willing to help would help.. but I digress.

these articles/discussions capture the good/bad/ugly.
The article's points are valid Replace STALE/locking with Closing, re-read it and see.

Here are a few to read, digest, ignore and I guess close this if you disagree which is your prerogative.

https://news.ycombinator.com/item?id=28998374#:~:text=It%20unnecessarily%20invalidates%20the%20experience,something%20to%20your%20software%20project.

reddit post and related article: https://www.reddit.com/r/programming/comments/kzvryq/github_stale_bots_a_false_economy/
https://blog.benwinding.com/github-stale-bots/

related, and perhaps what is happening? probot/stale#343

thanks for your time!

[arvidn]

From what I understand, locking an issue translates to the same thing that happens here

It's still not obvious to me that issues are locked. did we establish that? Is it not possible to re-open an issue that has been closed by stale bot? I've definitely seen other users re-open issues, so I'm pretty sure that's not a privilege only I have.

Let me be clear, this is TOTALY YOUR CHOICE to keep it if you know the downsides and it will encourage users to NOT report issues

I don't see that. My experience right now is that people are eager to report issues, much more so than interested in helping out trying to pin-point what's failing. Obviously not all issues, but a material number of them.

closing issues that don't get attention seems at first to be a great way to eliminate work.

I think there's some disconnect here. The things that eliminate "work" are things like "day jobs", "spending time with family" and "sleeping".

In open source hobby projects, the limiting factor is the amount of work people are willing to put in. Nothing happens if nobody is willing to put in the work. That doesn't just go for engineers debugging and writing code; it also goes for people reporting issues, trouble shooting, experimenting and drilling down to what might be going wrong and under what conditions.

Bugs aren't fixed by tickets being left open. Closing tickets that nobody cares about avoids the important ones from drowning in noise. You really should see the noise.

Stale bot surfaces, and makes explicit, this reality; if not enough people care about an issue nothing will happen. It doesn't matter whether the ticket is open or closed. In that sense, it helps people understand how the process works.

It would be better to see if something is still in issue, if you cant reproduce it, the poster doesn't return (here is where having a ME TOO/Upvote/might help others to respond who are active and willing to help would help.. but I digress.

I agree with you that there are probably better tools than github issues for this, especially to gauge how impactful issues are. However, the important thing isn't necessarily to count the number of people experiencing an issue, but to find one of them that is willing to help fixing it. Without that, there's little point in working on the issue (assuming I can't reproduce it or understand the description enough to write a test that can).

I would love to have a uservoice-like voting system. Do you know of a free one?

related, and perhaps what is happening? probot/stale#343

I have been assuming stale-bot works as advertised and won't close tickets with activity. Reading that makes me think perhaps it does.

[AllSeeingEyeTolledEweSew]

There's also actions/stale#719, which echoes a lot of concerns here. The OP suggests stalebot should only act on issues with a needs-more-information label. That sounds better than what we have.

But given probot/stale#343, which has stung me (#5154, #6198), maybe stalebot isn't worth using at all. It seems broken.

[AllSeeingEyeTolledEweSew]

It's still not obvious to me that issues are locked. did we establish that? Is it not possible to re-open an issue that has been closed by stale bot? I've definitely seen other users re-open issues, so I'm pretty sure that's not a privilege only I have.

actions/stale#345 confirms it's known behavior that users can't reopen their own staled issues. Maybe only the OP can't reopen their own issue, if what you say is true.

[AllSeeingEyeTolledEweSew]

Also libtorrent's issue template is fairly bare bones and could probably be expanded to improve report quality. At the extreme end: https://github.com/pre-commit/pre-commit/blob/3cdc6c9d81149ab1f74b05c17743f988cb3af655/.github/ISSUE_TEMPLATE/bug.yaml requires users to submit the search terms they used for existing issues before submitting a new one!

[AllSeeingEyeTolledEweSew]

Also @arvidn, IMO, you should be more aggressive about closing poor-quality reports. I've followed a lot of issues where you clearly put in a lot of time translating vague explanations and/or foreign languages. I am amazed at your success rate at this, even when the OP gives no reproduction steps. But perhaps it's not the best use of your time.

[arvidn]

IMO, you should be more aggressive about closing poor-quality reports.

I was hoping stale-bot could do that for me.

[AllSeeingEyeTolledEweSew]

IMO, you should be more aggressive about closing poor-quality reports.

I was hoping stale-bot could do that for me.

stalebot doesn't prevent the time sink. I've seen a lot of examples of the following:

1. poor quality issue opened
2. you spend time figuring out what the OP means, and reply / ask clarification
3. OP never replies and stalebot closes the issue

What I think should happen, orthogonal to stalebot, is:

1. poor quality issue opened
2. you close the issue without spending time figuring out what OP means, and reply they can reopen if they add context / clarification / do google translate themselves / validate that the issue is really a libtorrent issue not an app issue / etc

[iopq]

One of the "Closed" issues is actually quite active:

#4936

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cocokola]

Guess we have an answer. 🤣

…

On Tue, Nov 22, 2022, 9:17 PM stale[bot] ***@***.***> wrote: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. — Reply to this email directly, view it on GitHub <#6797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACLTLQJCKE7FZRQLCSOUULDWJWEDNANCNFSM5S2GC7CA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arvidn]

One of the "Closed" issues is actually quite active:

#4936

That ticket is not active. Sure, people post comments on it, but none of it is driving any progress on the feature request.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soredake]

Not stale....

[calumapplepie]

H

One of the "Closed" issues is actually quite active:
#4936

That ticket is not active. Sure, people post comments on it, but none of it is driving any progress on the feature request.

A "closed" issue is one which will not experience any further comments. It's done, it's resolved. Maybe the resolution is "the report is unusable, we cannot debug further without user feedback, and the user is gone". Maybe it's "this feature is not and never will be a part of this project". Maybe it's "we fixed it". But under no circumstances should it be "I didn't notice".

I'm considering writing the feature mentioned; I think it would be a significant win for torrent swarms as a whole if more people were able and encouaged to conduct swarm merging. But I'm extremely hesitant to invest time and energy in improving the Libtorrent ecosystem if bugs I find which I lack the energy to resolve are closed.

Lastly off, here's another argument against stale bots. Don't worry, it's pretty quick.

https://fvsch.com/stale-bots

[arvidn]

I'm considering writing the feature mentioned; I think it would be a significant win for torrent swarms as a whole if more people were able and encouaged to conduct swarm merging.

That would be great. You can re-open the ticket to advance any discussion on the topic.

But I'm extremely hesitant to invest time and energy in improving the Libtorrent ecosystem if bugs I find which I lack the energy to resolve are closed.

What's so bad about being closed? It just means nobody is working on it right now.

[calumapplepie]

I'm considering writing the feature mentioned; I think it would be a significant win for torrent swarms as a whole if more people were able and encouaged to conduct swarm merging.

That would be great. You can re-open the ticket to advance any discussion on the topic.

Can I? What's with all the discussion above about issues being locked? And I'm fairly sure I've run into that myself, previously; though I do now see the ability to comment, so it's not impossible that I'm crazy.

But I'm extremely hesitant to invest time and energy in improving the Libtorrent ecosystem if bugs I find which I lack the energy to resolve are closed.

What's so bad about being closed? It just means nobody is working on it right now.

No. No it doesn't. Acording to the oxford english dictionary, closed in the relevant sense means:

To conclude, bring to a close or end; to finish, complete. to close one's days: to die.
And, indeed, the way most repositories use closing is that it is final. Re-opening something is a rarity; it messes with all kinds of DevOps flows, and really should only be done if you thought you fixed an issue, but actually didn't.

Closing an issue isn't putting it to sleep for a while, until someone comes along and fixes it. Closing it declares that it is dead; either solved, or unsolvable. If I'm trying to find an issue, Github will (correctly) hide all closed issues. Those are dead; they are gone. If I see that the feature request I want is closed, then I should just move on; clearly that feature is not desired, since the request for it was declared dead. I'm not a necromancer; I shouldn't raise an ancient skeleton that the community has moved on from.

That isn't your intended message, I know; that's why using stale bot is an issue. Many low-quality things do need to be closed; the way to do that is to review them, comment to request more information, and then tag it as needing more information. Stalebot can safely close stale issues with insufficent information; without the ability to reproduce, it can never be known to be fixed, so it needs to be killed eventually. But feature requests and high-quality bug reports? Closing them as stale is counterproductive.