4 ms·

I had a quick check and it looks like Microsoft doesn't have an automatic clean-up bot running which is really nice to see. Compare it to the Istio project whi

I had a quick check and it looks like Microsoft doesn't have an automatic clean-up bot running which is really nice to see. Compare it to the Istio project which just deletes your issue if someone doesn't respond it to after 28 days. Despite the issue often being quite real. Also I wonder how these larger projects will fare once Github rolls out the Discussions feature.

qz2 6y ago
They don’t. They do however have a policy of closing down tickets which are unpopular after beating customers down. Like the whole CLR telemetry thing.
gitgud 6y ago
The @angular repositories do that too... The worst are the "lock bots" which prevents any new information being added to the issue... Which is super annoying.... But it must be hard for a maintainer to deal with the notifications
- birracerveza 6y ago
  Yeah, but sweeping the issue under the rug is not the way to go. Sure, you have closed the issue because you did not pay attention to it for the last year. But the problem is still there. So the next person who stumbles upon the old, locked issue will now open a new one. Now you have two issues.
- acoard 6y ago
  Doesn't this just cause more noise and notifications, not less? A stale issue can be ignored, a closed issue may be duplicated. Whenever I came across these issues, I'd just open up a new issue and link to the old one and politely ask if they planned on addressing it or not.
diggan 6y ago
Seems they do have automatic cleanup but it's not documented. Seems if the label "needs more info" was added more than a week ago, they close the issue. The quest for the perfect issue grooming continues. Example: https://github.com/microsoft/vscode/issues/86409#issuecomment-713502637 https://github.com/microsoft/vscode/issues/86409#issuecommen...
- claviska 6y ago
  I think this is perfectly acceptable. If the user hasn’t demonstrated a reproducible problem and more information is required, the user has a week to submit said information. If not, the issue is cleaned up automatically. I don’t see why the maintainers should have to manually revisit each ticket if the OP fails to respond. And auto-closing doesn’t mean the issue can’t be reopened. If OP posts additional information after the grace period, the maintainers will be notified and the ticket can be reopened.
  - diggan 6y ago
    Yeah, guess we all have different processes for dealing with reports/GitHub Issues. For me, a closed issue signals a closure of some sort, either that it's not accurate, been fixed, or any other reason. Simply that time has passed does not count as "resolution" for me. But in the end, whatever works for you!
    - xboxnolifes 6y ago
      > For me, a closed issue signals a closure of some sort, either that it's not accurate... In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
      - diggan 6y ago
        No, as I wouldn't have the full picture of the issue, I can't say if it's accurate or not.
    - codethief 6y ago
      Maybe another status "stale" would be the solution here. That way, maintainers would be able to focus on "active" issues while the people who reported the issue could still add information to the issue later on to move it from "stale" back to "open" / "active".
      - 6y ago
vidanay 6y ago
Microsoft's automatically closed tickets are a running gag joke with my development team. They are pathetic - problems don't go away because you ignore them.
bredren 6y ago
Many projects have auto-closing issue bots. More than I realized. I also don’t like them, but it does force the reporter to stay engaged and bump issues they really care about. Issue management seems like a major surface for Github to improve on. I have a work category for each of my projects named simply “ticket laundry” and I know it eats up a lot of time for maintainers and reporters.
JamesSwift 6y ago
Auto cleanup bots are one of my biggest pet peeves in recent years. As another commenter mentioned, angular is the worst offender for me. Ive seen countless _real_ issues get closed over the years because of inactivity by core maintainers. The only reason I knew those github issues existed in the first place was because I wasted hours (sometimes days) of my life looking into an issue only to eventually stumble upon them and realize its a bug and I'm not "holding it wrong". Good luck to the next person that goes spelunking on the internet for help on those issues.
- moufestaphio 6y ago
  >Good luck to the next person that goes spelunking on the internet for help on those issues. Reminds me of: https://xkcd.com/979/ https://xkcd.com/979/
- pmiller2 6y ago
  If only there was a way you could mark an issue as "old, but still possibly relevant." Perhaps by adding a label, or something.... Doesn't all issue tracking software support either labels, tags, or custom statuses beyond "open, todo, in progress, closed"? I think having a bot tag, but not close, issues over a certain age, seems to make a lot of sense.
  - kazinator 6y ago
    The "age" of an issue should be the most recent version number of the software in which it reproduces, and not the date when the ticket was created.
  - edflsafoiewq 6y ago
    Why? If you want to know how old it is, just look at the filing date.
yboris 6y ago
I've not heard about the Discussions feature! Here's a nice write-up I found: https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-discussions.html https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-d...
gumby 6y ago
An automatic clean up bot could help but is usually not thought through (as numbers examples in this thread describe). There are two common cases where some automation can help: - User reports bug, dev explains that "it's not a bug, here's why, xxx" (or otherwise provides a satisfactory response) and user, even if satisfied, fails to return to close bug. So instead devs have to remember to close the bug which they usually do immediately after responding, which comes off as abrupt, even though it's not meant that way. - User reports bug, dev responds with request for more info ("I can't duplicate; could you provide a better test case?"), user never responds. In both cases it's OK to time out these old reports (which are essentially clutter). You could provide a way for the dev to flag this as one not to be auto-cleaned up. Another improvement, while I'm at it: provide a Godbolt-like way to submit a test case that can be outrun (i.e. a CI case). Then the bug could be auto-closed if it's in the current release but already fixed in the dev sources. Not all bugs or applications could take advantage of this of course.

qz2 6y ago

They don’t. They do however have a policy of closing down tickets which are unpopular after beating customers down. Like the whole CLR telemetry thing.

gitgud 6y ago

The @angular repositories do that too... The worst are the "lock bots" which prevents any new information being added to the issue... Which is super annoying.... But it must be hard for a maintainer to deal with the notifications

birracerveza 6y ago
Yeah, but sweeping the issue under the rug is not the way to go. Sure, you have closed the issue because you did not pay attention to it for the last year. But the problem is still there. So the next person who stumbles upon the old, locked issue will now open a new one. Now you have two issues.
acoard 6y ago
Doesn't this just cause more noise and notifications, not less? A stale issue can be ignored, a closed issue may be duplicated. Whenever I came across these issues, I'd just open up a new issue and link to the old one and politely ask if they planned on addressing it or not.

diggan 6y ago

Seems they do have automatic cleanup but it's not documented. Seems if the label "needs more info" was added more than a week ago, they close the issue. The quest for the perfect issue grooming continues. Example: https://github.com/microsoft/vscode/issues/86409#issuecomment-713502637 https://github.com/microsoft/vscode/issues/86409#issuecommen...

claviska 6y ago
I think this is perfectly acceptable. If the user hasn’t demonstrated a reproducible problem and more information is required, the user has a week to submit said information. If not, the issue is cleaned up automatically. I don’t see why the maintainers should have to manually revisit each ticket if the OP fails to respond. And auto-closing doesn’t mean the issue can’t be reopened. If OP posts additional information after the grace period, the maintainers will be notified and the ticket can be reopened.
- diggan 6y ago
  Yeah, guess we all have different processes for dealing with reports/GitHub Issues. For me, a closed issue signals a closure of some sort, either that it's not accurate, been fixed, or any other reason. Simply that time has passed does not count as "resolution" for me. But in the end, whatever works for you!
  - xboxnolifes 6y ago
    > For me, a closed issue signals a closure of some sort, either that it's not accurate... In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
    - diggan 6y ago
      No, as I wouldn't have the full picture of the issue, I can't say if it's accurate or not.
  - codethief 6y ago
    Maybe another status "stale" would be the solution here. That way, maintainers would be able to focus on "active" issues while the people who reported the issue could still add information to the issue later on to move it from "stale" back to "open" / "active".
    - 6y ago

vidanay 6y ago

Microsoft's automatically closed tickets are a running gag joke with my development team. They are pathetic - problems don't go away because you ignore them.

bredren 6y ago

Many projects have auto-closing issue bots. More than I realized. I also don’t like them, but it does force the reporter to stay engaged and bump issues they really care about. Issue management seems like a major surface for Github to improve on. I have a work category for each of my projects named simply “ticket laundry” and I know it eats up a lot of time for maintainers and reporters.

JamesSwift 6y ago

Auto cleanup bots are one of my biggest pet peeves in recent years. As another commenter mentioned, angular is the worst offender for me. Ive seen countless _real_ issues get closed over the years because of inactivity by core maintainers. The only reason I knew those github issues existed in the first place was because I wasted hours (sometimes days) of my life looking into an issue only to eventually stumble upon them and realize its a bug and I'm not "holding it wrong". Good luck to the next person that goes spelunking on the internet for help on those issues.

moufestaphio 6y ago
>Good luck to the next person that goes spelunking on the internet for help on those issues. Reminds me of: https://xkcd.com/979/ https://xkcd.com/979/
pmiller2 6y ago
If only there was a way you could mark an issue as "old, but still possibly relevant." Perhaps by adding a label, or something.... Doesn't all issue tracking software support either labels, tags, or custom statuses beyond "open, todo, in progress, closed"? I think having a bot tag, but not close, issues over a certain age, seems to make a lot of sense.
- kazinator 6y ago
  The "age" of an issue should be the most recent version number of the software in which it reproduces, and not the date when the ticket was created.
- edflsafoiewq 6y ago
  Why? If you want to know how old it is, just look at the filing date.

yboris 6y ago

I've not heard about the Discussions feature! Here's a nice write-up I found: https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-discussions.html https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-d...

gumby 6y ago

An automatic clean up bot could help but is usually not thought through (as numbers examples in this thread describe). There are two common cases where some automation can help: - User reports bug, dev explains that "it's not a bug, here's why, xxx" (or otherwise provides a satisfactory response) and user, even if satisfied, fails to return to close bug. So instead devs have to remember to close the bug which they usually do immediately after responding, which comes off as abrupt, even though it's not meant that way. - User reports bug, dev responds with request for more info ("I can't duplicate; could you provide a better test case?"), user never responds. In both cases it's OK to time out these old reports (which are essentially clutter). You could provide a way for the dev to flag this as one not to be auto-cleaned up. Another improvement, while I'm at it: provide a Godbolt-like way to submit a test case that can be outrun (i.e. a CI case). Then the bug could be auto-closed if it's in the current release but already fixed in the dev sources. Not all bugs or applications could take advantage of this of course.