7 ms·

In my experience, these auto-closing bots are the natural result of software development workflows that treat issues as tasks to be closed, rather than a data p

In my experience, these auto-closing bots are the natural result of software development workflows that treat issues as tasks to be closed, rather than a data point that a user is experiencing a problem of some kind (maybe they are doing things wrong, expecting something the project doesn't provide, or triggering a real problem – the exact cause is immaterial). This treatment of issue-as-a-task is made worse by corporate micromanagement frameworks like Agile, which encourage metrics on how many of these issues-as-tasks are closed, which leads to ill-advised features like this that close them automatically because "Duh, no one said anything in 30 days". If I were to design this myself, I would argue that the correct way to treat an issue is not to have it have a closed or open state at all. If the issue spawns a task or related tasks, you can close those. Or you can provide feedback on the issue that states that it is invalid. The user has already experienced a problem or wants a feature, there is no value in putting a red label that indicates "I'm done with this, please go away". It unnecessarily invalidates the experience of users who have their provided valuable time to report something to your software project. I think this is similar to the approach used by forums like Discourse, where a thread about a problem will usually not be closed or locked, but will just age out of current discussion if nobody brings it up.

c7DJTLrn 5y ago
Yep. GitHub Issues is not a scrum board and shouldn't be treated as such. It's for consumers to discuss with authors and other consumers.
- pc86 5y ago
  If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.
  - npteljes 5y ago
    Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.
pydry 5y ago
It's ironic that github sold itself as "social coding" coz while the design was pretty and the usability is good the social aspects are almost programmed to bring the worst out in people. Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To. It's not that it will ruin your relationships if you work with good people or vice versa but I've seen bad blood and insecurities exacetbated by the workflow that were unnecessary.
- charrondev 5y ago
  Are suggesting that code review is a net negative or that having a visual interface for reviewing a patch set brings out worse in people than emailing around patchsets? Code-bases, especially large ones “Must Be Attended To” and reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author and can present many good learning opportunities for both sides of it.
  - pydry 5y ago
    >Are suggesting that code review is a net negative Good god no. I'm, ironically enough, suggesting that misinterpretation of textual content is a bit of a problem :) >reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author I can remember hundreds of times I've seen textual code reviews that were "just critiquing code" that were interpreted as a critique of the author. It's particularly a problem when coders with slightly less social awareness than others write comments and don't pause to think how they might be interpreted. The example I gave in the comment above is just one of these.
- heurisko 5y ago
  > Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To. If you have good relationships with your colleagues/contributors, this will be reflected in the review process. If you have a bad relationship, the process will be painful. I don't think this is particularly a technology problem. GitHub also allows "comments" for points which are suggestions, rather than requirements.
franciscop 5y ago
As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "health" of a repository, things like the number or lifetime of issues play an important role. Even npm shows publicly (open) "Issues" and "Pull Requests". Well, if my project is working as intended, I like that people look at it and see the "Issues" count to be as close to 0 as possible. That's why I'm so excited/hopeful about Github Discussions, that seems like it was a huge hole in the whole Github and finally being addressed. A place to ask questions, meta questions, show YOUR issues using the library, etc. just a place to have conversations around the library. So you can leave the Issues for bug reports/potential issues. I closed the Issues tab in two of my most popular libraries because they just got low quality questions where devs were expecting me/others to basically fix their code/do their homework.
- onei 5y ago
  Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.
  - humanistbot 5y ago
    A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
  - 5y ago
georgyo 5y ago
I'm not sure you're implementation would actually be useful, and effectively you are doing the same thing as stalebot, just in a less obvious way. If you have 100 reports created in a month on a form, then it is very difficult to see what is triaged, who is working on what, and what still needs attention. The reporter wants something, which is by definition a task. The simple reports get resolved quickly, so you post a message saying that it is resolved. In a form that is now the top message. Other team members are more and more likely to click on already resolved issues at the top, which may not obviously be resolved. Eventually these resolved posts will age out and be paginated away, along with other non-resolved reports. The non-resolved reports are essentially closed by being stale. They have been aged out, and no one looks at old reports because they are mixed with things already actioned. People will still search the form, just as they do tickets, which is the same either way.
ryanbrunner 5y ago
I think it's possible to work this way while still having single issues - I usually like to do a two phase resolution of an issue. First, I triage issues - this should be done relatively quickly (within a day is a good target), and should involve reviewing the issue, determining whether it represents a genuine bug, a misunderstanding, a missing feature, etc., tries to identify where the problem might be occurring, and provides any workarounds, etc. That should happen on every issue without exception. Second is actually solving the issue, if it wasn't solved during triage. The 60 days can be useful here - as much as we all want to have bug free software, an issue that a single person encountered 60 days ago and hasn't been seen or reported by anyone since might just not be worth fixing or might not even exist anymore. Maybe it's unfair to users, but also keeping an issue open indefinitely can be equally unfair - if you're realistically not going to fix something, better that the user knows now. There's for sure cases where a single report is actually about multiple bugs, but that's relatively rare and I'm happy treating that as the exception rather than the rule.
- withinboredom 5y ago
  Or, what usually happens, is someone like me runs into the bug. I search the issues and find it closed. I consider the maintainer incompetent because the issue was reported and either fixed, but they obviously don’t have regression testing, or the don’t care about actually fixing bugs. Either way, I will probably seek out a different project if I can. If the issue is open, even for years, that’s totally different and understandable.
- notreallyserio 5y ago
  Does the stalebot check for recent reactions (thumbs up, etc) or just comments? I think it’s the latter, meaning it is closing issues others may have and know that “me too” replies are frowned upon.
CJefferson 5y ago
I wish github made it easier to seperate issues into different tabs -- while I can tag issues, by default you click on the 'issues' tab and see 100 (or 1000) issues, sorted by date. As you say, issues are bugs (which often need fixing ASAP), feature requests, general requests for help, etc. etc. It seem very hard to stop issues piling up to the point where you lose control out of them on any github project.
- swozey 5y ago
  I never had to use Github professionally until the last 2 years and it's horrible for anything but basic projects. Gitlab has "scoped" labels, for instance "db:mysql" or "mysql:bugfix" "mysql:performance", maybe one day Github will copy that or come up with something unique on their own but with the way github actions is going I don't see it happening. You can see examples of scoping here. "devops/create" etc, https://gitlab.com/gitlab-org/gitlab-docs/-/issues https://gitlab.com/gitlab-org/gitlab-docs/-/issues
  - DangitBobby 5y ago
    It's not perfect, but the GitHub CLI might help you with this. You can list issues filted by tags and potentially use your own tagging conventions to construct useful views.
    - swozey 5y ago
      I hadn't even considered their CLI. Thanks, I've been digging around at other repos examples a lot.

c7DJTLrn 5y ago

Yep. GitHub Issues is not a scrum board and shouldn't be treated as such. It's for consumers to discuss with authors and other consumers.

pc86 5y ago
If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.
- npteljes 5y ago
  Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.

pydry 5y ago

It's ironic that github sold itself as "social coding" coz while the design was pretty and the usability is good the social aspects are almost programmed to bring the worst out in people. Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To. It's not that it will ruin your relationships if you work with good people or vice versa but I've seen bad blood and insecurities exacetbated by the workflow that were unnecessary.

charrondev 5y ago
Are suggesting that code review is a net negative or that having a visual interface for reviewing a patch set brings out worse in people than emailing around patchsets? Code-bases, especially large ones “Must Be Attended To” and reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author and can present many good learning opportunities for both sides of it.
- pydry 5y ago
  >Are suggesting that code review is a net negative Good god no. I'm, ironically enough, suggesting that misinterpretation of textual content is a bit of a problem :) >reviews should be impersonal. A good review is inherently inspection and critiquing code, not the author I can remember hundreds of times I've seen textual code reviews that were "just critiquing code" that were interpreted as a critique of the author. It's particularly a problem when coders with slightly less social awareness than others write comments and don't pause to think how they might be interpreted. The example I gave in the comment above is just one of these.
heurisko 5y ago
> Their review workflow, for instance, is innately structured as a dehumanizing pipeline for delivering soundbites of impersonal criticism that Must Be Attended To. If you have good relationships with your colleagues/contributors, this will be reflected in the review process. If you have a bad relationship, the process will be painful. I don't think this is particularly a technology problem. GitHub also allows "comments" for points which are suggestions, rather than requirements.

franciscop 5y ago

As a OSS author, the problem is that other developers also treat issues as tasks. If you look at anywhere or any kind of rubric that tries to measure the "health" of a repository, things like the number or lifetime of issues play an important role. Even npm shows publicly (open) "Issues" and "Pull Requests". Well, if my project is working as intended, I like that people look at it and see the "Issues" count to be as close to 0 as possible. That's why I'm so excited/hopeful about Github Discussions, that seems like it was a huge hole in the whole Github and finally being addressed. A place to ask questions, meta questions, show YOUR issues using the library, etc. just a place to have conversations around the library. So you can leave the Issues for bug reports/potential issues. I closed the Issues tab in two of my most popular libraries because they just got low quality questions where devs were expecting me/others to basically fix their code/do their homework.

onei 5y ago
Maybe I'm different, but if the repo has some dozens of issues open, I take it as a sign of health. It means people are using it enough to find problems or ask for more features. If there's no issues, it tends to mean I'm treading on new, untested (or at least less tested) ground.
- humanistbot 5y ago
  A few dozen issues is one thing, but lots of the major OSS projects have thousands of open issues at any given time. If people think that each open issue is an unfixed bug or missing feature, then thousands of issues would mean that the project is at best unreliable and at worst fundamentally broken or dead. Except most of those issues are from users who should be asking questions on stack overflow.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
- 5y ago

georgyo 5y ago

I'm not sure you're implementation would actually be useful, and effectively you are doing the same thing as stalebot, just in a less obvious way. If you have 100 reports created in a month on a form, then it is very difficult to see what is triaged, who is working on what, and what still needs attention. The reporter wants something, which is by definition a task. The simple reports get resolved quickly, so you post a message saying that it is resolved. In a form that is now the top message. Other team members are more and more likely to click on already resolved issues at the top, which may not obviously be resolved. Eventually these resolved posts will age out and be paginated away, along with other non-resolved reports. The non-resolved reports are essentially closed by being stale. They have been aged out, and no one looks at old reports because they are mixed with things already actioned. People will still search the form, just as they do tickets, which is the same either way.

ryanbrunner 5y ago

I think it's possible to work this way while still having single issues - I usually like to do a two phase resolution of an issue. First, I triage issues - this should be done relatively quickly (within a day is a good target), and should involve reviewing the issue, determining whether it represents a genuine bug, a misunderstanding, a missing feature, etc., tries to identify where the problem might be occurring, and provides any workarounds, etc. That should happen on every issue without exception. Second is actually solving the issue, if it wasn't solved during triage. The 60 days can be useful here - as much as we all want to have bug free software, an issue that a single person encountered 60 days ago and hasn't been seen or reported by anyone since might just not be worth fixing or might not even exist anymore. Maybe it's unfair to users, but also keeping an issue open indefinitely can be equally unfair - if you're realistically not going to fix something, better that the user knows now. There's for sure cases where a single report is actually about multiple bugs, but that's relatively rare and I'm happy treating that as the exception rather than the rule.

withinboredom 5y ago
Or, what usually happens, is someone like me runs into the bug. I search the issues and find it closed. I consider the maintainer incompetent because the issue was reported and either fixed, but they obviously don’t have regression testing, or the don’t care about actually fixing bugs. Either way, I will probably seek out a different project if I can. If the issue is open, even for years, that’s totally different and understandable.
notreallyserio 5y ago
Does the stalebot check for recent reactions (thumbs up, etc) or just comments? I think it’s the latter, meaning it is closing issues others may have and know that “me too” replies are frowned upon.

CJefferson 5y ago

I wish github made it easier to seperate issues into different tabs -- while I can tag issues, by default you click on the 'issues' tab and see 100 (or 1000) issues, sorted by date. As you say, issues are bugs (which often need fixing ASAP), feature requests, general requests for help, etc. etc. It seem very hard to stop issues piling up to the point where you lose control out of them on any github project.

swozey 5y ago
I never had to use Github professionally until the last 2 years and it's horrible for anything but basic projects. Gitlab has "scoped" labels, for instance "db:mysql" or "mysql:bugfix" "mysql:performance", maybe one day Github will copy that or come up with something unique on their own but with the way github actions is going I don't see it happening. You can see examples of scoping here. "devops/create" etc, https://gitlab.com/gitlab-org/gitlab-docs/-/issues https://gitlab.com/gitlab-org/gitlab-docs/-/issues
- DangitBobby 5y ago
  It's not perfect, but the GitHub CLI might help you with this. You can list issues filted by tags and potentially use your own tagging conventions to construct useful views.
  - swozey 5y ago
    I hadn't even considered their CLI. Thanks, I've been digging around at other repos examples a lot.