5 ms·

> Despite how much some people detest the stale bot [...] I detest the stale bot :-) And I really think it only is a disservice to the project, 99% times I se

by j1elo 5y ago

> Despite how much some people detest the stale bot [...] I detest the stale bot :-) And I really think it only is a disservice to the project, 99% times I see it used. If the code has a genuine, real defect, it will not "go away" magically just because nobody complained again, or the authors didn't have time to look on it. See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue. I really hate when googling about some problem and then finding a promising bug tracker conversation that then... got comments closed because of old age. That's literally swiping the problem under the rug. Now regarding burnout and burden of OSS maintainers, I might lack a bit of empathy here, but I just don't get it. Really the license text says it all: THIS PROJECT IS OFFERED AS-IS. Most if not all OSS licenses have a phrase like this. Just quote those words 100 times if it's needed. My mental health as an OSS maintainer is very well and I cannot see it being changed by some, even lots, of demanding users at any point. Every time someone takes my code and uses it, there is an implicit conversation where I go "hey, here you are take this work for free, I'm lending it to you AS-IS, do whatever you want with it!". Absolutely at no point in time I feel pressure about defects in the code, after having this imaginary conversation. I guess we need more spreading of the notion of "not giving a sh*t" so the idea gets extended to more and more OSS maintainers, helping them have a happy life not encumbered by the work they decided to release by sheer goodness. EDIT: with this last phrase I mean that one should have the mentality of contributing up to, and not more, what one is able to do within their own limits. The "not caring" I mention is for after reaching this limit: it will help not pushing through the burnout line, and thus as a result being happier in the long term.

corndoge 5y ago
Your latter point doesn't make a lot of sense to me. I write and maintain open source software because I enjoy seeing people use it. For me, not giving a shit about it means not working on it at all. It seems like it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra but in reality that just doesn't work for me. And I bet I'm not so different from most foss maintainers.
- j1elo 5y ago
  > it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra It definitely is. Of course OSS authors and maintainers want to see people using and enjoying it, but nothing is black or white. What you really mean is that you want people using and enjoying your software within the limits of time and abilities that you can employ on it without it affecting your mental health. Some people are worse than others at finding out about this latter part, and as a consequence they suffer. My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it. I.e., be in a defensive mental state. Ironically, it will make you work happier and over a longer period of time, which ends up being positive for the health of the project itself.
  - corndoge 5y ago
    > It definitely is I just told you that for me, it's not. Repeating your view isn't adding anything. Restating it doesn't make it so. I understood you the first time. > My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it. I completely believe that's how the mental process works for you. That's not how it works for me. If I detach myself from the project enough to not let it affect my mental state then I do zero work on that project.
    - j1elo 5y ago
      I see. Not being able to detach your mental process from an overburdened project probably means that you are more prone to suffer the kind of issues discussed every time this topic is brought up. Caution is advised, I guess. You might be able to perfectly handle your OSS projects despite of this tendency, you probably have your own complementary techniques (like limiting the number of simultaneously accepted PRs at any given time? I'd be interested if you want to share any), or if a bad wave of burden arrives one day, you might end up burning out and either throwing the towel or growing a thicker skin. Hopefully the latter!
pictur 5y ago
"See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue." I think this is really important. In some projects, the number of open issues is always zero. Most people see this as a good thing. I think it is not. we need projects where there are hundreds of open issues and these issues are visible. it is important to solve problems if they want to be followed clearly. I think it is a very important issue to be able to follow up the problems clearly.
- b3morales 5y ago
  Absolutely. If nothing else, the issue report establishes a findable, centralized location for users to share workarounds with each other.
kibwen 5y ago
If you don't like how some open-source library is managed, then exercise your freedom to fork it. Anyone who then claims that they don't have the time or energy to maintain such a fork cannot also reasonably expect anyone else to spend their own time and energy maintaining it for them.
- Aethylia 5y ago
  It isn't more work for the maintainer to _not_ close issues purely based on time. This argument has been repeated often. And with the prevalence of lazily-used stale bots, it's not feasible for anyone to make all the forks necessary. Discussion can eventually lead to a shift, repeating this argument can't.
  - kibwen 5y ago
    > It isn't more work for the maintainer to _not_ close issues purely based on time This overlooks the emotional burden of having a large, unbounded backlog. When I see that I have a missed call, I feel an obligation to call that person back. When I see that I have a text, or a DM, or an email, I feel an obligation to respond. Individually these are all minor obligations, but in aggregate they eventually coalesce into anxiety. PRs, too, get thrown onto this pile. Burnout is a self-imposed "boiling the frog slowly" scenario caused by gradually taking on more responsibility than you can successfully deal with. Realistic ways to prevent burnout are by either aggressively preventing new obligations from being thrown onto the pile, or by periodically defaulting on obligations and resetting the pile entirely. It appears to me that the stale bot is an instance of the latter. An instance of the former would be to just outright forbid PRs entirely. And if anyone thinks that they have the mental fortitude to handle an ever-growing and unbounded pile of obligations, then that only reiterates the call for them to fork these projects and accept the burden personally.
    - BeFlatXIII 5y ago
      I've solved that problem by being one of those people who never calls back or checks voicemail. At some point, I've got 75 e-mails to mark as read and delete today.
geerlingguy 5y ago
I mark bugs, security-related issues, and planned features with appropriate labels, and the stale bot ignores those: https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/stale.yml#L15 https://github.com/geerlingguy/ansible-role-docker/blob/mast... Not all maintainers do the same. And some even _lock issues_, which I hate, because even closed issues can have a very fruitful discussion long after the issue was originally posted.
- j1elo 5y ago
  Then you are, in my humble opinion, doing it exactly right :-) (apart from going all-in and just never closing anything, but yours is a very good middle ground) > even closed issues can have a very fruitful discussion long after the issue was originally posted 100% agree! In some occasions I've learned a lot from reading long related conversations in a bug report that had been closed or resolved long since.
