12 ms·

Closing issues automatically after a certain period of time is a disastrously stupid thing to do for a bug tracker that helps no one (not users, not reporters,

Closing issues automatically after a certain period of time is a disastrously stupid thing to do for a bug tracker that helps no one (not users, not reporters, not maintainers), and is actually counterproductive in systems where search excludes closed issues by default (which is most of them), because you’re certain to end up with more duplicates. There are other types of trackers where automatic closure can be justified, but a bug tracker is not one of them. I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice.

dawnerd 5y ago
Worse is when they prevent you from reopening or if you comment after it’s closed you get a rude response to open a new ticket.
- heinrichhartman 5y ago
  I can get behind closing stale issues, to a certain degree, but this practice sound straight-out stupid: Why would you discard the context of a previews discussion?
  - TeMPOraL 5y ago
    At the risk of spinning of a tangent flamewar: this ties into a wider issue that boggles my mind to this day - the concept of "necroposting" as something negative. People will commonly want to eat you alive if you post a new reply under a stale discussion thread, but that reaction feels really dumb. The old context is useful.
    - travisjungroth 5y ago
      Agree for intelligent discourse about a slow-moving topic. Disagree for conversations about personal opinions (most of forums), especially ones with time context. When you post on a three year old thread, everyone else has left the room. That's fine if you want to share how you finally got this old sound card working on a specific OS, lame if there was a lively discussion about working at Lyft versus Uber.
      - lucideer 5y ago
        Firstly there's a 3rd type: someone asks for help and you post a suggested solution 3 years later. Extremely useful for all the lurkers who also had the same question and are reading looking for possible solutions. But secondly, even your own counterexample I don't think checks out. If I'm browsing your forum & interested in perspectives on working at Lyft v Uber, I absolutely want to read a recent update and contrast that with what people thought 3 yrs ago v now. Tbh, the "I got my sound card working" post seems least appropriate of them all (but still ok to do imo, necroposts are good)
        travisjungroth 5y ago
        My sound card example was supposed to be like your 3rd type, so we agree there. Old and current experiences are definitely both valuable. Just start a new thread. It's too easy for other members to miss the dates when it comes back to the top. Then they're reading and responding to old posts from absent people like they're here and now.
    - wott 5y ago
      > boggles my mind to this day - the concept of "necroposting" as something negative. I never understood it either. I mean, as a religion. What is even sillier, is that as far as web forums are concerned, you have 50% of them which will go mad if you "necropost", and the other 50% which will go mad if you open a new thread when there is already an existing thread on the same topic (even buried), because these have the exact opposite written or unwritten rule. The latter ones love their 800 pages long topics; the former ones forbid you to follow up with a discussion even when it is the exact same topic, if the discussion stopped for a while.
      - TeMPOraL 5y ago
        You know what beats that still? I've been using a few boards where people believed in both these things at the same time. So when a topic stalled, it was nigh-impossible to resume it later.
        wott 5y ago
        Ah! :) I've seen something a bit like that: moderators who would come down hard on people who ask a question, both in an old thread or a new one (because the first time they were told not to create new threads or not to necropost so they tried again, following the advice, in the opposite manner), by telling them "why can't you search the fucking forum 2 minutes before digging an old thread / creating a new thread, stupid; this has been answered multiple times: here, here and here; topic locked", and of course none of the links he gives does answer the specific problem the posters had and clearly specified, because the mod didn't spend the said 2 minutes reading the posters' questions and just stupidly copied the first search results in the rush he had to punish the intruders. So, when you hit the same problems as the posters, you are out of luck, because their questions were not answered before, and they will never be.
        kergonath 5y ago
        I have seen this unfortunate behaviour in mailing lists for some Open Source software as well. Gatekeepers with anger issues and too much time on their hand (but not enough to actually answer the question). Sometimes I wish these people realised how hostile they are and unwelcoming to new users and potential contributors, but maybe that’s the point. The result is ~10 relevant hits when you Google an error message with not a single useful solution.
    - twic 5y ago
      There's at least one forum out there where necroposting is actually valued by the culture. It's considered cool and fun to make a relevant post on a thread that was last updated five years ago. I love that.
      - smeyer 5y ago
        Which forum?
    - alpaca128 5y ago
      For me the reason I see it mostly as something negative is because most necroposts are pointless. They're often only written because the author forgot to check the date and thus didn't realise their comment won't contribute anything useful. Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists.
      - lucideer 5y ago
        but that's just a reasonable response to a specific type of comment, not a general defense of banning necroposts outright. The reason the term exists is because it's a blanket rule based on the age of the reply, not based on the intent or context.
        chc 5y ago
        The blanket rule is because even "good" necroposts tend to encourage bad ones. If I'm on an active forum and I revive some ancient discussion with a useful comment, lots of people will click on the thread and try to argue with the old posts. The generally recommended alternative is to make a new thread and simply link to the old one so you don't confuse people.
      - TeMPOraL 5y ago
        > the author forgot to check the date and thus didn't realise their comment won't contribute anything useful I have a different view of those in most cases - particularly on large, or publicly accessible, boards. That comment may not contribute anything useful for the people previously involved, but it may very well be useful for everyone else - such as any person that finds the thread through a search engine. > Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists. That's a specific case about one-upping someone much later, but a more generalized case - posting modern solution under unresolved problem thread - is very valuable for people who find the thread looking for a solution. Conversely, blanket ban on "necroposting" discourages accumulation of knowledge on tough problems. See also: https://xkcd.com/979/ https://xkcd.com/979/
    - detaro 5y ago
      If the old context is useful, sure. but it often isn't, and that's what causes people to dislike necroposting. But without a specific policy/instance in mind discussing this is a bit moot, since everyone has a different level of reasonableness in mind.
  - strogonoff 5y ago
    I don’t think “necroposting” is something inherently bad[0], but specifically insisting (or expecting) that open-source project maintainer remembers a 100-screen thread every time anyone wants to bring it up is IMO ill-mannered. A random person online invests an afternoon to read through a years old issue thread and decides to comment, expecting the maintainer to reply. Meanwhile, maintainer has dozens of such issues, and dozens of frustrated users bringing up each of them every week. Asking the submitter to respect a previously made maintainer’s decision, file a new issue and invest their own time to concisely summarize the status quo seems only fair. In other words, diverting discussion to a new thread is a chance to compress old context into a short summary, like you would squash a Git history—except in this case the old closed issue thread is fully linkable and isn’t going anywhere. [0] That said, it depends on maintainer’s personality. I can see how some could feel losing control and demoralised by ever-evolving difficult-to-track discussions on previously closed issues.
    - lucideer 5y ago
      You're right that this behaviour is bad and I know that what you describe happens but it seems like a strawman argument in the context of this discussion. What you describe is about the community respecting foss maintainers; closing tickets is not going to solve this problem.
      - strogonoff 5y ago
        I was responding to the point about comments piling on a closed issue. It is not bad by default, but still there can be valid reasons for maintainers to discourage it. Whether an issue should be closed or should be allowed to be re-opened by the public is not even up to debate as far as I’m concerned, this is up to maintainer’s policy.
