4 ms·

Then again, adding a comment may prevent a bot from auto-closing the issue.

MereInterest 4y ago
I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.
- johannes1234321 4y ago
  It depends a bit in the project and maintainers motivation. However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.
  - yorwba 4y ago
    How do old tickets hide recent issues? The default is to show the newest ones first, isn't it?
- jlkuester7 4y ago
  Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person who notices the issue to open a new one... Also, no activity on an issue can just mean that folks are waiting patiently for someone to get around to implementing it (or, more commonly, for some project dependency to release the patch that is necessary for fixing the issue ..).
  - deleted 4y ago
    [deleted]
- jrochkind1 4y ago
  I think they are basically an attempt at form of "issues/tracker bankruptcy" -- we have too many open things here, leaving them all open like we're going to get to them all eventually is a fantasy, and is overwhelming and makes it harder to find the ones we might actually address, so trying to algorithmically close the ones least likely to be actionable is just trying to make the situation more manageable. I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too. Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer: > While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions. > Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs. https://github.com/rails/rails/commit/acf48169943011834c4c885b956e29050548fa98 https://github.com/rails/rails/commit/acf48169943011834c4c88...
  - jrochkind1 4y ago
    Reading over the Rails committer message there… So Rails, decided that they did not want to discourage code PR contributors (despite getting some poor quality ones, I'm sure). But other projects may actually want to discourage PR's, or especially Issues, so consider this a plus not a minus. Of course, you can just turn off Issues/PR's, or only allow maintainers to make them, if you really don't want them. But sometimes I'm guessing someone really don't want them but doesn't really want to say so...
matkoniecz 4y ago
Project with autoclose bots is not worth wasting any time by contributing to it, even by making an issue.

I've never really understood the point of these bots. I could understand if an issue had a test case attached to it, and the bot was auto-closing the issue if/when the test passes. That way, if it is resolved when fixing some other bug, or when refactoring, the issue is closed. But closing an issue due to inactivity gives the false impression that the issue has been resolved.

johannes1234321 4y ago
It depends a bit in the project and maintainers motivation. However: Many projects swim in a sea of open tickets. Too many for the maintainers to keep an overview. By auto closing you make it clear to observers that currently this thing likely won't change and by forcing to reopen the maintainers can get users to tell them whether the issue still persists without having to try themselves. Generally there is little worth in keeping many years old tickets open, hiding recent issues while probably not being an issue anymore for whatever reason.
- yorwba 4y ago
  How do old tickets hide recent issues? The default is to show the newest ones first, isn't it?
jlkuester7 4y ago
Same, I find these bots really annoying. I guess they might be necessary/useful for popular projects where a small team of maintainers is trying to stay on top of a massive pile of incoming issues. But for the most part they seem misguided. (Especially the ones with a really short (like 30 days) activity window.) If an issue still exists in the project, why should it be closed? That will just require the next person who notices the issue to open a new one... Also, no activity on an issue can just mean that folks are waiting patiently for someone to get around to implementing it (or, more commonly, for some project dependency to release the patch that is necessary for fixing the issue ..).
- deleted 4y ago
  [deleted]
jrochkind1 4y ago
I think they are basically an attempt at form of "issues/tracker bankruptcy" -- we have too many open things here, leaving them all open like we're going to get to them all eventually is a fantasy, and is overwhelming and makes it harder to find the ones we might actually address, so trying to algorithmically close the ones least likely to be actionable is just trying to make the situation more manageable. I think it's a desperate measure -- if any maintainers are seeing it as reasonable management technique rather than desparate measure, I think they're making a mistake. It has a lot of downsides, some of which you outline, I agree with you. It also generally raises user frustration, leading to even more adversorial relationship between users and maintainers, which is what the OP is about and I think part of what's going on in this "issue bankruptcy" situations too. Notably, Rails just turned off their auto-closer for Pull Requests (not sure about Issues), with this commit message from a maintainer: > While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions. > Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs. https://github.com/rails/rails/commit/acf48169943011834c4c885b956e29050548fa98 https://github.com/rails/rails/commit/acf48169943011834c4c88...
- jrochkind1 4y ago
  Reading over the Rails committer message there… So Rails, decided that they did not want to discourage code PR contributors (despite getting some poor quality ones, I'm sure). But other projects may actually want to discourage PR's, or especially Issues, so consider this a plus not a minus. Of course, you can just turn off Issues/PR's, or only allow maintainers to make them, if you really don't want them. But sometimes I'm guessing someone really don't want them but doesn't really want to say so...

matkoniecz 4y ago

Project with autoclose bots is not worth wasting any time by contributing to it, even by making an issue.