- mkeedlinger 5y ago
  TIL that my hatred of stale bot is somewhat misplaced, because it seems that it can be configured in a way I think is a lot more acceptable. Shame when it's set to be aggressive, it can be a serious hindrance. Issues almost act like a user forum, and can be super useful even if the maintainer doesn't want to put energy into that particular issue. I've found some really helpful work-arounds in "stale" issues.
skybrian 5y ago
A bug report is an observation about a particular version. If nobody bothers to test newer versions, you don't know if it's real. The more the code changes, the less likely the behavior is still there. Now, granted, it's likely that if nobody did anything then it's still broken, but it's still the case that a bug database, considered as documentation, gradually becomes outdated and increasingly misleading if not maintained. Stale bugs are still in the database and you can still query them. Nothing is lost. The question is how relevant old history is when it comes up in search results? Maybe querying on open bugs only is the wrong default? Stale bugs should probably be included but with much decreased rank.
- j1elo 5y ago
  I agree with this, too. Which opens up a nice point of discussion: closing stale bugs is bad because it sweeps the issue under the rug; but closing them is good in case the context and source code around the issue has changed a lot. In this case I'm not sure what's the best solution. I have suffered myself finding an open bug but so old that it didn't really apply any more. However in those cases, it has happened that attracting attention from a dev, or just testing by myself, has driven the conversation into quickly realizing that the issue didn't apply any more with current state of the source code... Maybe it's a good idea having the feature of specifying which version the bug was reported against. GitHub doesn't have this, but I've seen it in some other bug trackers.
  - toast0 5y ago
    In an ideal world, someone would go over the open bugs on some timeline and mark them as no longer an issue, still an issue, don't know, or won't fix. An easy timeline to specify would be take a look 3 months after last activity and double the wait every time. Of course, that takes time and effort and some bugs are harder to evaluate than others.
    - skybrian 5y ago
      Typically this gets bounced back to the person who reported the bug and if they don’t care (and why should they if they moved on) then nobody does it.
AnIdiotOnTheNet 5y ago
If I encounter a bug in a thread closed by a stalebot, my natural conclusion is that the developers have no intention or desire to ever fix the bug. This usually leads me to searching for alternatives rather than wasting my time re-reporting it.

by j1elo 5y ago

corndoge 5y ago

Your latter point doesn't make a lot of sense to me. I write and maintain open source software because I enjoy seeing people use it. For me, not giving a shit about it means not working on it at all. It seems like it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra but in reality that just doesn't work for me. And I bet I'm not so different from most foss maintainers.

