4 ms·

I sympathise with this, however, I disagree that it's harmful at all times. I think having it misconfigured it's definitely harmful. The way I handle it is ess

by gizdan 5y ago

I sympathise with this, however, I disagree that it's harmful at all times. I think having it misconfigured it's definitely harmful. The way I handle it is essentially never setting up automatic thread locking, and then, default to closing the issue, unless I add some specific label. This is mostly for my sanity. There's a lot of issues where you get an issue raised with "x doesn't work", with little to no information. Great, I can't do anything with that, so I push back, and often you don't hear anything back. At this point, I close it (or rather, stale bot does after inactivity). If the user then provides more information and the issue is triaged and valid, I add a label, which makes sure stale bot does not close the issue. If an issue does get closed, I'll get a notification if someone ends up commenting, and I can take appropriate action. It also gives others the opportunity to comment if they can provide additional context.

geerlingguy 5y ago
This is exactly how I use it. Some people do complain, and I get it. But they don't realize that 98% of all issues are spam that clutters up the issue queue, and outside of dedicated time just sitting around labeling issues and manually closing them, there would be no way for maintainers of anything near-popular to sift through issues for anything that actually matters. As it stands, a few of my moderately popular repos get on average 5-10 new issues per day. One of them might have any relevance towards improving the project. I don't see the same people who complain about stale bots volunteering to sit there babysitting issue queues closing irrelevant ones and responding to, essentially, free support requests.
- cxr 5y ago
  You're way mistaken; there are absolutely people who recognize that these bots suck and also dump on the GitHub community for its tendency to abuse bugtrackers for dumb stuff like support requests and general project discussion. This comprises like half of my GitHub-related comments on HN. (The other half includes complaints that the GitHub generation has rendered the word "wiki" meaningless by applying it to things that are clearly not wikis and then taking an IDGAF attitude if you bring it up. The author of the blog post here is among the guilty.) Good bug discipline isn't new. It was understood at least 20 years ago and widely practiced with Bugzilla. GitHub and the types of users who go for it, though, seem to have a bent on organizational and operational regression. It's more important to chase self-actualization by doing things that feel productive because they keep you busy rather than thinking critically about how to actually be productive, apparently.
mook 5y ago
Yes, auto-closing an issue waiting on external feedback that hasn't happened is a great thing. Unfortunately GitHub isn't set up for that at all — there's no easy configuration to do that; instead the easy thing is to close based on inactivity without considering who the issue is waiting on. You essentially need to have a label ("needs user feedback") that isn't applied by default, have the stale bot only act on issues with that label, and get that label cleared automatically on any comment. I don't think that last part is doable without your own custom bot.
- yjftsjthsd-h 5y ago
  Of all the things I miss from Jira, the ability to have an explicit "waiting on user" state is definitely one of the big ones. Edit: Someone below has suggested a way to roughly do this with tags; I'll have to try that.

by gizdan 5y ago

geerlingguy 5y ago

This is exactly how I use it. Some people do complain, and I get it. But they don't realize that 98% of all issues are spam that clutters up the issue queue, and outside of dedicated time just sitting around labeling issues and manually closing them, there would be no way for maintainers of anything near-popular to sift through issues for anything that actually matters. As it stands, a few of my moderately popular repos get on average 5-10 new issues per day. One of them might have any relevance towards improving the project. I don't see the same people who complain about stale bots volunteering to sit there babysitting issue queues closing irrelevant ones and responding to, essentially, free support requests.

cxr 5y ago
You're way mistaken; there are absolutely people who recognize that these bots suck and also dump on the GitHub community for its tendency to abuse bugtrackers for dumb stuff like support requests and general project discussion. This comprises like half of my GitHub-related comments on HN. (The other half includes complaints that the GitHub generation has rendered the word "wiki" meaningless by applying it to things that are clearly not wikis and then taking an IDGAF attitude if you bring it up. The author of the blog post here is among the guilty.) Good bug discipline isn't new. It was understood at least 20 years ago and widely practiced with Bugzilla. GitHub and the types of users who go for it, though, seem to have a bent on organizational and operational regression. It's more important to chase self-actualization by doing things that feel productive because they keep you busy rather than thinking critically about how to actually be productive, apparently.

mook 5y ago

Yes, auto-closing an issue waiting on external feedback that hasn't happened is a great thing. Unfortunately GitHub isn't set up for that at all — there's no easy configuration to do that; instead the easy thing is to close based on inactivity without considering who the issue is waiting on. You essentially need to have a label ("needs user feedback") that isn't applied by default, have the stale bot only act on issues with that label, and get that label cleared automatically on any comment. I don't think that last part is doable without your own custom bot.

yjftsjthsd-h 5y ago
Of all the things I miss from Jira, the ability to have an explicit "waiting on user" state is definitely one of the big ones. Edit: Someone below has suggested a way to roughly do this with tags; I'll have to try that.