Default behavior can be disruptive for contributors of a repository

[Marcono1234]

Describe your issue

The current default behavior (with minimal configuration) of closing issues and pull requests without any activity is often disruptive for contributors of a repository. It might even harm building a contributor community.

When maintainers of a repository add the stale action (or the stale bot) they seem to mostly (or only) think of the positive aspect of closing irrelevant or outdated issues. However, what they often fail to consider is the perspective from the user or contributor who created an issue or pull request. The main problem is that the action acts without any context, this means issues or pull requests where the reporter is waiting on the response or feedback from the maintainer are closed as 'stale' (related #56). This can be extremely frustrating for the user because they continuously waste their time (and clutter the comments) by keeping an issue "updated", eventually giving up. Additionally, if you (or any other user interested in an issue) misses the time frame before an issue is closed, the issue remains closed (see #345). So even if users comment on it again it won't be reopened. This forces users to duplicate the closed issue, which puts even more work on the maintainers and splits the upvotes and comments between two (or more) separate issues, making it difficult to track.

One could argue that if a user does not respond to the stale comment it means that the original issue is not so important, or has been resolved. But what this might actually mean is that users are so frustrated that they either create their own fork, or just switched to an alternative project where interaction with the maintainers is more productive.

Negative examples can even be found in this repository itself:

• Allow to add or remove labels on stale #498, surely this can't be the right way to keep an issue "updated"
• Feature request: Support deleting branches when closing PRs #57 (comment)
• exempt-milestone and exempt-project options #35, this and similar issues have multiple upvotes but are closed as stale nonetheless without any reaction from the maintainers

If you want to keep this default behavior, it would be good to explicitly mention in the README what effect this might have on contributors and community building (maybe even in bold with big warnings signs ...), to make it clear to users of this action what price they pay.

In my opinion a default behavior where an explicit awaiting-response label (or similar) is added by maintainers and only then when no activity happens an issue or pull request may be marked as stale and will be closed would be more reasonable, and would be reopened when activity (from a non-maintainer) occurs. (Ideally with functionality to automatically remove the awaiting-response label on non-maintainer activity, but that may be out of scope).
My point here is not to discredit this action; it is really powerful and can be very useful. But its current default behavior is in my personal opinion problematic.

Maybe for large repositories with a lot user interaction, or when maintainers don't have much free time to work on a project, the current default behavior might make sense to help them manage the workload. But it is a bit questionable whether the action should then really run before any manual triage by the maintainers happened.

Blog posts and discussions about this issue:

• https://blog.benwinding.com/github-stale-bots/ (related but about a different bot)
• https://news.ycombinator.com/item?id=25821092
• https://news.ycombinator.com/item?id=28998374

[luketomlinson]

hi @Marcono1234, thanks for writing these thoughts down. I think your concerns make sense. However, I do think it's also worth noting that using the stale actions is completely opt-in. The action is primarily geared toward maintainers and it's somewhat up to them how they would like to administer it. Maintainers have the ability to tweak the configuration to their unique needs.

It sounds like from your perspective, a few things would help the situation:

• multiple layers of labels: e.g. awaiting-response -> stale -> closed (this seems feasible)
• allow the stale-action to re-open closed stale issues that have new activity (the main issue I see with this is that the action would have to process all issues and check which have the stale label and check for new activity on those)

I'll leave this issue open for a bit to see if others feel the same.

[Marcono1234]

Thanks a lot for your feedback! You are right, it is mostly up to the owners of a repository how they use this action. And a configuration with an awaiting-response label is mostly already possible (through the only-labels input).

The issue is that most usage examples in the README do not show this, and do not warn about the consequences of these default configurations either. So I assume users may just pick one of the usage examples for simplicity, without thinking much about the consequences of that configuration.

[riphack]

#134

[bgehman]

allow the stale-action to re-open closed stale issues that have new activity (the main issue I see with this is that the action would have to process all issues and check which have the stale label and check for new activity on those)

Github has an API to pull all issues with a specific label(s), and will return up to 100 matches per API call. Also, that same API supports the since query parm to only fetch things updated recently if the concern is processing ancient issues that haven't had recent updates.

The current default behavior (with minimal configuration) of closing issues and pull requests without any activity is often disruptive for contributors of a repository. It might even harm building a contributor community.

100% agree with that. Having an issue I opened against this project, only to have it be closed by the stale-bot without any response from a maintainer is quite off-putting. It indicates that the project owner/maintainer(s) are too lazy to even respond to the community and has the effect of actively impeding any further community involvement.