7 ms·

I rely a lot on stale bot actually, simply because I don't like closing issues. When you do that, users sometimes get upset and you have to explain that this is

I rely a lot on stale bot actually, simply because I don't like closing issues. When you do that, users sometimes get upset and you have to explain that this is not a bug, or it's a duplicate of another bug, or that we use GitHub issues as a bug tracker, not for support, etc. Then the user might argue that it's not exactly the same bug, or that we should leave it open for reason x or y. It's a time consuming process that needs to be repeated very often when you manually close bugs. And it's mostly worthless because we know what we're doing - we know what will be worked on, what will be ignored. We just tag the issues that we'll work on and Stale Bot will skip these. So now I don't close anything anymore and let users get mad at Stale Bot instead. It's a bit weird but the end result is the same.

fistynuts 5y ago
What an odd point of view. It doesn't sound like you respect your users at all.
- shp0ngle 5y ago
  If you have even a mildly successful github repository, you will understand. People are weirdly entitled and feel like you really, really must fix the bug. Often with no real actual datapoints or way to reproduce. Still, auto-closing bots are annoying. But I see why people might want them
  - geerlingguy 5y ago
    And there are a ton of non-bug issues that people feel entitled to your time (as a maintainer) to respond to and help them. Often for many, many comments. Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc. We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
    - berkes 5y ago
      I don't think people are saying you should manually handle the deluge of issues. At least I'm not expecting this of anyone maintaining any Open Source, popular or not. (Thanks for your great Ansible work, BTW!). But how is auto-closing after X days a solution to "manually handling a deluge of issues"? Would, for example, it not be a much simpler and logical workflow to read those issues which you will handle manually and ignore all the rest? Why do they need to be closed?
      - laurent123456 5y ago
        > Why do they need to be closed? Likewise, why do they need to be open? Closed or open is just a state anyway, since the issue is still there. The fact that it's closed at least makes it clear that we won't deal with that issue (why we won't is explained in the template when the user creates the issue). If it stays open, we also won't dealt with it, but it will give the wrong impression that we might, some day.
        berkes 5y ago
        To me, closing sends a clear signal. I know it is not "deleted" but the signal is close to that. "Thanks for your work, but no thanks. And now shut up". Closing does not send the same signal as flagging, tagging or simply ignoring. Closing implies finality. It implies it's gone; and in fact it will be gone from most searches. Edit: to be clear: I don't mind someone closing my PR with a short explanation. Say "thanks for your Makefile, but since we have a lot of developers on Windows, we fear that switching to makefiles for our automation only adds to confusion. So I am closing this". this is very different from a bot coming in and closing such a PR. The latter signals to me "we are so overwhelmed that your help is not welcome so we sent a bot to keep you away from us. No-one even looked at the work you did for us. Now shut up" Tagging something as "backlog", "someday" or "low-prio" is a far different signal than closed. Maybe the root of the entire problem lies in the github-issues being too simple for large open source workflows. A lack or additional statuses, a lack of dimensions maybe. open/closed is one-dimensional, tags add a second dimension, and swimlanes when using GH projects a third. Maybe we need "read"/"ignored", or "team assignments" or such as additional dimension. Or maybe we need worked out templates for tagging-structures and workflows? (without it becoming another jira mess) Because clearly there is a need for workflows on top of Github, as can be seen by people pulling in bots that clearly piss off a lot of other people.
- laurent123456 5y ago
  If you define "respect" as personally responding to every user request, on a product used by thousands of people, then your definition of respect just doesn't scale.
  - jcelerier 5y ago
    > then your definition of respect just doesn't scale. ... why should respect be something that needs to scale ? it's fine to admit that this kind of respect itself does not scale when you're a single OSS maintainer.
- blueflow 5y ago
  Not gonna lie, many bug reports are not really useful. You need to "send them away" somehow without angering the users who opened them...
  - dudleypippin 5y ago
    It’s quite discouraging to stumble upon a well-written bug report that matches exactly an issue I’m having and see that it’s been “sent away”. I’m not getting angry, per se, but more disappointed and concerned that the project might not have enough resources to make me feel comfortable using it in the way I intended. (The one I’m thinking of was a cross-cloud app that obviously got more love on AWS than GCP. I got the feeling from the staled bugs that GCP was the “red-headed stepchild”, so we phased that app out after the POC.) I like the “bug reports are signals, not tasks” idea, though. As a user, I’ll keep that in mind and see if that helps change my gut reaction to the stalebot.
    - geerlingguy 5y ago
      Welcome to open source. Even projects that don't use the stale bot and let open issues rot forever "don't have enough resources". Case in point, look at projects like Drupal, with tens of thousands of open issues, a large portion of which are verifiable bugs. The problem is those bugs don't affect the right people to have them care about fixing them, so they'll just sit there open forever. At least the stale bot would signal "as a community of developers, this issue doesn't have enough interest or priority to get fixed".
- resizeitplz 5y ago
  What an odd point of view. It doesn't sound like you respect others' points of view at all. There's a far cry between disrespect and avoidance/minimization of challenging social interaction.
- remus 5y ago
  > It doesn't sound like you respect your users at all. I think that's a pretty harsh take. At the end of the day issue trackers are a tool for maintainers to help manage the project/codebase and the details are largely up to them. Im sure some maintainers also use it as a tool for communicating with users, but I don't think it should be compulsory. At the same time, if I as a user of a project add a bug then I do that as a favour to the maintainer. I don't think you should necessarily expect something back from the maintainer (assuming we're talking about open source here, not some payed service with an SLA etc.)
- whoknowswhat11 5y ago
  What an odd point of view. It doesn't sound like you as a user respect a maintainers free labor at all. This attitude is really the crux of it. Someone is working on a project, and has to argue - endlessly - with users who demand "respect" but don't contribute. Quick tip to users: The maintainers and bug tracker is generally not a support / training channel. The quickest way to get respect is to help out.
tessierashpool 5y ago
yeah, the really harmful thing is not the stale bot but the fact that people can open Issues in the first place. it's not a helpful feature at all. it assumes wildly inaccurate things about the people who are using it. every open source maintainer I know dreads the Issues UI, and only a few get anything useful out of it.
- remram 5y ago
  At least it's only issues. On GitLab, any random user can open Incidents against any repository. They haven't reached GitLab's focus on cramming in more features at the cost of maintainers' workflows yet.
- laurent123456 5y ago
  Yes we tried various things to better manage issues but there's just no easy solution when anybody can open issues. We have templates, clear explanations about what the issues are for (it's purely used as a bug tracker for us), we even say plainly that if your issue is a support or feature request, it's very likely to be ignored. But still, probably 90% of new issues are feature requests, support requests or duplicates. We've also considered closing the bug tracker altogether but in the end we prefer to leave it open for the 10% of issues we actually want to hear about.
Vinnl 5y ago
Here's something I don't understand: if you're already tagging the issues you'll work on, why go through the effort of closing the others? Can't you just filter by that tag to effectively "close" the non-tagged ones?
- darknavi 5y ago
  Not OP but curating a large backlog of items is a lot of work they smaller projects might not find worth it. I am not surprised many projects chose to automatically close inactive items. It's the epitome of "the squeaky wheel gets the grease".
  - Vinnl 5y ago
    Generally the amount of work should be equal, especially when, as in OPs case, the curation is already happening. But even when not already curating, what is effectively a simple rename could already prevent a lot of complaints: rather than automatically closing stale issues, you could either just have them tagged "Stale" and filter those out of your own view (if you prefer passively dealing with stale issues), or automatically tag all new issues as "Untriaged" and remove that tag if you want them to show up in your view (if you want more active curation).
- laurent123456 5y ago
  But what would be the value in leaving hundreds of open reports and nobody looking after them? Or do you mean some good bug reports are going to be missed because of this? Because in general if an issue is even moderately important, we'll hear about it via multiple channels - the issue tracker, the forum, Discord, etc. so we'll eventually be aware of it and there will be a proper bug report on the issue tracker. Either we'll select a good one among the duplicates, or we'll create one.
  - Vinnl 5y ago
    The "value" would be that nobody would be complaining about issues getting closed. Of course, that's just a small upside, but since I don't see any downside with it, I'm still wondering why one wouldn't do that.
scrollaway 5y ago
> So now I don't close anything anymore and let users get mad at Stale Bot instead. I can assure you I'm personally mad at whoever set up stalebot, not the bot or the people behind the idea itself. I have several high traffic repos, or repos that got very popular. The minute they're no longer manageable by myself, I've opened up the maintenance of the repository to more people than myself. If I stop showing up altogether in one of my repos I want it to keep breathing. This problem is easily solvable WITHOUT stalebot for all kinds of repositories up to the hyper-popular (tens of thousands of issues), at which point, there are still better ways to triage than with a stalebot. (Early in my career I used to triage for Wine, Webkit and later Chromium. It was fun. Stalebots didn't exist and would have been a dumb idea then, still are now.)
- deleted 5y ago
  [deleted]
bjourne 5y ago
If that strategy works for you then you should continue doing so. However, I noticed that in the read me for your project (https://github.com/laurent22/joplin https://github.com/laurent22/joplin) you are not explaining that this is how you handle bug reports. Perhaps as a courtesy to users you could add that? Then people like me who think that strategy is bonkers could avoid wasting our time by filing bug reports to your project.
- laurent123456 5y ago
  If you click on "New issue", it's explained there. We also have an issue template with more info.
  - bjourne 5y ago
    I can't see it. I also read the contributing file (https://github.com/laurent22/joplin/blob/dev/CONTRIBUTING.md https://github.com/laurent22/joplin/blob/dev/CONTRIBUTING.md) but I can't find it mentioned there either. You write that bug reports are "mostly worthless" to you so state that upfront?
    - deleted 5y ago
      [deleted]
lvass 5y ago
You're hindering your project because you don't want people getting upset with you. Sounds like you don't realize that, if you're acting in good faith, it's their fault they get upset, and it's nothing but harmful towards yourself to even care about something like this. This behavior, among other things, makes skimming through existing issues far less useful to anyone not actively working on the project. Which in turn leads to much worse new issue reports.
- laurent123456 5y ago
  It's not that much about caring, it's more about how to allocate time. If I have one hour to spare, do I want to spend it arguing with users over closed issues, or do I want to spend it to improve some feature or fix a bug?
  - deleted 5y ago
    [deleted]

fistynuts 5y ago

What an odd point of view. It doesn't sound like you respect your users at all.

shp0ngle 5y ago
If you have even a mildly successful github repository, you will understand. People are weirdly entitled and feel like you really, really must fix the bug. Often with no real actual datapoints or way to reproduce. Still, auto-closing bots are annoying. But I see why people might want them
- geerlingguy 5y ago
  And there are a ton of non-bug issues that people feel entitled to your time (as a maintainer) to respond to and help them. Often for many, many comments. Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc. We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
  - berkes 5y ago
    I don't think people are saying you should manually handle the deluge of issues. At least I'm not expecting this of anyone maintaining any Open Source, popular or not. (Thanks for your great Ansible work, BTW!). But how is auto-closing after X days a solution to "manually handling a deluge of issues"? Would, for example, it not be a much simpler and logical workflow to read those issues which you will handle manually and ignore all the rest? Why do they need to be closed?
    - laurent123456 5y ago
      > Why do they need to be closed? Likewise, why do they need to be open? Closed or open is just a state anyway, since the issue is still there. The fact that it's closed at least makes it clear that we won't deal with that issue (why we won't is explained in the template when the user creates the issue). If it stays open, we also won't dealt with it, but it will give the wrong impression that we might, some day.
      - berkes 5y ago
        To me, closing sends a clear signal. I know it is not "deleted" but the signal is close to that. "Thanks for your work, but no thanks. And now shut up". Closing does not send the same signal as flagging, tagging or simply ignoring. Closing implies finality. It implies it's gone; and in fact it will be gone from most searches. Edit: to be clear: I don't mind someone closing my PR with a short explanation. Say "thanks for your Makefile, but since we have a lot of developers on Windows, we fear that switching to makefiles for our automation only adds to confusion. So I am closing this". this is very different from a bot coming in and closing such a PR. The latter signals to me "we are so overwhelmed that your help is not welcome so we sent a bot to keep you away from us. No-one even looked at the work you did for us. Now shut up" Tagging something as "backlog", "someday" or "low-prio" is a far different signal than closed. Maybe the root of the entire problem lies in the github-issues being too simple for large open source workflows. A lack or additional statuses, a lack of dimensions maybe. open/closed is one-dimensional, tags add a second dimension, and swimlanes when using GH projects a third. Maybe we need "read"/"ignored", or "team assignments" or such as additional dimension. Or maybe we need worked out templates for tagging-structures and workflows? (without it becoming another jira mess) Because clearly there is a need for workflows on top of Github, as can be seen by people pulling in bots that clearly piss off a lot of other people.
laurent123456 5y ago
If you define "respect" as personally responding to every user request, on a product used by thousands of people, then your definition of respect just doesn't scale.
- jcelerier 5y ago
  > then your definition of respect just doesn't scale. ... why should respect be something that needs to scale ? it's fine to admit that this kind of respect itself does not scale when you're a single OSS maintainer.
blueflow 5y ago
Not gonna lie, many bug reports are not really useful. You need to "send them away" somehow without angering the users who opened them...
- dudleypippin 5y ago
  It’s quite discouraging to stumble upon a well-written bug report that matches exactly an issue I’m having and see that it’s been “sent away”. I’m not getting angry, per se, but more disappointed and concerned that the project might not have enough resources to make me feel comfortable using it in the way I intended. (The one I’m thinking of was a cross-cloud app that obviously got more love on AWS than GCP. I got the feeling from the staled bugs that GCP was the “red-headed stepchild”, so we phased that app out after the POC.) I like the “bug reports are signals, not tasks” idea, though. As a user, I’ll keep that in mind and see if that helps change my gut reaction to the stalebot.
  - geerlingguy 5y ago
    Welcome to open source. Even projects that don't use the stale bot and let open issues rot forever "don't have enough resources". Case in point, look at projects like Drupal, with tens of thousands of open issues, a large portion of which are verifiable bugs. The problem is those bugs don't affect the right people to have them care about fixing them, so they'll just sit there open forever. At least the stale bot would signal "as a community of developers, this issue doesn't have enough interest or priority to get fixed".
resizeitplz 5y ago
What an odd point of view. It doesn't sound like you respect others' points of view at all. There's a far cry between disrespect and avoidance/minimization of challenging social interaction.
remus 5y ago
> It doesn't sound like you respect your users at all. I think that's a pretty harsh take. At the end of the day issue trackers are a tool for maintainers to help manage the project/codebase and the details are largely up to them. Im sure some maintainers also use it as a tool for communicating with users, but I don't think it should be compulsory. At the same time, if I as a user of a project add a bug then I do that as a favour to the maintainer. I don't think you should necessarily expect something back from the maintainer (assuming we're talking about open source here, not some payed service with an SLA etc.)
whoknowswhat11 5y ago
What an odd point of view. It doesn't sound like you as a user respect a maintainers free labor at all. This attitude is really the crux of it. Someone is working on a project, and has to argue - endlessly - with users who demand "respect" but don't contribute. Quick tip to users: The maintainers and bug tracker is generally not a support / training channel. The quickest way to get respect is to help out.

tessierashpool 5y ago

yeah, the really harmful thing is not the stale bot but the fact that people can open Issues in the first place. it's not a helpful feature at all. it assumes wildly inaccurate things about the people who are using it. every open source maintainer I know dreads the Issues UI, and only a few get anything useful out of it.

remram 5y ago
At least it's only issues. On GitLab, any random user can open Incidents against any repository. They haven't reached GitLab's focus on cramming in more features at the cost of maintainers' workflows yet.
laurent123456 5y ago
Yes we tried various things to better manage issues but there's just no easy solution when anybody can open issues. We have templates, clear explanations about what the issues are for (it's purely used as a bug tracker for us), we even say plainly that if your issue is a support or feature request, it's very likely to be ignored. But still, probably 90% of new issues are feature requests, support requests or duplicates. We've also considered closing the bug tracker altogether but in the end we prefer to leave it open for the 10% of issues we actually want to hear about.

Vinnl 5y ago

Here's something I don't understand: if you're already tagging the issues you'll work on, why go through the effort of closing the others? Can't you just filter by that tag to effectively "close" the non-tagged ones?

darknavi 5y ago
Not OP but curating a large backlog of items is a lot of work they smaller projects might not find worth it. I am not surprised many projects chose to automatically close inactive items. It's the epitome of "the squeaky wheel gets the grease".
- Vinnl 5y ago
  Generally the amount of work should be equal, especially when, as in OPs case, the curation is already happening. But even when not already curating, what is effectively a simple rename could already prevent a lot of complaints: rather than automatically closing stale issues, you could either just have them tagged "Stale" and filter those out of your own view (if you prefer passively dealing with stale issues), or automatically tag all new issues as "Untriaged" and remove that tag if you want them to show up in your view (if you want more active curation).
laurent123456 5y ago
But what would be the value in leaving hundreds of open reports and nobody looking after them? Or do you mean some good bug reports are going to be missed because of this? Because in general if an issue is even moderately important, we'll hear about it via multiple channels - the issue tracker, the forum, Discord, etc. so we'll eventually be aware of it and there will be a proper bug report on the issue tracker. Either we'll select a good one among the duplicates, or we'll create one.
- Vinnl 5y ago
  The "value" would be that nobody would be complaining about issues getting closed. Of course, that's just a small upside, but since I don't see any downside with it, I'm still wondering why one wouldn't do that.

scrollaway 5y ago

> So now I don't close anything anymore and let users get mad at Stale Bot instead. I can assure you I'm personally mad at whoever set up stalebot, not the bot or the people behind the idea itself. I have several high traffic repos, or repos that got very popular. The minute they're no longer manageable by myself, I've opened up the maintenance of the repository to more people than myself. If I stop showing up altogether in one of my repos I want it to keep breathing. This problem is easily solvable WITHOUT stalebot for all kinds of repositories up to the hyper-popular (tens of thousands of issues), at which point, there are still better ways to triage than with a stalebot. (Early in my career I used to triage for Wine, Webkit and later Chromium. It was fun. Stalebots didn't exist and would have been a dumb idea then, still are now.)

deleted 5y ago
[deleted]

bjourne 5y ago

If that strategy works for you then you should continue doing so. However, I noticed that in the read me for your project (https://github.com/laurent22/joplin https://github.com/laurent22/joplin) you are not explaining that this is how you handle bug reports. Perhaps as a courtesy to users you could add that? Then people like me who think that strategy is bonkers could avoid wasting our time by filing bug reports to your project.

laurent123456 5y ago
If you click on "New issue", it's explained there. We also have an issue template with more info.
- bjourne 5y ago
  I can't see it. I also read the contributing file (https://github.com/laurent22/joplin/blob/dev/CONTRIBUTING.md https://github.com/laurent22/joplin/blob/dev/CONTRIBUTING.md) but I can't find it mentioned there either. You write that bug reports are "mostly worthless" to you so state that upfront?
  - deleted 5y ago
    [deleted]

lvass 5y ago

You're hindering your project because you don't want people getting upset with you. Sounds like you don't realize that, if you're acting in good faith, it's their fault they get upset, and it's nothing but harmful towards yourself to even care about something like this. This behavior, among other things, makes skimming through existing issues far less useful to anyone not actively working on the project. Which in turn leads to much worse new issue reports.

laurent123456 5y ago
It's not that much about caring, it's more about how to allocate time. If I have one hour to spare, do I want to spend it arguing with users over closed issues, or do I want to spend it to improve some feature or fix a bug?
- deleted 5y ago
  [deleted]