j1elo 5y ago
> it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra It definitely is. Of course OSS authors and maintainers want to see people using and enjoying it, but nothing is black or white. What you really mean is that you want people using and enjoying your software within the limits of time and abilities that you can employ on it without it affecting your mental health. Some people are worse than others at finding out about this latter part, and as a consequence they suffer. My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it. I.e., be in a defensive mental state. Ironically, it will make you work happier and over a longer period of time, which ends up being positive for the health of the project itself.
- corndoge 5y ago
  > It definitely is I just told you that for me, it's not. Repeating your view isn't adding anything. Restating it doesn't make it so. I understood you the first time. > My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it. I completely believe that's how the mental process works for you. That's not how it works for me. If I detach myself from the project enough to not let it affect my mental state then I do zero work on that project.
  - j1elo 5y ago
    I see. Not being able to detach your mental process from an overburdened project probably means that you are more prone to suffer the kind of issues discussed every time this topic is brought up. Caution is advised, I guess. You might be able to perfectly handle your OSS projects despite of this tendency, you probably have your own complementary techniques (like limiting the number of simultaneously accepted PRs at any given time? I'd be interested if you want to share any), or if a bad wave of burden arrives one day, you might end up burning out and either throwing the towel or growing a thicker skin. Hopefully the latter!

pictur 5y ago

"See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue." I think this is really important. In some projects, the number of open issues is always zero. Most people see this as a good thing. I think it is not. we need projects where there are hundreds of open issues and these issues are visible. it is important to solve problems if they want to be followed clearly. I think it is a very important issue to be able to follow up the problems clearly.

b3morales 5y ago
Absolutely. If nothing else, the issue report establishes a findable, centralized location for users to share workarounds with each other.

kibwen 5y ago

If you don't like how some open-source library is managed, then exercise your freedom to fork it. Anyone who then claims that they don't have the time or energy to maintain such a fork cannot also reasonably expect anyone else to spend their own time and energy maintaining it for them.

Aethylia 5y ago
It isn't more work for the maintainer to _not_ close issues purely based on time. This argument has been repeated often. And with the prevalence of lazily-used stale bots, it's not feasible for anyone to make all the forks necessary. Discussion can eventually lead to a shift, repeating this argument can't.
- kibwen 5y ago
  > It isn't more work for the maintainer to _not_ close issues purely based on time This overlooks the emotional burden of having a large, unbounded backlog. When I see that I have a missed call, I feel an obligation to call that person back. When I see that I have a text, or a DM, or an email, I feel an obligation to respond. Individually these are all minor obligations, but in aggregate they eventually coalesce into anxiety. PRs, too, get thrown onto this pile. Burnout is a self-imposed "boiling the frog slowly" scenario caused by gradually taking on more responsibility than you can successfully deal with. Realistic ways to prevent burnout are by either aggressively preventing new obligations from being thrown onto the pile, or by periodically defaulting on obligations and resetting the pile entirely. It appears to me that the stale bot is an instance of the latter. An instance of the former would be to just outright forbid PRs entirely. And if anyone thinks that they have the mental fortitude to handle an ever-growing and unbounded pile of obligations, then that only reiterates the call for them to fork these projects and accept the burden personally.
  - BeFlatXIII 5y ago
    I've solved that problem by being one of those people who never calls back or checks voicemail. At some point, I've got 75 e-mails to mark as read and delete today.

geerlingguy 5y ago

I mark bugs, security-related issues, and planned features with appropriate labels, and the stale bot ignores those: https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/stale.yml#L15 https://github.com/geerlingguy/ansible-role-docker/blob/mast... Not all maintainers do the same. And some even _lock issues_, which I hate, because even closed issues can have a very fruitful discussion long after the issue was originally posted.

j1elo 5y ago
Then you are, in my humble opinion, doing it exactly right :-) (apart from going all-in and just never closing anything, but yours is a very good middle ground) > even closed issues can have a very fruitful discussion long after the issue was originally posted 100% agree! In some occasions I've learned a lot from reading long related conversations in a bug report that had been closed or resolved long since.
mkeedlinger 5y ago
TIL that my hatred of stale bot is somewhat misplaced, because it seems that it can be configured in a way I think is a lot more acceptable. Shame when it's set to be aggressive, it can be a serious hindrance. Issues almost act like a user forum, and can be super useful even if the maintainer doesn't want to put energy into that particular issue. I've found some really helpful work-arounds in "stale" issues.

skybrian 5y ago

A bug report is an observation about a particular version. If nobody bothers to test newer versions, you don't know if it's real. The more the code changes, the less likely the behavior is still there. Now, granted, it's likely that if nobody did anything then it's still broken, but it's still the case that a bug database, considered as documentation, gradually becomes outdated and increasingly misleading if not maintained. Stale bugs are still in the database and you can still query them. Nothing is lost. The question is how relevant old history is when it comes up in search results? Maybe querying on open bugs only is the wrong default? Stale bugs should probably be included but with much decreased rank.

j1elo 5y ago
I agree with this, too. Which opens up a nice point of discussion: closing stale bugs is bad because it sweeps the issue under the rug; but closing them is good in case the context and source code around the issue has changed a lot. In this case I'm not sure what's the best solution. I have suffered myself finding an open bug but so old that it didn't really apply any more. However in those cases, it has happened that attracting attention from a dev, or just testing by myself, has driven the conversation into quickly realizing that the issue didn't apply any more with current state of the source code... Maybe it's a good idea having the feature of specifying which version the bug was reported against. GitHub doesn't have this, but I've seen it in some other bug trackers.
- toast0 5y ago
  In an ideal world, someone would go over the open bugs on some timeline and mark them as no longer an issue, still an issue, don't know, or won't fix. An easy timeline to specify would be take a look 3 months after last activity and double the wait every time. Of course, that takes time and effort and some bugs are harder to evaluate than others.
  - skybrian 5y ago
    Typically this gets bounced back to the person who reported the bug and if they don’t care (and why should they if they moved on) then nobody does it.

AnIdiotOnTheNet 5y ago

If I encounter a bug in a thread closed by a stalebot, my natural conclusion is that the developers have no intention or desire to ever fix the bug. This usually leads me to searching for alternatives rather than wasting my time re-reporting it.