Hacker News Reader

Comment by triska | Hacker News Reader

This was achieved also by ignoring open issues and simply closing the bug even though the issue still exists. An example of this is:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21526

In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause.

As I remember it, the Emacs maintainers used to put a lot more emphasis on actually correcting issues instead of only closing them, and this may also be the reason why fewer issues are reported now.

A great attraction of Emacs is how easily one can actually report issues, using Emacs itself: M-x report-emacs-bug RET.

View on HN

Last message in the thread:

> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report.

I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(

I'm kind of on the fence for these (in general, not specific to this ticket).

Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?

No other approach is sustainable.

Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?

Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.

Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.

And if not, the bug is probably not important. ¯\_(ツ)_/¯

At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.

And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.

At my last job, this was the attitude we eventually took with tickets that were several years old.

If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.

[0] when I say "customer", I'm talking about a department, not a single individual

There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks: 1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment. 2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied. Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.

Not five year. Two months went from the OP in September 2015 to the final dev message in November 2015, during which the OP and the dev were communicating regularly. It was the OP who didn't respond after the dev mentioned that he believes that he fixed all the outstanding issues.

It was five years later that someone came along and closed the bug.

I would estimate the chance of a user coming back to close a bug at near zero, even after only two months.

Indeed. As a fellow maintainer I will manually replicate the error the user reports, write an test to around the failing function, then fix said function.

After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”

That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family).

Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.

> ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”

This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope.

It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.

There are multiple types of issues. You’re describing a bug in a very pure sense. But often the most important issues are customer issues where they are blocked and need help. Then it is less about the big that you’re tracking and more about this customers experience. The resolution to their issue might not even be in your products code, but we still track it until the customer is unblocked to use our product.

> Then it is less about the big that you’re tracking and more about this customers experience.

Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?)

> we still track it until the customer is unblocked

As you should... in some place that isn't the bug tracker. (See "muddled.")

You're focusing too much on correctness. Bug reports are almost never because a user has identified incorrect behavior, they are because the user has identified unpleasant behavior. The maintainer then takes that reported unpleasantness and decides whether it's a bug or a feature. If it's a bug then the maintainer, usually implicitly, updates the program specification such that the unpleasant behavior is now incorrect, perhaps by writing a test, and then corrects the incorrect behavior. But since the primary motivator is actually the user's reported unpleasant behavior, it makes sense to check that the now correct software also behaves pleasantly for the reporting user. And since pleased users may well just be using the software instead of following up in the bug tracker, it makes sense to close those issues with the proviso that displeased users are welcome to reopen them.

It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.

Personally if a bug report does not get a reply in two months I'm probably not using it anymore. Collaborating to these kinds of projects is extremely frustrating. Why will I spend my time debugging and implementing features when issues and PR are promptly ignored or closed? Is my time a joke?

Recognising the orignal bug opener's name, Markus Triska, I know he's on HN. I checked his username to see if he's been active recently and, well, see for yourself: https://news.ycombinator.com/threads?id=triska

For what it's worth, when I encounter a project doing this I treat it as a giant red flag that the developers don't care about the quality of their project.

In the majority of cases, there's another project that I can move to and I do so as soon as possible.

There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.

While reporter is still alive.

sometimes it feels to me that people collectively forget that writing software (especially FOSS)'s primary goal is to empower other human beings, before anything else - including our own little developer comfort. Closing unfixed bugs because of no activity really really goes against that in my mind.

Closing issues by itself do not fix bugs.

IMO, It is the user responsibility to make a reproducible bug (to become a failing test). From there on it is the developer responsibility to fix it (make it a passing test)

Absolutely. If there is nothing new and a bug is still there, there is simply nothing to add to the bug report. Too often now bugs get closed automatically for "inactivity" after a short period. Should users come back every months to "ping" the thread ? Some bugs last for years, they'd sooner be blocked for spamming. It's just Goodhart's law in action, a cheap way to reduce the bug report count.

Agreed. The bug report was one reporter and a maintainer discussing a bug for 2 months back in 2015, and at the end the maintainer says he believes he’d fixed it. Then no more messages. After 5 years of no complaints after a likely fix, closing it is very, very reasonable.

Assuming you're the author of that bug report, it looks like you never did reply to that last message on 23 Nov 2015, so the developer was left hanging. Seems totally fair to assume this is fixed after half a decade with zero user comments.

As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.

