ci: update stale bot to include only assigned

[wernerfred]

Description

feature idea (i'm fine if this gets rejected as well): include-only-assigned issues for stale bot workflow.

Instead of writing this myself i link to the comment that basically states my opinion: actions/stale#596 (comment)

Mainly I was just looking for a way to reduce spam'ish updates. For most of the projects I work with there's little point in the action/bot updating issues which aren't assigned (like this one). We would rather that it was more of a reminder to assignees that they've got something outstanding which they should be working on.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change that does improve existing functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[polarathene]

This is fine by me, we've been adding explicit stalebot-ignore labels to ensure some are safe from the bot.

I have seen a PR (regarding LDAP docs) get closed by the bot, but to be fair I don't think the contributor was planning to ever get back to my feedback, even though the contribution was probably worthwhile to get through.

Some issues also get closed, and I'm a bit on the fence about it. I think we have a higher ratio of issues that are user specific and difficult to reproduce, or the user never responds back. The issue may not resolved, but if enough time has passed, then it may not get resolved and after enough time passes, we may have had enough changes that someone should report a similar experience as a new issue.

As such, while I do find the bot typically annoying, it is doing it's job at letting anyone know that is subscribed that it's been a while and the issue will be closed if there's no further engagement. We don't have that many contributors, anything long-lived assigned to a maintainer just gets the stalebot-ignore label. I'm not sure if this setting will prove useful for this project.

---

Personal experience as a maintainer here would vote instead to increase the time until considered stale. That would seem more effective, 4 months seems appropriate?

I'm not against this change if others agree with it, so I'm approving. I don't see how it would be an improvement however (other than less notifications).

[casperklein]

As such, while I do find the bot typically annoying, it is doing it's job at letting anyone know that is subscribed that it's been a while and the issue will be closed if there's no further engagement. We don't have that many contributors, anything long-lived assigned to a maintainer just gets the stalebot-ignore label

This 👍

But I don't have a strong opinion on that. So feel free to merge.

[georglauterbach]

I'm more in favor of increasing the time it takes for the bot to kick an. As a maintainer, I am against this change, but I see that the majority has nothing against it. I will not stand in the way of merging this, but I cannot recommend it either: we still have plenty of issues (and PRs) that just rot, because no one is taking care. I rather see them closed so I can take care of activly maintained ones, then leave them open for a really long time.

I do not have the solution, admittedly, but I do not think this change solves anything either, as stupid as that may sound.

[polarathene]

@georglauterbach and @casperklein are the most active maintainers currently, neither expressed a need for this change.

The better change would be to raise the limit for when an issue / PR is considered stale (my suggestion was 4 months). If anyone is annoyed enough at the stale-bot, they should raise a PR to make that change.

---

Closing Reason

As cited above, this does not seem like it would be useful in the opinion of most maintainers.

It may actually become a regression for the purpose it serves this project (an engagement prompt for anyone subscribed that cares). Thus rejecting until it can be shown the benefits are worthwhile for this project, compared to alternatives such as increasing the time requirement for the bot to trigger.