MrOxiMoron 5y ago
not searching closed issues is always bad, things that are fixed in a newer version or after long discussion are closed as won't fix won't be found either
Jenk 5y ago
Meh. It's just a method of filtration. When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little in the way of automatic triage determining the priority it is a borderline impossible task to wade through them. Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.
- tinus_hn 5y ago
  It’s fine, as long as the time he submitter spent to write a decent bug report is worthless to you.
  - frereubu 5y ago
    That's a straw man. It's a balance between your time and theirs, and I presume you don't think that all bug reports are carefully considered and well-written. Many are even obtuse, aggressive and self-entitled. I'd bet most well-written, civil bug reports are at least taken seriously, even if they end up as a wontfix.
    - tinus_hn 5y ago
      You don’t need to wait for a certain period of time to decide that a bug report is poorly written.
    - ForHackernews 5y ago
      There's nearly zero cost to leaving a stale bug report open. A few kB, and maybe not even that because closed tickets are rarely actually deleted. If you're not working on a bug, then, by definition, it's not taking up your time. Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
      - thaumasiotes 5y ago
        > But closing tickets and fixing bugs are not the same thing. You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D
frereubu 5y ago
In an ideal world I'd agree with you, but if you or your team don't have the time to fix every bug - some of which will not be critical - then having a mass of open issues pile up often leads to people being overwhelmed and fixing even fewer. Also, over time, some issues are superceded by changes elsewhere so they become moot anyway.
- bayindirh 5y ago
  Why not move them to a low visibility category like a back-burner? Some long standing problems get progressively easier to fix when the blockers around a bigger problem gets conquered slowly due to requirements.
