Skip to content
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

Open
Marcono1234 opened this issue Apr 18, 2022 · 6 comments
Open
Labels
enhancement New feature or request keep

Comments

@Marcono1234
Copy link

Marcono1234 commented Apr 18, 2022

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 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:

@Marcono1234 Marcono1234 added the bug Something isn't working label Apr 18, 2022
@luketomlinson
Copy link
Collaborator

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.

@luketomlinson luketomlinson added enhancement New feature or request keep and removed bug Something isn't working labels Apr 22, 2022
@Marcono1234
Copy link
Author

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
Copy link

riphack commented Apr 27, 2022

#134

@bgehman
Copy link

bgehman commented May 23, 2022

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.

gberche-orange added a commit to gberche-orange/crossplane that referenced this issue Apr 26, 2023
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 <guillaume.berche@orange.com>
AndrewChubatiuk pushed a commit to AndrewChubatiuk/crossplane that referenced this issue May 4, 2023
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 <guillaume.berche@orange.com>
Signed-off-by: Andrew Chubatiuk <andrew.chubatiuk@motional.com>
negz pushed a commit to negz/crossplane that referenced this issue May 24, 2023
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 <guillaume.berche@orange.com>
@dundargoc
Copy link

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
Script to remove label
Script that checks if the author has commented in the last 30 days

My hope would be to eventually remove this and rely on something from either github or a "community" solution/action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep
Projects
None yet
Development

No branches or pull requests

6 participants
@Marcono1234 @bgehman @luketomlinson @dundargoc @riphack and others