Also Gnome. Always cracked me up. Like I'd make this issue with like all the details reported and everything. ESR would have wept. And then "Does this issue still occur in Gnome 3?" and closed a week later all while I'm on vacation. Homie, this sat here for like 5 years, surely you can be a little patient.
Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.
Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window.
The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.
The counterargument is that a bug is enough a function of its context that the older they get, the less likely they are to still be relevant or accurately documented. Having a bug on the list isn't enough - it needs to be periodically reviewed, kept up to date, prioritized, etc.
Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority' for years. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it.
With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance.
(Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)
I think it's actually a problem with issue trackers, which have only this binary open/closed status, where the only way to express "outdated" is with a label or something.
As a project maintainer, I don't want to close unfixed issues because they become much harder to find (hidden by default), which results in duplicate reports if it turns out the issue is not fixed. Also it can be rude, if it was a high effort bug report.
At the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with.
The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.
But it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed -- but this is not a separate bin).
This assumes that the bug creator can be bothered to review the bug and type every n weeks "still happens", with n unknown and variable in general. This makes sense for an organization with clear processes where the value of n is well-known to all stakeholders, but comes off as unwelcoming and offputting for users who want to contribute in their free time to improve their favorite applications.
I'm one of the maintainers / developers / support personnel for an internal app that was created circa 1996. We still have open bugs that's 20 years old and haven't yet been fixed.
When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs.
To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed.
I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant.
Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good.
Open bugs are also history - and amazing for support; a "known bug" will have workarounds or suggestions on how to avoid hitting it, even if it never gets fixed.
Closing bugs just to make dashboards/metrics look better is wrong; either adjust the dashboard or fix the bugs.
For open repositories like this I certainly agree. And when I worked at a smaller company with no dedicated QA team we never closed bugs, either.
But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed.
If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
Just do what they do where I work, move to a new tracking product, if you really care then you have to go and open bugs in the new (more annoying to use) system :)
I have seen projects where the developer(s) would say things like: "This feature request sounds good to have but we don't have the time for this now. So, I'm closing it. Could you please create it again in 6 months?"
I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?
I half-seriously suggested that a project I used to care about set up a cron job to delete requests older than a year automatically.
The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations.
See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary):
The link is good and insightful, if you copy-paste it into the browser bar. If you click it it redirect to a fairly tasteless image complaining about being linked from HN.
>In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
>>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
>This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
>I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short.
>It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
>But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
[random GIF of a compass, that links to the homepage]
> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
Sounds like the content is just as mature and insightful as the HN ddos redirect image. I see why objecting to being linked an image of a hairy ball in a 2011 image macro was wrong of me.
If the author complains about a HN ddos, then why does everyone suggest evading his ddos protection? It seems like reuploading the content works out better for everyone. It's just plain lazy to post a raw link to that site on this forum.
The downside is that Mozilla tracks thousands of open tickets, most of which are probably obsolete. But who is going to start now with reviewing stuff from 20 years ago?
As much as it pains me (I’m still tracking multiple bugs I reported) to say this, but all tickets with no activity for some reasonable time period must simply be closed. Things are _already_ out of control.
That's too simplistic. What if it IS an issue, or what if it WILL be fixed, but because of priorities it's always bumped down the list? What do you then, bump it every few weeks?
No, any open source project needs someone (or multiple people) triaging tickets; either keep them open and make sure they are implemented in a reasonable time, or close them as a 'wontfix'.
Of course, then you'll have the issue of people opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
I think there is a place for "Priority: Would Accept Patch". AKA we don't think it is a bad idea (otherwise we would close) but at this point we don't think that "the developers" will ever get to it. However leave it open, people can mark interest (hopefully with a vote not a bump) or maybe even write a patch. It's not hurting anyone just sitting there.
There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
Does it? It's not like you're paying GitHub per open issue.
I've literally had issues I filed that the maintainer verified as an actual bug be closed due to lack of activity. I can understand that an unpaid maintainer doesn't have the time or motivation to fix it, but closing issues you know are valid seems insane to me.
The maintainer may see issues as "something that they should fix", vs "something that could be fixed". If they see it as the former and have no intention of working on it, then closing makes sense. I don't think there's a universal code of conduct on how to handle Github issues.
Is it a human closing it or a bot? If you run an open source project there's a natural tendency to install a bot to auto-close all of the issues which people open because they didn't read the docs, want you to do free consulting for their business, have an irreproducible bug report, etc. and since most projects are short on labor that makes it somewhat inevitable that someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
> someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
Looking at you, every random GitHub project ever.