In this specific case, the Emacs maintainers took a mode which already shipped with Emacs (in fact it was the mentioned third-party Prolog mode that was already bundled with Emacs with slight modifications) and changed it so that it no longer worked as previously and also not as expected.

It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode.

The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.

> even though the issue still exists.

The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".

I have to say I find it extremely bad form to write like this hear suggesting you are an unrelated party, while in fact you are the bug reporter who didn't reply when asked if the bug still persists. At least be honest about your involvement in this issue.

I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.

You are right that I should have pointed out explicitly that I filed this specific issue. Please note though that I was not "asked if the bug still persists" before it was closed.

I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue.

Another example, an issue which I also filed and which was closed even though the issue still persists:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005

It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.

My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.

> In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.

At the top of your bug report, it says:

    To add a comment to this bug, you must first unarchive it, by sending
    a message to control AT debbugs.gnu.org, with unarchive 21526 in the body.
    You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.

The last message 6 years ago reads that the dev thinks the bug is fixed. Since then no-one complained. Do you know that the bug was falsely closed? Isn’t it more an example of a bug submitter loosing interest in their bug?

Disclaimer: I did not read all 146 messages.

The person you are replying to here (triska) is the original bug opener Markus Triska. A skim read of the thread, there's a long back-and-forth of Prolog parsing and formatting and interaction with Emacs movements, with many bugs raised in it. (It's more of a review-and-polish something than a single bug), and near the end Stefan Monnier says:

> "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce."

It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly."

Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed".

It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug".

[1] https://web.archive.org/web/20210311012401/https://www.jwz.o...

In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers.

That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software.

I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.

From personal experience, bug reports are cheap to generate and very expensive to investigate. Additionally often it is the case that bug that no one paid any attention to eventually does go away on its own (the environment changes, the features is removed, a single commit ends up fixing multiple symptoms of the same problem, it was actually a user error, etc). Give the morale and dev time cost of a sprawling and low fidelity bug list I sympathize with aggressive bug triage, as I had to do the same myself. The real stuff will keep popping back in, and its better to have a real but incomplete list than a complete but mostly bogus one.

> bug reports are cheap to generate and very expensive to investigate

This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.

Yes, this is true, and as you say the more work is put into the bug report, the cheaper it is for the dev to investigate and the less likely it is that a bug report will be closed prematurely.

Yep. Closing issues consistently without resolving it is best way to cause your users to stop caring ever reporting new issues.

If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.

When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size is to simply declare that if a bug cannot be fixed in $timeframe, it should be closed as WONTFIX. Acknowledging that the bug or issue will remain because the projects resources have more important things do do, and it will never be dealt with unless some external factor is added (eg. a volunteer with skills prepared to prioritize the work). It also acknowledges that the longer bugs sit open, the less relevant they become. The feature they apply too may have changed beyond recognition, becomes deprecated, or the bug metastasizes and becomes a feature. It acknowledges that long open bugs are going to be reported multiple times anyway, and at least this way you get fresh, current reports rather than everyone dog piling on an ancient ticket that nobody wants to get near. You know the ones, where it has mutated over time that the initial report from 2008 bears no resemblance to what is currently being discussed, but everyone is cranky because it has been open 12 years and obviously the devs all suck... doesn't really inspire you to deal with it.

So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.

That is how most projects on GitHub are run. There is a bot that just closes issues after periods of inactivity. As if "not fixing the bug" can be considered as inactivity. Mostly in Kubernetes repositories I keep getting this "we are closing your issue, because we cba to solve it after 4 months" notifications.

I think people set up those bots without even starting to think through the consecuences of doing so. There is nothing more hostile to users than a program that misbehaves, searching and finding that the problem was reported in 2017 and closed afterwards with the excuse of no activity for the last 6 months (or any other equally ridiculously short amount of time).

Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong.

I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.

I think this is a filter that allows the issues submitted by other big companies to get the attention they deserve while at the same time maintaining the facade of operating as an open source project

This is how some projects on GitHub are run. Any bots like that need to be set up by the maintainers.

The word “closed” doesn’t mean problem solved. It actually can legitimately mean the problem is ignored: we closed the case because nobody cared anymore.

That shouldn’t happen because people will continue to report the bug and open duplicate issues. Instead, it should be tagged with something like “won’t fix”.

If someone reopens the bug or opens another bug, that is an indication that someone still cares.

WONTFIX means the developer won't fix the bug. If you still care about it, fix it yourself or pay someone to do it for you; you're not entitled to unpaid support from 3rd parties, even if you ask nicely.

