-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default behavior can be disruptive for contributors of a repository #719
Comments
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:
I'll leave this issue open for a bit to see if others feel the same. |
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 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. |
Github has an API to pull all issues with a specific
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. |
The 7 days current limit is preventing people away from keyboard to comment the issue and there is supported bot action to reopen them afterwards See related side effect of misconfigured stale bot at actions/stale#719 Signed-off-by: Guillaume Berche <[email protected]>
The 7 days current limit is preventing people away from keyboard to comment the issue and there is supported bot action to reopen them afterwards See related side effect of misconfigured stale bot at actions/stale#719 Signed-off-by: Guillaume Berche <[email protected]> Signed-off-by: Andrew Chubatiuk <[email protected]>
The 7 days current limit is preventing people away from keyboard to comment the issue and there is supported bot action to reopen them afterwards See related side effect of misconfigured stale bot at actions/stale#719 Signed-off-by: Guillaume Berche <[email protected]>
Mentioning in case it helps someone else: I basically created my own custom response "action" precisely because the default behavior of stale bot is so aggressive. It's not amazing by any means, but its behavior certainly aligns more with how I'd like it to behave. The workflow file My hope would be to eventually remove this and rely on something from either github or a "community" solution/action. |
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:
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 theawaiting-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:
The text was updated successfully, but these errors were encountered: