4 ms·

Hell yes. If you have an open issue, you have an issue. It doesn't disappear because you wish it away with a bot. Ticket overload may be a problem, but stale b

Hell yes. If you have an open issue, you have an issue. It doesn't disappear because you wish it away with a bot. Ticket overload may be a problem, but stale bots do not solve it.

ajsnigrutin 5y ago
This depends There might be an issue like "I get an error message, and then the software crashes!", you ask "what error message? What version? What does the log say?", and you never get a response, and the issues gets burried and forgotten.
- Snetry 5y ago
  Yes, but a stale bot is not going to stop those from appearing and will close issues with steps to reproduce and tracebacks
  - darkwater 5y ago
    Exactly. If you want to improve quality of reports, GH now let's projects even ask some questions before opening an issue, to redirect users to the proper channel. And if the proper channel is an issue, there is the ISSUE.md template that has been working for several years already now.
    - dhaavi 5y ago
      I only know the issue templates with the chooser. Can you point me to the feature you referred to with „GH now let's projects even ask some questions before opening an issue“?
      - darkwater 5y ago
        We are probably talking about the same feature. What I meant was this kind of page https://github.com/home-assistant/core/issues/new/choose https://github.com/home-assistant/core/issues/new/choose
        imtringued 5y ago
        That looks fantastic.
        dhaavi 5y ago
        Ok. Thanks. That’s how we use it too. I guess the question thing got me confused.
        darkwater 5y ago
        Yeah sorry for that, it's a multichoice page which inherently asks you a "what are you trying to do?" question.
    - chrismorgan 5y ago
      Contrarian view: I hate issue templates (at least as implemented) because they utterly cripple search for any word that appears in the template (and I’ve had this bite me more than once or twice). Most of the stuff people use templates for should instead be instructions outside the box, but GitHub doesn’t support that. If you’re going to follow the “big blob of text” model rather than having separate fields for much of the metadata, then your goal should be to have as little text as possible in any template, and avoid any words that people might want to search on.
      - c0wb0yc0d3r 5y ago
        Could you provide an example of the problem you describe? I'm having trouble imagining it. My brain keeps telling me that the words I would search for would show up in the content even if they're used in a template. Is it maybe an issue of synonyms. Like error and exception might mean the same to one person and not another?
        chrismorgan 5y ago
        Sorry, it’s a year or so since it last happened (I haven’t been interacting with projects with heavy templates so recently) and I can’t remember any of them off the top of my head. One that I recall (but not the project or word) was a fairly common English word with two senses where I would have expected one or two false positives only, another was something more along the lines of “Versions (`uname -a`, `mylangc --version`, `mylangpkg --version`):” making “mylangpkg” unsearchable (in cases like this, disciplined use of labels can mitigate the damage). The problem is that as soon as the template contains the word you’re searching for, every issue matches your search.
        blincoln 5y ago
        > My brain keeps telling me that the words I would search for would show up in the content even if they're used in a template. Thats exactly how I read the description of the original problem. The issue template says something like "What text appears in the 'Current Status' pop-up?", and so then it becomes difficult to search for issues related to the "Current Status" pop-up not appearing at all, because searching for it will return all issues.
- chrismorgan 5y ago
  Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely. This is then readily searchable, so that when you get round to doing another batch of manual triage you can quickly close it as incomplete, or try to follow it up, or whatever you like. This also highlights another crucial difference in Bugzilla: it keeps track of not just open/closed state, but also the reason: fixed, can’t reproduce, won’t fix, incomplete… whereas stale bots are a single awful blunt instrument that seem like they might help with closing incomplete bug reports, but in practice they do much more closing of real stuff, annoying of reporters, shoving of stuff under the carpet, &c. What the stale bots lack is nuance, because GitHub Issues is too generic to support a good triage bot that isn’t deeply specialised to a project. And even if you have a decent triage bot, there is no substitute for manual triage. It doesn’t need to take very long.
  - emersion 5y ago
    This kind of workflow can be achieved with GitHub or GitLab issues by using labels. For instance, I often add a waiting-on-reporter label when asking for more info.
    - techdragon 5y ago
      You could even have a friendly bot nag the user a few times over several months for the extra info, perhaps eventually closing it after a year.
      - sodality2 5y ago
        A conditional stale bot based on this tag being applied would be ideal IMO
  - scottlamb 5y ago
    > Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely. In my experience, in many projects the issue does stay in that state indefinitely, even after the reporter provides the info. The reporter doesn't have permissions to remove the label; the people who do have the permissions miss the notification and never do the manual triage you mention. They might as well just close anything that doesn't have enough information or (depending on your perspective) that they don't understand/care to understand. (For example: I filed an issue a couple months ago in which I explained the problem I was having, pointed out it contradicted the documentation, then proposed a solution. Then I opened a PR with the solution and explained it within the documentation and the commit message. Then I got asked a question in a PR comment that was answered in all three of those other places. I replied (explaining it in a fourth place), but the PR still has the "needs-reporter-feedback ?" label and isn't going anywhere.) Maybe the most useful thing a bot could do is remove this label after the next comment... or maybe it's just hopeless if a project doesn't care enough about their issues.
- fireflash38 5y ago
  Then close it directly, rather than relying on a (passive agressive) bot to do it for you.
- corobo 5y ago
  Tag it as waiting and then stale bot the waiting tag only

Hell yes. If you have an open issue, you have an issue. It doesn't disappear because you wish it away with a bot. Ticket overload may be a problem, but stale bots do not solve it.

ajsnigrutin 5y ago

This depends There might be an issue like "I get an error message, and then the software crashes!", you ask "what error message? What version? What does the log say?", and you never get a response, and the issues gets burried and forgotten.

Snetry 5y ago
Yes, but a stale bot is not going to stop those from appearing and will close issues with steps to reproduce and tracebacks
- darkwater 5y ago
  Exactly. If you want to improve quality of reports, GH now let's projects even ask some questions before opening an issue, to redirect users to the proper channel. And if the proper channel is an issue, there is the ISSUE.md template that has been working for several years already now.
  - dhaavi 5y ago
    I only know the issue templates with the chooser. Can you point me to the feature you referred to with „GH now let's projects even ask some questions before opening an issue“?
    - darkwater 5y ago
      We are probably talking about the same feature. What I meant was this kind of page https://github.com/home-assistant/core/issues/new/choose https://github.com/home-assistant/core/issues/new/choose
      - imtringued 5y ago
        That looks fantastic.
      - dhaavi 5y ago
        Ok. Thanks. That’s how we use it too. I guess the question thing got me confused.
        darkwater 5y ago
        Yeah sorry for that, it's a multichoice page which inherently asks you a "what are you trying to do?" question.
  - chrismorgan 5y ago
    Contrarian view: I hate issue templates (at least as implemented) because they utterly cripple search for any word that appears in the template (and I’ve had this bite me more than once or twice). Most of the stuff people use templates for should instead be instructions outside the box, but GitHub doesn’t support that. If you’re going to follow the “big blob of text” model rather than having separate fields for much of the metadata, then your goal should be to have as little text as possible in any template, and avoid any words that people might want to search on.
    - c0wb0yc0d3r 5y ago
      Could you provide an example of the problem you describe? I'm having trouble imagining it. My brain keeps telling me that the words I would search for would show up in the content even if they're used in a template. Is it maybe an issue of synonyms. Like error and exception might mean the same to one person and not another?
      - chrismorgan 5y ago
        Sorry, it’s a year or so since it last happened (I haven’t been interacting with projects with heavy templates so recently) and I can’t remember any of them off the top of my head. One that I recall (but not the project or word) was a fairly common English word with two senses where I would have expected one or two false positives only, another was something more along the lines of “Versions (`uname -a`, `mylangc --version`, `mylangpkg --version`):” making “mylangpkg” unsearchable (in cases like this, disciplined use of labels can mitigate the damage). The problem is that as soon as the template contains the word you’re searching for, every issue matches your search.
      - blincoln 5y ago
        > My brain keeps telling me that the words I would search for would show up in the content even if they're used in a template. Thats exactly how I read the description of the original problem. The issue template says something like "What text appears in the 'Current Status' pop-up?", and so then it becomes difficult to search for issues related to the "Current Status" pop-up not appearing at all, because searching for it will return all issues.
chrismorgan 5y ago
Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely. This is then readily searchable, so that when you get round to doing another batch of manual triage you can quickly close it as incomplete, or try to follow it up, or whatever you like. This also highlights another crucial difference in Bugzilla: it keeps track of not just open/closed state, but also the reason: fixed, can’t reproduce, won’t fix, incomplete… whereas stale bots are a single awful blunt instrument that seem like they might help with closing incomplete bug reports, but in practice they do much more closing of real stuff, annoying of reporters, shoving of stuff under the carpet, &c. What the stale bots lack is nuance, because GitHub Issues is too generic to support a good triage bot that isn’t deeply specialised to a project. And even if you have a decent triage bot, there is no substitute for manual triage. It doesn’t need to take very long.
- emersion 5y ago
  This kind of workflow can be achieved with GitHub or GitLab issues by using labels. For instance, I often add a waiting-on-reporter label when asking for more info.
  - techdragon 5y ago
    You could even have a friendly bot nag the user a few times over several months for the extra info, perhaps eventually closing it after a year.
    - sodality2 5y ago
      A conditional stale bot based on this tag being applied would be ideal IMO
- scottlamb 5y ago
  > Bugzilla’s approach: in your “what error message?” comment, you also set the needsinfo?(reporter@example.com) flag (a single checkbox does it), and it can stay in that state indefinitely. In my experience, in many projects the issue does stay in that state indefinitely, even after the reporter provides the info. The reporter doesn't have permissions to remove the label; the people who do have the permissions miss the notification and never do the manual triage you mention. They might as well just close anything that doesn't have enough information or (depending on your perspective) that they don't understand/care to understand. (For example: I filed an issue a couple months ago in which I explained the problem I was having, pointed out it contradicted the documentation, then proposed a solution. Then I opened a PR with the solution and explained it within the documentation and the commit message. Then I got asked a question in a PR comment that was answered in all three of those other places. I replied (explaining it in a fourth place), but the PR still has the "needs-reporter-feedback ?" label and isn't going anywhere.) Maybe the most useful thing a bot could do is remove this label after the next comment... or maybe it's just hopeless if a project doesn't care enough about their issues.
fireflash38 5y ago
Then close it directly, rather than relying on a (passive agressive) bot to do it for you.
corobo 5y ago
Tag it as waiting and then stale bot the waiting tag only