[jaworek]

Summary

Inspired by blog post linked below, I would like to propose removing stale bot from the project.
I'll quickly summarise points mentioned there:

• opened issue should not make maintainer feel obligated to respond, implement, or fix any feature/bug
• issues are a place for discussion and a way for community to find solutions to problems that they encounter
• it serves as a place to record additional information, workaround, opportunity for other developers to create a PR in the future

https://drewdevault.com/2021/10/26/stalebot.html

I'm aware that we also have a "Discussions" enabled for this reason, but it seems as it is not uses as often as "Issues" tab.

Test plan

Verify that merge and build pipeline is working correctly.

[github-actions]

The mobile version of example app from this branch is ready! You can see it here

.

[BartoszKlonowski]

In my opinion it's always good, polite, professional to respond to an issue, in any kind of a response, whether it's adding a label, or writing a comment.
I'm trying to send responses in Slider when there's a new issue, or at least apply a label.
I believe that it let's the reporting user know he's not completely ignored.
That's why I only partially agree with the linked article.

I do, however, believe that an issue is also a place to discuss things, share solutions, not only to complain about bugs and blame the owner/owners.

So I think that it's best to let the author close it when he/she gets the answer or decide that issue can/should be closed.
I wouldn't like to have my issue closed only due to a given time of inactivity, especially when it's an automated bot, not a human who closes it just like that.

[mikehardy]

Interesting! I just saw this as I was fishing for a PR I need to complete for react-native-paper and as a maintainer of a lot of repos I had to check this and the linked post.

I think it's a false premise:

There is no shame in having a lot of open issues

Stale bot for me at least, in my repos, is not motivated by shame. It's motivated because the issues list in a well-maintained repo actually carries a lot of signal. An open issue is something on my list of things I'm actually going to work on or am interested in collaborating on. It's an actual todo list. An open issue signals to the users that this issue is real and is accepted for work if someone wants to post a PR.

A closed issue means "not actionable", that's really valuable for users to know.

There is not a single thing stopping users from continuing to collaborate on closed issues and that happens all the time.

Conversely a policy of auto-locking closed issues, I consider that harmful personally and only lock when conversation quality is extremely poor.

Not that anyone asked me here, but that's a really important point to make. Ignoring the signaling value of an issue's open/closed state and/or ignoring possible utility of an issues list as an actual todo list makes the stale bot a strawman and of course it seems silly then.

[satya164]

• opened issue should not make maintainer feel obligated to respond, implement, or fix any feature/bug
• issues are a place for discussion and a way for community to find solutions to problems that they encounter
• it serves as a place to record additional information, workaround, opportunity for other developers to create a PR in the future

I think the last 2 points don't really depend on the issue being open or closed, and usually, the bot will only close issues without a repro anyway.

Regarding the first point, while it shouldn't in an ideal scenario, that's not the case:

• having a lot of issues open makes it harder to focus and manage them, like having a lot of items in your todo list.
• people (and tools) count the number of open issues in a repo to determine the quality

Basically agree with @mikehardy

[Doberjohn]

We're keeping the stale bot: it only acts on issues and PRs labelled needs more info or needs repro, so it only closes items that are waiting on the reporter, and it has been kept up to date since (most recently in #4884). This PR now targets 5.0, where scheduled workflows don't run, so it couldn't take effect anyway. Closing as declined. If you'd like to revisit the policy for 6.x, please open an issue or a Discussion.