lloydatkinson 5y ago
1000% this. The lodash library for Javascript had the authoritarian dictatorship extreme version of this for the longest time. Any issue was immediately closed and only closed issues would be reopened if enough people gave said closed issue enough thumbs up (and "enough" wasn't even defined). And of course, this process wasn't explained anywhere except in replies to closed issues. The obvious problem with this was that no issues were ever acted upon ever because no one ever looked at closed issues, because why would they? I had created a proposal for a new function to be added that was and still is sorely missing. After it was closed and a long discussion ensued between many devs, I gave up and a year later I simply replied that I retract the proposal due to the ridiculous policy of actively being hostile to users. The maintainer deleted the whole issue and along with it all proof of their hostility and hypocrisy. It was then that I decided I would boycott lodash and simply use better libraries in my projects now like Ramda, which is actually OSS. Looks like lodash is now no longer maintained and has hundreds of tickets open after the hostile maintainer (and it's not hard to guess who from looking at the commit counts) appears to have stopped maintaining it. Funny how that works, closing tickets constantly ensures no one will want to help, and then the maintainers feel overwhelmed because they are doing it alone. Basically closing issues is an awful practice that helps no one, as you say.
- goldenkey 5y ago
  Don't forget that Lodash was basically JDalton's rip of Underscore.js. There used to be a mention of it, since the selling point was benchmarks. Now, I don't see any mention of Underscore...
  - capableweb 5y ago
    Not sure I'd call it a "rip", "ripping" for me is associated with "ripping media" which is copying video/music/data from CDs to local hardware. Lodash is more of a re-implementation of a MIT library, not something that should be shameful. As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.
Arathorn 5y ago
+1E100. On a busy project it's disasterous if long-lived chronic bugs which are serious enough to be tracked in the first place, but have never quite made it to the top of the todo list, randomly got closed for no good reason. This issue is a classic case in point. We have too many similar ones on Matrix (but which we've been slowly working through over the years).
fn1 5y ago
This came up in the javascript-world.
rvz 5y ago
> I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice. Imagine if the Linux kernel or even Chromium had stale bots closing reported vulnerabilities everywhere. It's like they are burying bugs waiting to be exploited by drive-by security researchers.
- handrous 5y ago
  Android, notoriously, does this. When (not if) you hit an Android bug while developing an app, more than likely you'll find it closed as stale. Luckily they don't usually block comments, so you'll get to see confirmation from within the last few weeks that you're not crazy and this bug is still present, and maybe some up-to-date workarounds if you're lucky.
zaphirplane 5y ago
I disagree for bugs in volunteer open source because it requires someone to triage it and recreate the bug cross versions. Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid The process of closing it means pushes that work back on the users obviously this requires the coders to keep an eye on the bugs and assess their importance Having 8000 bugs cross 10 years with ancient versions helps no one FWIW In this case it’s a feature request
- CRConrad 5y ago
  > Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid This sentence missing lot grammar. So much so that I really can't even see which direction of the argument it's arguing for or against.
bassdropvroom 5y ago
I disagree. It entirely depends on the behaviour. I've lost count of the number of tickets that have been raised that has no information, or is not reproducible, or something else. When I then ask for more information, or something else, they never reply. I've no incentive to keep such tickets open. So I set up stale bot and auto-close the tickets. Individuals can come and re-open if it happens to them, or more information is added. Now I do agree, if it is a genuine issue, then it shouldn't be closed until it is sorted out it. So you can set up stale bot to ignore labelled or something. So that's how I've set up all of my repos. For me this has taken off a huge burden. I don't agree with locking threads after they've closed though. There is very little reason to do so.
- eptcyka 5y ago
  This is different from closing legitimate bugs/issues that are well described and testable, just not fixed.
  - bassdropvroom 5y ago
    That's right. It's all use-case based. Indiscriminately closing issues automatically is definitely wrong. Automatically closing issues that cannot be reproduced or have other issues is a perfect use-case for stale bot.
    - eptcyka 5y ago
      Show me a bot that can tell the difference between a testable and well described bug and one that's affecting lots of users but has bad descriptions.
      - bassdropvroom 5y ago
        Using GitHub's stale bot you can set it to ignore labelled issues, and so it's up to maintainer to label things correctly. Once the maintainer does so, stale bot won't touch it.
jlarcombe 5y ago
Amen. About once a year I spend an entire day reopening bugs in the Qt bug tracker while somewhere in Finland someone is sitting there closing them, like a sort of really annoying game. The process consists of (a) downloading the minimal test app attached to the bug, (b) making a trivial change to get it building with the latest Qt, and (c) reopening the bug with the remark "this still happens in Qt X.latest". Unfortunately I can't quite do this as fast as they can close them...
arghwhat 5y ago
It depends solely on the definition of "stale". An issue where the reporter is unreachable and developers do not have local reproduction should absolutely be closed as it serves no function other than generating noise in the issue tracker. Open issues is a liability to overview and planning, and having bad open issues is therefore directly harmful to maintainers, reporters and users. Closing a bad but ultimately real issue will just make way for a possibly good report to take it's place (i.e. a new reporter rather an old unresponsive one) so it only provides benefit.
xattt 5y ago
It helps people gain a sense of productivity when a lot of yak shaving place.
johnchristopher 5y ago
As a bug reporter I take it very personally when it happens to me. When I try to debug a problem and I see it has already been reported and closed due to inactivity (that is :not fixed. Not tagged won't fix) I give up, I won't fight the machine.
mumblemumble 5y ago
In general I don't disagree, but I'd moderate the position with context. For projects that have some sort of product manager who is personally in charge of managing and perhaps de-duplicating the tickets, I'd leave the choice up to them. Some like having only one ticket that captures all discussion about an issue. Some don't care, and aren't so worried about losing track of comments from several years ago. That feels to me like a work style issue, and I don't need to tell them how to do their job. Or, for projects that are working with an issue tracking system that makes it really difficult to juggle large numbers of open tickets, I also see it as potentially valuable. It's a trade-off. Yes, you get a little extra chaos from broken discussion around perennial issues. But, if you simply cannot effectively manage and prioritize more than, say, a hundred open tickets, then that might be the lesser of two evils.
asoneth 5y ago
I agree that auto-closing bugs is unfortunate, but I understand the motivation. I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them. Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".
- ryandrake 5y ago
  Not sure if relevant to open source bug tracking, but I've worked in more than one company whose "old bug" policy boiled down to: If after we found this bug, we chose to ship an update that did not include a fix, then the bug is not important enough to ever fix and should be closed as "Won't Fix". In other words, customers have lived with this bug for at least two release cycles and the world didn't come to an end, so don't prioritize it. I don't agree with this policy but I think it's a pretty common mentality in the commercial software world. EDIT: Additionally, I've never worked anywhere where the capacity/willingness to fix bugs exceeded the incoming rate. So net bug count minus fixes would always grow forever unless you regularly purged unfixed bugs. This seems almost universally true in software.
- CRConrad 5y ago
  > Just reading through all the old issues would require a larger team than the product revenue could sustain, Yeah, well, if it weren't so full of decades-old still-unsolved bugs, then maybe the product would have more users and therefore more revenue?
  - 5y ago
agilob 5y ago
This is even worse, competitive projects are compared to each other based on number of OPEN issues, making the project that ignores "stale bugs" look better than project that keeps bug until actually solved. I've seen this thinking twice in action, a teach leads decided to use react native over flutter, because RN had fewer issues

dawnerd 5y ago

Worse is when they prevent you from reopening or if you comment after it’s closed you get a rude response to open a new ticket.

heinrichhartman 5y ago
I can get behind closing stale issues, to a certain degree, but this practice sound straight-out stupid: Why would you discard the context of a previews discussion?
- TeMPOraL 5y ago
  At the risk of spinning of a tangent flamewar: this ties into a wider issue that boggles my mind to this day - the concept of "necroposting" as something negative. People will commonly want to eat you alive if you post a new reply under a stale discussion thread, but that reaction feels really dumb. The old context is useful.
  - travisjungroth 5y ago
    Agree for intelligent discourse about a slow-moving topic. Disagree for conversations about personal opinions (most of forums), especially ones with time context. When you post on a three year old thread, everyone else has left the room. That's fine if you want to share how you finally got this old sound card working on a specific OS, lame if there was a lively discussion about working at Lyft versus Uber.
    - lucideer 5y ago
      Firstly there's a 3rd type: someone asks for help and you post a suggested solution 3 years later. Extremely useful for all the lurkers who also had the same question and are reading looking for possible solutions. But secondly, even your own counterexample I don't think checks out. If I'm browsing your forum & interested in perspectives on working at Lyft v Uber, I absolutely want to read a recent update and contrast that with what people thought 3 yrs ago v now. Tbh, the "I got my sound card working" post seems least appropriate of them all (but still ok to do imo, necroposts are good)
      - travisjungroth 5y ago
        My sound card example was supposed to be like your 3rd type, so we agree there. Old and current experiences are definitely both valuable. Just start a new thread. It's too easy for other members to miss the dates when it comes back to the top. Then they're reading and responding to old posts from absent people like they're here and now.
  - wott 5y ago
    > boggles my mind to this day - the concept of "necroposting" as something negative. I never understood it either. I mean, as a religion. What is even sillier, is that as far as web forums are concerned, you have 50% of them which will go mad if you "necropost", and the other 50% which will go mad if you open a new thread when there is already an existing thread on the same topic (even buried), because these have the exact opposite written or unwritten rule. The latter ones love their 800 pages long topics; the former ones forbid you to follow up with a discussion even when it is the exact same topic, if the discussion stopped for a while.
    - TeMPOraL 5y ago
      You know what beats that still? I've been using a few boards where people believed in both these things at the same time. So when a topic stalled, it was nigh-impossible to resume it later.
      - wott 5y ago
        Ah! :) I've seen something a bit like that: moderators who would come down hard on people who ask a question, both in an old thread or a new one (because the first time they were told not to create new threads or not to necropost so they tried again, following the advice, in the opposite manner), by telling them "why can't you search the fucking forum 2 minutes before digging an old thread / creating a new thread, stupid; this has been answered multiple times: here, here and here; topic locked", and of course none of the links he gives does answer the specific problem the posters had and clearly specified, because the mod didn't spend the said 2 minutes reading the posters' questions and just stupidly copied the first search results in the rush he had to punish the intruders. So, when you hit the same problems as the posters, you are out of luck, because their questions were not answered before, and they will never be.
        kergonath 5y ago
        I have seen this unfortunate behaviour in mailing lists for some Open Source software as well. Gatekeepers with anger issues and too much time on their hand (but not enough to actually answer the question). Sometimes I wish these people realised how hostile they are and unwelcoming to new users and potential contributors, but maybe that’s the point. The result is ~10 relevant hits when you Google an error message with not a single useful solution.
  - twic 5y ago
    There's at least one forum out there where necroposting is actually valued by the culture. It's considered cool and fun to make a relevant post on a thread that was last updated five years ago. I love that.
    - smeyer 5y ago
      Which forum?
  - alpaca128 5y ago
    For me the reason I see it mostly as something negative is because most necroposts are pointless. They're often only written because the author forgot to check the date and thus didn't realise their comment won't contribute anything useful. Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists.
    - lucideer 5y ago
      but that's just a reasonable response to a specific type of comment, not a general defense of banning necroposts outright. The reason the term exists is because it's a blanket rule based on the age of the reply, not based on the intent or context.
      - chc 5y ago
        The blanket rule is because even "good" necroposts tend to encourage bad ones. If I'm on an active forum and I revive some ancient discussion with a useful comment, lots of people will click on the thread and try to argue with the old posts. The generally recommended alternative is to make a new thread and simply link to the old one so you don't confuse people.
    - TeMPOraL 5y ago
      > the author forgot to check the date and thus didn't realise their comment won't contribute anything useful I have a different view of those in most cases - particularly on large, or publicly accessible, boards. That comment may not contribute anything useful for the people previously involved, but it may very well be useful for everyone else - such as any person that finds the thread through a search engine. > Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists. That's a specific case about one-upping someone much later, but a more generalized case - posting modern solution under unresolved problem thread - is very valuable for people who find the thread looking for a solution. Conversely, blanket ban on "necroposting" discourages accumulation of knowledge on tough problems. See also: https://xkcd.com/979/ https://xkcd.com/979/
  - detaro 5y ago
    If the old context is useful, sure. but it often isn't, and that's what causes people to dislike necroposting. But without a specific policy/instance in mind discussing this is a bit moot, since everyone has a different level of reasonableness in mind.
- strogonoff 5y ago
  I don’t think “necroposting” is something inherently bad[0], but specifically insisting (or expecting) that open-source project maintainer remembers a 100-screen thread every time anyone wants to bring it up is IMO ill-mannered. A random person online invests an afternoon to read through a years old issue thread and decides to comment, expecting the maintainer to reply. Meanwhile, maintainer has dozens of such issues, and dozens of frustrated users bringing up each of them every week. Asking the submitter to respect a previously made maintainer’s decision, file a new issue and invest their own time to concisely summarize the status quo seems only fair. In other words, diverting discussion to a new thread is a chance to compress old context into a short summary, like you would squash a Git history—except in this case the old closed issue thread is fully linkable and isn’t going anywhere. [0] That said, it depends on maintainer’s personality. I can see how some could feel losing control and demoralised by ever-evolving difficult-to-track discussions on previously closed issues.
  - lucideer 5y ago
    You're right that this behaviour is bad and I know that what you describe happens but it seems like a strawman argument in the context of this discussion. What you describe is about the community respecting foss maintainers; closing tickets is not going to solve this problem.
    - strogonoff 5y ago
      I was responding to the point about comments piling on a closed issue. It is not bad by default, but still there can be valid reasons for maintainers to discourage it. Whether an issue should be closed or should be allowed to be re-opened by the public is not even up to debate as far as I’m concerned, this is up to maintainer’s policy.

MrOxiMoron 5y ago

not searching closed issues is always bad, things that are fixed in a newer version or after long discussion are closed as won't fix won't be found either

Jenk 5y ago

Meh. It's just a method of filtration. When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little in the way of automatic triage determining the priority it is a borderline impossible task to wade through them. Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.

tinus_hn 5y ago
It’s fine, as long as the time he submitter spent to write a decent bug report is worthless to you.
- frereubu 5y ago
  That's a straw man. It's a balance between your time and theirs, and I presume you don't think that all bug reports are carefully considered and well-written. Many are even obtuse, aggressive and self-entitled. I'd bet most well-written, civil bug reports are at least taken seriously, even if they end up as a wontfix.
  - tinus_hn 5y ago
    You don’t need to wait for a certain period of time to decide that a bug report is poorly written.
  - ForHackernews 5y ago
    There's nearly zero cost to leaving a stale bug report open. A few kB, and maybe not even that because closed tickets are rarely actually deleted. If you're not working on a bug, then, by definition, it's not taking up your time. Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
    - thaumasiotes 5y ago
      > But closing tickets and fixing bugs are not the same thing. You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D

frereubu 5y ago

In an ideal world I'd agree with you, but if you or your team don't have the time to fix every bug - some of which will not be critical - then having a mass of open issues pile up often leads to people being overwhelmed and fixing even fewer. Also, over time, some issues are superceded by changes elsewhere so they become moot anyway.

bayindirh 5y ago
Why not move them to a low visibility category like a back-burner? Some long standing problems get progressively easier to fix when the blockers around a bigger problem gets conquered slowly due to requirements.

lloydatkinson 5y ago

1000% this. The lodash library for Javascript had the authoritarian dictatorship extreme version of this for the longest time. Any issue was immediately closed and only closed issues would be reopened if enough people gave said closed issue enough thumbs up (and "enough" wasn't even defined). And of course, this process wasn't explained anywhere except in replies to closed issues. The obvious problem with this was that no issues were ever acted upon ever because no one ever looked at closed issues, because why would they? I had created a proposal for a new function to be added that was and still is sorely missing. After it was closed and a long discussion ensued between many devs, I gave up and a year later I simply replied that I retract the proposal due to the ridiculous policy of actively being hostile to users. The maintainer deleted the whole issue and along with it all proof of their hostility and hypocrisy. It was then that I decided I would boycott lodash and simply use better libraries in my projects now like Ramda, which is actually OSS. Looks like lodash is now no longer maintained and has hundreds of tickets open after the hostile maintainer (and it's not hard to guess who from looking at the commit counts) appears to have stopped maintaining it. Funny how that works, closing tickets constantly ensures no one will want to help, and then the maintainers feel overwhelmed because they are doing it alone. Basically closing issues is an awful practice that helps no one, as you say.

goldenkey 5y ago
Don't forget that Lodash was basically JDalton's rip of Underscore.js. There used to be a mention of it, since the selling point was benchmarks. Now, I don't see any mention of Underscore...
- capableweb 5y ago
  Not sure I'd call it a "rip", "ripping" for me is associated with "ripping media" which is copying video/music/data from CDs to local hardware. Lodash is more of a re-implementation of a MIT library, not something that should be shameful. As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.

Arathorn 5y ago

+1E100. On a busy project it's disasterous if long-lived chronic bugs which are serious enough to be tracked in the first place, but have never quite made it to the top of the todo list, randomly got closed for no good reason. This issue is a classic case in point. We have too many similar ones on Matrix (but which we've been slowly working through over the years).

fn1 5y ago

This came up in the javascript-world.

rvz 5y ago

> I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice. Imagine if the Linux kernel or even Chromium had stale bots closing reported vulnerabilities everywhere. It's like they are burying bugs waiting to be exploited by drive-by security researchers.

handrous 5y ago
Android, notoriously, does this. When (not if) you hit an Android bug while developing an app, more than likely you'll find it closed as stale. Luckily they don't usually block comments, so you'll get to see confirmation from within the last few weeks that you're not crazy and this bug is still present, and maybe some up-to-date workarounds if you're lucky.

zaphirplane 5y ago

I disagree for bugs in volunteer open source because it requires someone to triage it and recreate the bug cross versions. Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid The process of closing it means pushes that work back on the users obviously this requires the coders to keep an eye on the bugs and assess their importance Having 8000 bugs cross 10 years with ancient versions helps no one FWIW In this case it’s a feature request

CRConrad 5y ago
> Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid This sentence missing lot grammar. So much so that I really can't even see which direction of the argument it's arguing for or against.

bassdropvroom 5y ago

I disagree. It entirely depends on the behaviour. I've lost count of the number of tickets that have been raised that has no information, or is not reproducible, or something else. When I then ask for more information, or something else, they never reply. I've no incentive to keep such tickets open. So I set up stale bot and auto-close the tickets. Individuals can come and re-open if it happens to them, or more information is added. Now I do agree, if it is a genuine issue, then it shouldn't be closed until it is sorted out it. So you can set up stale bot to ignore labelled or something. So that's how I've set up all of my repos. For me this has taken off a huge burden. I don't agree with locking threads after they've closed though. There is very little reason to do so.

eptcyka 5y ago
This is different from closing legitimate bugs/issues that are well described and testable, just not fixed.
- bassdropvroom 5y ago
  That's right. It's all use-case based. Indiscriminately closing issues automatically is definitely wrong. Automatically closing issues that cannot be reproduced or have other issues is a perfect use-case for stale bot.
  - eptcyka 5y ago
    Show me a bot that can tell the difference between a testable and well described bug and one that's affecting lots of users but has bad descriptions.
    - bassdropvroom 5y ago
      Using GitHub's stale bot you can set it to ignore labelled issues, and so it's up to maintainer to label things correctly. Once the maintainer does so, stale bot won't touch it.

jlarcombe 5y ago

Amen. About once a year I spend an entire day reopening bugs in the Qt bug tracker while somewhere in Finland someone is sitting there closing them, like a sort of really annoying game. The process consists of (a) downloading the minimal test app attached to the bug, (b) making a trivial change to get it building with the latest Qt, and (c) reopening the bug with the remark "this still happens in Qt X.latest". Unfortunately I can't quite do this as fast as they can close them...

arghwhat 5y ago

It depends solely on the definition of "stale". An issue where the reporter is unreachable and developers do not have local reproduction should absolutely be closed as it serves no function other than generating noise in the issue tracker. Open issues is a liability to overview and planning, and having bad open issues is therefore directly harmful to maintainers, reporters and users. Closing a bad but ultimately real issue will just make way for a possibly good report to take it's place (i.e. a new reporter rather an old unresponsive one) so it only provides benefit.

xattt 5y ago

It helps people gain a sense of productivity when a lot of yak shaving place.

johnchristopher 5y ago

As a bug reporter I take it very personally when it happens to me. When I try to debug a problem and I see it has already been reported and closed due to inactivity (that is :not fixed. Not tagged won't fix) I give up, I won't fight the machine.

mumblemumble 5y ago

In general I don't disagree, but I'd moderate the position with context. For projects that have some sort of product manager who is personally in charge of managing and perhaps de-duplicating the tickets, I'd leave the choice up to them. Some like having only one ticket that captures all discussion about an issue. Some don't care, and aren't so worried about losing track of comments from several years ago. That feels to me like a work style issue, and I don't need to tell them how to do their job. Or, for projects that are working with an issue tracking system that makes it really difficult to juggle large numbers of open tickets, I also see it as potentially valuable. It's a trade-off. Yes, you get a little extra chaos from broken discussion around perennial issues. But, if you simply cannot effectively manage and prioritize more than, say, a hundred open tickets, then that might be the lesser of two evils.

asoneth 5y ago

I agree that auto-closing bugs is unfortunate, but I understand the motivation. I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them. Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".

ryandrake 5y ago
Not sure if relevant to open source bug tracking, but I've worked in more than one company whose "old bug" policy boiled down to: If after we found this bug, we chose to ship an update that did not include a fix, then the bug is not important enough to ever fix and should be closed as "Won't Fix". In other words, customers have lived with this bug for at least two release cycles and the world didn't come to an end, so don't prioritize it. I don't agree with this policy but I think it's a pretty common mentality in the commercial software world. EDIT: Additionally, I've never worked anywhere where the capacity/willingness to fix bugs exceeded the incoming rate. So net bug count minus fixes would always grow forever unless you regularly purged unfixed bugs. This seems almost universally true in software.
CRConrad 5y ago
> Just reading through all the old issues would require a larger team than the product revenue could sustain, Yeah, well, if it weren't so full of decades-old still-unsolved bugs, then maybe the product would have more users and therefore more revenue?
- 5y ago

agilob 5y ago

This is even worse, competitive projects are compared to each other based on number of OPEN issues, making the project that ignores "stale bugs" look better than project that keeps bug until actually solved. I've seen this thinking twice in action, a teach leads decided to use react native over flutter, because RN had fewer issues