Please look at the context of my comment. ummonk suggested that developers should tag closed bugs with wontfix, even if they were only closed because no one cared (rather than because they don't want to fix it).

Won’t fix can be such a trap as well because it doesn’t make the problem go away but signals to the users “we don’t care so go away”. The issue that pushed me off of android was tagged as wontfix, and doesn’t seem to be solved despite a decade of users complaining android is literally costing them money: https://issuetracker.google.com/issues/36907469?pli=1

The affected users didn't bother to check if the issue was solved for five years. I think it is fine to close it

Or they gave up checking and moved on, but the bug is still affecting others (who do not know how or don't bother to report) - some of whom may also just move on.

I disagree. The affected users completed their responsibility of filing a ticket, and if triage is done correctly, they should rely to the issue status or comments for updates. The alternative of having issue creators regularly ping the assignee for status updates via comments seems unproductive for both the creator and assignee.

It's super sad considering the new stream of users of all levels, but energy is spent at the higher layers (emacs config, org tricks) rather than core..

This is probably because it is relatively easy to add more elisp flourishes, another seven major modes for editing JavaScript, much harder to actually improve the core.

As with any large system, improvements to core also risk compromising large, popular packages.

I wonder how remacs guys are doing now

They're no longer taking PRs, development has moved over to emacs-ng with a different perspective on how to improve Emacs.

There's a new elisp JIT in emacs 28

https://emacsconf.org/2020/talks/38/

There's a new portable undump in emacs 27

https://www.masteringemacs.org/article/whats-new-in-emacs-27...

a couple of examples of very core features off the top of my head

I had no idea about the new JIT but in any case it would be nice if more manpower was allocated on fixing bugs I guess.

As active as you are in the Emacs community, you ought to know that there is a steady stream of commits to "core." Anyway, if that's not enough for you, maybe you could allocate some of your own manpower to fixing those bugs.

i'm not able to commit enough neurons for emacs core right now otherwise you'd see me everywhere

I agree with you, but also having maintained a fairly large corporate OSS project, our backlog has gotten unsustainable. We've thrown more bodies at the problem, and are trying to deputize more of the community, but I really don't know how to manage/organize super old issues that may be legitimate, but typically aren't very searchable for people with similar problems (which often aren't obviously similar).

>However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause.

Fantastic! Two birds with one stone!

Your comment feels like you’ve never worked on an open source project that gets issues.

This has always been my problem with emacs. The basic interpreter and interface design is phenomenal, but it is so bogged down and buggy it is frustrating to actually push it to the limits of capability. I wish the devs would just drop support for stuff that can be maintained just as well as a plugin.

Time for a neomacs?

146 messages in that bug thread. Wow.

> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report.

If only there was a way to find out, instead of guessing.

I’m going to start trying this at work. I wonder how it will be received?

I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.

> I’m going to start trying this at work. I wonder how it will be received?

You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year

That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?

I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…

Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.

For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?

The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.

See my response to kortilla above.

QA is not your test suite. Test your own code, submit working code, let QA try to break it.

Dont just push code and expect others to point out your flaws. Take some responsibility.

See my response to kortilla above.

> Though, to be honest, it is QA who is testing it, not us developers.

Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.

Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).

Not where I work. QA are the ones who first look at all reported issues. They see if they can replicate the reported issue. If they can’t they contact the reporter and try to figure out why they can’t replicate it. Once they can replicate it they write up the ticket with replication steps and add it to the backlog to be assigned out in a sprint. They attend all meetings and explain the issues. Once the developer thinks they have fixed the issue they send it back to QA to verify it is fixed. Then QA reaches out to the person that reported the issue to tell the about the resolution.

Have you ever sent the issue back to QA as fixed, and then they do their reproducer and it’s not fixed? That’s roughly the scenario we’re asking you to have empathy toward.

That’s not testing, that’s triage. If you don’t bother writing unit tests yourself as a developer when you fix the tickets, then that’s the problem I’m referring to.

In most places I’ve worked, having a bug untouched for even a fairly small fraction of that time would result in someone getting, at a minimum, corrective counseling.

Corrective counseling for a single bug? I take it you’ve never worked in a US software company.

Yeah... This actually seems standard for old backlogs.

Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen.

Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.

When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.

I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen

Everybody does this, it's the normal behavior with enterprise bugs.

They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.

when your text editor has a better bug reporting feature than its text editing feature, maybe it's time you move onto something else

Reply on news.ycombinator.com