3/25/2026 at 8:29:32 PM
Author must not have worked in enterprise software before.That's a classic trick where the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. And if it doesn't get confirmed then they can close it as User Error or Not Reproducible.
Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.
by freediddy
3/25/2026 at 8:44:22 PM
From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").by Leherenn
3/26/2026 at 9:19:08 AM
Outsiders can't see the internal ticket, but e.g. https://github.com/microsoft/STL/issues/4448This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug.
And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work.
Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.
by tialaramex
3/25/2026 at 10:29:35 PM
I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr.Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.
by Natsu
3/26/2026 at 10:55:33 AM
I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.by Neywiny
3/26/2026 at 9:35:32 PM
[delayed]by Natsu
3/26/2026 at 1:52:18 PM
puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hatby butlike
3/26/2026 at 7:52:20 AM
Why would they do that when they could waste your time instead?by hsbauauvhabzb
3/26/2026 at 12:50:24 AM
[flagged]by nradov
3/25/2026 at 11:29:12 PM
My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see".Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team.
They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever.
Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence.
If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."
by jiggawatts
3/25/2026 at 10:27:19 PM
It'd kind of sad, how the market went. I suppose there are pluses too.But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items.
Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet.
On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail.
I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes.
Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
by b112
3/26/2026 at 12:54:00 AM
High end enterprise products still come with support. That's literally what customers are paying for: a single throat to choke.by nradov
3/26/2026 at 1:28:16 AM
Exactly! The "pay a lot of money but get really good support" tier still exists just about everywhere. You just didn't do the first part.by Bratmon
3/26/2026 at 4:17:54 AM
It really depends, support is usually the first thing companies adjust when they want to improve their margins.Even when you're paying millions to AWS you have to get through their first line of support and they will ask silly questions until you can convince them to escalate.
by atherton94027
3/26/2026 at 7:56:21 AM
So build barely usable products that force people to pay for support as an upsell.by hsbauauvhabzb
3/26/2026 at 10:55:40 AM
Not really, you get "really dedicated support" at most, but not a "really good" one, otherwise all those decades-old bugs common in many software producs would've been fixed since they affect people at all tiersby eviks
3/26/2026 at 4:43:40 AM
Back then, computers didn't had competition from the analog world, so vendors had to provide excellent service such that users would be convinced into switching over to the digital way if doing things. Now comouters have a monopoly on how we work and live, so vendors care as little as possible.by glitchc
3/26/2026 at 1:16:22 AM
That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company.When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.
by rkagerer
3/26/2026 at 1:27:00 AM
It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion. Triage, filtering, and winnowing are necessary here.by nerdile
3/26/2026 at 1:43:14 PM
It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.by account42
3/26/2026 at 1:23:13 AM
My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs.If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning.
You could say: "but have pride in your work!"
But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.
by eob
3/26/2026 at 2:07:00 AM
What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.by nradov
3/26/2026 at 4:01:44 AM
Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it?My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make
by daheza
3/26/2026 at 5:39:55 AM
There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.by nradov
3/26/2026 at 7:54:33 AM
You’ve just described AGILE development, a way for product owners to backlog code rot while empowering developers to feel like they have a say in things.by hsbauauvhabzb
3/26/2026 at 7:22:41 AM
> That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability.GTK1, GTK2, GTK3, GTK4, GTK5. Fixing bugs is hard, rewrite is easier.
by hulitu
3/26/2026 at 7:58:29 AM
None of those were full rewrites. Not sure what point you are trying to make.by chris_wot
3/26/2026 at 3:54:54 PM
https://www.jwz.org/doc/cadt.htmlby kasabali
3/25/2026 at 9:42:31 PM
Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.by beembeem
3/25/2026 at 10:36:36 PM
I totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs.Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.
by nradov
3/25/2026 at 10:47:19 PM
There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned.You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.
by SchemaLoad
3/26/2026 at 12:31:00 AM
If bug contains instructions for reproduction most of that will be eliminated.by PunchyHamster
3/26/2026 at 1:47:20 PM
99.99% of bug reports do notYou're lucky if there is an accurate description of what produced the bug on the customers' specific setup at the time of reporting.
by account42
3/26/2026 at 3:12:46 PM
well then closing it with inactivity is fine.by PunchyHamster
3/26/2026 at 12:54:15 AM
There's obviously some nuance here, but the fact is that much modern software is riddled with bugs, and this is sub-optimal for everyone (both software users and software builders). Most of the bugs which frustrate and irritate software users are not due to uncontrollable events such as cosmic rays flipping a bit. Most of them are plain old code defects.But, you do have a valid point. Allow me to rephrase it this way: The answer is not for software companies to spend unbounded amounts of engineer time chasing every reported bug.
But there are ways that we, as an industry, can do better, and it's not by pouring all our time into chasing hard-to-diagnose bugs. Here are a few ways that I personally see:
1. Some very powerful technologies for finding many bugs with little engineering effort already exist, but are not widely used. As an example, coverage-guided fuzzing is amazingly good at finding all kinds of obscure bugs. The idea of coverage-guided fuzzing was known from the 1990's, but it took AFL (in ~2013) to take it mainstream. Even now, much of the industry is not benefiting from the awesome power of coverage-guided fuzzing. And there are other, equally powerful techniques which have been known for a long time, but are even less accessible to most software developers.
So: spread the word about such techniques, and for programming language/platform developers, work on making them more easily applicable. This could help many software companies to catch a great number of bugs before they ever go to production.
2. Similarly, there are extant historical computing systems which had very powerful debugging facilities, much better than what is currently available to most developers. The ideas on how to make our platforms more debuggable are already out there; it's now a matter of popularizing those ideas and making them readily accessible and applicable.
3. Since it's widely known that many bugs (real bugs, not "cosmic rays") are extremely hard to reproduce, an admirable target for us to aim for as developers is to implement debug logging in a way which allows us to root-cause most obscure bugs just by examining the logs (i.e. no need to search for a reproducer). Some real-world systems have achieved that goal, with very good results.
4. While there is currently much buzz about using LLM-based coding agents to write code, I think an almost better use case for coding agents is in triaging bug reports, diagnosing the bugs, finding reproducers, etc.
I've recently had a couple of shocking experiences where, just given a written description of an intermittent, hard-to-diagnose bug, a coding agent was able to search an entire codebase, identify the exact cause, and write a reproducer test case. (And this after multiple experienced human programmers had looked at the issue but failed to identify the cause.)
In summary, I think there are ways to "cut the Gordian knot" of bug reports.
by alexdowad
3/25/2026 at 11:41:43 PM
What if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes?That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goose chase.
Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.
by ImPostingOnHN
3/26/2026 at 1:38:16 PM
Right. The problem isn’t closing the ticket, it’s pretending more work is happening than actually is.“Needs verification” is fine if someone has actually tried to reproduce it. Otherwise it’s just a nicer way of saying “we’re not going to look at this.”
by annie511266728
3/26/2026 at 1:51:17 PM
Most of the time there is some reason to believe that the bug could be fixed though, i.e. there were non-trivial code changes around that area.by account42
3/26/2026 at 2:28:30 PM
Most of the time, there isn't any reason to believe it could be fixed, i.e. there were not any non-trivial changes around that area. What you're describing happens less frequently, and in such cases, the devs should discuss that with the reporter.In this specific example, it looks like Apple gave no indications that such changes had happened, and no indications they had even spent a nonzero amount of effort following the reproduction instructions with either the old code or the new code.
by ImPostingOnHN
3/26/2026 at 6:36:27 AM
> Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.Truenas literally takes this approach to bugs.
by ikiris
3/26/2026 at 12:12:09 AM
I'll steal this to my projects bug template! /s"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly acknowledge that, your bug will be closed automatically in 30 days. Thank you very much"
by hu3
3/26/2026 at 6:13:19 PM
Yes and no.Funny you mention Microsoft because I used to see bug reports for Windows. I can tell you there was a ton of low quality "SOMEONE HACKED MY COMPUTER" or similar feedback (and sometimes just unintelligible ranting) that was completely inactionable or unreproducible. I otherwise do agree with your premise that large monopolistic businesses can sit on large swaths of feedback without worrying about competition - and that this is a problem.
However, for most software projects and businesses, the lack of repeated feedback is a signal that the issue isn't important.
As a user I would hope that the software author/publisher is prioritizing important problems. Closing one ticket is not indicative of organizational rot, as you say.
by beembeem
3/26/2026 at 2:04:41 AM
> For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it
| Though only 5.8% of his game's buyers were playing on Linux, they generated over 38% of the bug reports. Not because the Linux platform was buggier, either. Only 3 of the roughly 400 bug reports submitted by Linux users were platform specific
Don't just a bug report by its cover, judge it by its merits. We're all biased to dismiss them and find an excuse to ignore them. But that just leads to bad software.
by godelski
3/26/2026 at 1:26:38 AM
Yeah competition works. I don't like nexus that much but they accept every ticket I've opened and fix it the next release. Two things I think affect that. One, my ticket has the name of a fortune 100 next to it. Two, artifactory will eat them alive if they don't keep customers happy.by galangalalgol
3/26/2026 at 1:00:27 AM
> this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities.
If you're having trouble reproducing, tag "needs verification" or something else. But closing a ticket isn't triaging, it is sweeping problems under the rug
by godelski
3/26/2026 at 10:41:46 AM
Exactly. Thank you for saying this.by olvy0
3/25/2026 at 10:16:51 PM
It's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.by falcor84
3/26/2026 at 7:00:15 AM
The cost/benefit framing makes sense for an individual ticket, but it breaks down at the portfolio level. The developers filing detailed, reproducible bug reports are your highest-quality signal — they've done half the diagnostic work already. The verification dance disproportionately discourages exactly those people, because they're busy and they know their time has value.The developers who keep jumping through hoops are often less technically sophisticated users who click "yes I reproduced it" without actually testing. So you end up with a feedback channel optimized for closing tickets, not for surfacing real problems. High-signal reporters get filtered out, low-signal confirmations pile up.
The Chromium team gets this right by assigning someone to reproduce reports before asking the filer to do anything. More expensive upfront, but the signal quality is far better and the developers who actually know what they're talking about don't give up after the first round of pushback.
by AbanoubRodolf
3/25/2026 at 10:23:22 PM
I’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work.Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.
by conductr
3/25/2026 at 10:46:03 PM
Careful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.by FridgeSeal
3/26/2026 at 1:14:01 AM
I can sort of back that for desktop apps but telemetry is so trivial for webapps needing a reproducer is almost an embarrassing admission the operator has no clue what they're doing.Error tracking and tracing make it fairly straight forward to retroactively troubleshoot unreproducible issues.
by nijave
3/26/2026 at 1:55:05 PM
And total 24/7 surveillance also makes police work easier, but it's still wrong.by account42
3/26/2026 at 4:04:01 PM
...you're claiming error tracking and monitoring are wrong?We're talking about companies you voluntarily have a relationship with, not the government
by nijave
3/26/2026 at 4:08:39 PM
The telemetry is almost always not voluntary and neither is the relation ship with the companies in the first place unless you mean that technically you could become a hermit living in the woods.by account42
3/25/2026 at 9:04:00 PM
> Author must not have worked in enterprise software before.Or with open source projects. Fucking stalebot.
by masklinn
3/25/2026 at 11:52:05 PM
Or even non-software tickets at large corporations. I reported a water dispenser filling too slowly at my office because it took me a few tries just to fill my 1L water bottle. They said it was fixed and closed it.It was not fixed. So I took a video of myself refilling my water bottle, attached it to the ticket, and re-opened it. They actually fixed it after that. The video was 2m12s long (and I spent god knows how long making the video file small enough to attach to the ticket lol)
by MiddleEndian
3/26/2026 at 2:35:31 AM
this is actually a good example of how a more detailed issue will have a higher chance to be addressed. I don't know what information that's your previous report is lacking, but the video certainly give more information that the maintainer can pinpoint the cause and act on it. The ability to pinpoint the cause from the report is a godsent for maintainers, it drastically reduce the time to investigate the cause, thus able to act immediately.Some of the information in this can may be:
* how "slow" exactly the process is related with normal behavior. If it's just said "slow" on previous report, it's easy to be dismissed
* the dispenser's behavior, such as if the water flow is consistently low volume or clogged intermittently, or if the dispenser is struggling to fetch from water source, etc
by fendy3002
3/26/2026 at 11:20:50 AM
I'd say it was both. I gave a pretty detailed explanation before, far more detailed than my post here, including a timeline of when it filled in one shot, then two shots, and then three or four (can't remember). I doubt they actually checked before the video. But I was very motivated to fix the issue so I gave them proof lolby MiddleEndian
3/26/2026 at 1:57:21 PM
More importantly it shows how the reporter actually used the system to trigger the undesired behavior. Just because something is obvious to you doesn't mean it will be obvious to whoever is looking at the bug report.by account42
3/25/2026 at 10:09:33 PM
Take a look at Anthropic's repo. They auto-close issues after just a few weeks.I don't think I've seen an issue of theirs that wasn't auto-closed.
by bmitc
3/26/2026 at 12:17:46 AM
Wait, isn’t software engineering a solved problem?by tchalla
3/26/2026 at 2:01:33 AM
Yes, that’s why they have such great up time. They don’t go down multiple times per day.by what
3/26/2026 at 1:35:49 AM
Yesby vpShane
3/25/2026 at 9:34:40 PM
Fuck stalebot.by IshKebab
3/25/2026 at 10:25:21 PM
All my homies hate stalebotby monster_truck
3/26/2026 at 1:23:41 PM
What about OSS weekend ?by tkfoss
3/25/2026 at 11:07:11 PM
As an open source maintainer, I feel that statement is really unfair. Yes, we do sometimes close bug reports without evidence they are fixed. But:- We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.
- Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed. That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.
by afdbcreid
3/26/2026 at 2:08:10 AM
It's not about expectation of work (well, there's some entitled people sure.)It's about throwing away the effort the reporter put into filing the issue. Stale bots disincentivise good quality issues, makes them less discoverable, and creates the burden of having to collate discussion across N previously raised issues about the same thing.
Bug reports and FRs are also a form of work. They might have a selfish motive, but they're still raised with the intention of enriching the software in some way.
by cedws
3/26/2026 at 5:22:58 AM
IMO closing issues via stale bot is fine, the problem is locking issues so that no further conversation is allowed on the issue. Multiple times, I've encountered multi-year old issues (which is usually not fixed due to the fix not being simple or compatible with the current architecture). There's usually a good amount of conversation between users offering workarounds (and those workarounds updated for newer versions) - till stale bot locks the issue.by calmingsolitude
3/26/2026 at 8:23:59 AM
This 1000%. Whoever came up with the idea of closing and locking issues because no one has posted on them for awhile is at best not all that bright and at worst downright sinister.Closing an issue due to staleness is one thing, locking it is another.
by rezonant
3/25/2026 at 11:54:24 PM
> That means that when we close the issue, we believe it has a high chance of being fixedI agree with this iff it's being done manually after reading the issue. stalebot is indiscriminate and as far as "owing" the user, that's fair, but I'd assume that the person reporting the bug is also doing you a favor by helping you make things more stable and contributing to your repo/tool's community.
by xmprt
3/26/2026 at 12:09:51 AM
I partially agree, but even with stalebots nobody is measuring the maintainers' productivity. So when they made the choice to use stalebots, they did that because they believe that's best for the project. It's different from corporate.by afdbcreid
3/26/2026 at 2:00:08 AM
Nobody is measuring their productivity, but people definitely look at how many open issues they have and potentially how long those issues have existed. They’re likely incentivized to close issues for appearances.by what
3/26/2026 at 4:10:24 AM
With a popular open source project, you'll quickly get to a number of bug reports that you have no chance of ever solving. You will have to focus on the worst ones and ones affecting most users.At the same time, you want to communicate to users that this is the case so they don't have wrong expectation. But also, psychologically it is demotivating to have a 1000+ open bugs queue with no capacity to re-triage and only two maintainers able to out a few fours in every month or every week.
In open source, "won't fix" means either "not in scope — feel free to fork" or "no capacity ever expected — feel free to provide a fix".
The optimization problem is how do you get the most out of very limited time from very few people, and having 1000+ open bugs that nobody can keep in their head or look for duplicates in is mentally draining and stops the devs from fixing even the top 3 bugs users do face.
by necovek
3/26/2026 at 2:23:44 PM
The problem is that your users also have limited time and if it's clear you're not even looking at issues where someone has put in lots of effort to help you then you're only going to get lazy issues and it will actually take more effort from you to do all that work yourself if you want to reach the same software quality.by account42
3/26/2026 at 2:05:06 PM
> We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.Users also don't owe you anything either. Auto-closing reports without even looking at them is like asking for donations only to throw 90% of what you get straight into the trash. Not cool. If you don't want bug reports, state that up front or at least leave bugs open for other users to see and talk about. Otherwise, users are free to warn others to stay away from you and your projects.
And that's before getting into more complex issues like what responsibility you have if you take on maintenance of existing software and end up breaking something what was working perfectly for some users.
> Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed.
There are plenty incentives, e.g. pride.
> That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.
That's fine, but bots that auto-close issues unless the reporter dances for them is the opposite of that.
by account42
3/25/2026 at 11:35:44 PM
Why do you close the issue then?by NetMageSCW
3/26/2026 at 12:07:55 AM
Because I have a reason to believe it's fixed, I have many more like it and it's difficult to reproduce. Simple :)by afdbcreid
3/26/2026 at 9:58:02 AM
You have no evidence that it's fixed, but you have reason to believe it's fixed?by saagarjha
3/26/2026 at 10:16:01 AM
>Because I have a reason to believe it's fixedWhat reason?
by alickz
3/25/2026 at 11:55:58 PM
Because open source is corporate nowby eleumik
3/25/2026 at 11:10:03 PM
I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.by 98codes
3/26/2026 at 7:27:41 AM
I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare.I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.
by opan
3/26/2026 at 2:57:26 AM
> the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything.We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system.
That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.
by magicalhippo
3/26/2026 at 8:58:33 AM
Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.by Nekorosu
3/26/2026 at 3:34:19 AM
I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.
by farhanhubble
3/25/2026 at 10:12:59 PM
> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.
by lapcat
3/25/2026 at 10:23:23 PM
Companies have no consciences.by loloquwowndueo
3/25/2026 at 10:28:57 PM
Companies are made of humans who do.by parasubvert
3/26/2026 at 9:15:16 AM
I guess that explains why social media companies try to maximize engagement even though it is almost bad for your mental health in every way.Or does it?
by g947o
3/26/2026 at 6:41:38 AM
I think you and I have had vastly different experiences of the normal level of conscience in companies.by ikiris
3/26/2026 at 10:56:34 AM
So was the Nazi regime, and yet…by loloquwowndueo
3/25/2026 at 11:11:19 PM
I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.by crest
3/25/2026 at 9:28:58 PM
If you are a veteran of software in a big company, we all know there will be weekly or bi-weekly meetings that some PM will set up. All the PM will do is go over the JIRA tickets and be like "is this still happening". Default answer is "no", as in "I didn't even try to reproduce it, do you think I have time to even do it?". Default answer by spineless QA person is also "didn't try it again yet". Then, the PM closes the ticket. It is much easier for QA person to say "Yes I verified it" if you are remote and developer cannot see the lies on your bad poker face.by bloodyplonker22
3/25/2026 at 9:49:46 PM
Ooh this gives me an interesting passive-aggressive idea to counter pointless "is this still relevant" questions. "No, I haven't hit this in the last 2 days." "No, I haven't hit this since I gave up trying to do it with your tool." And so forth.The less passive-aggressive version is to use this obviously-unhelpful answer of the obviously-unhelpful question, to actually have a conversation to get the PM to recognize that the default state of a ticket is in fact "no change." Ultimately that may turn into a stale bot if the PM realizes the policy they actually want is some sort of timeout, but at least it's not a time consuming meeting!
(Note, a cathartic thought experiment, but not really good manners to actually do!)
by thrtythreeforty
3/25/2026 at 10:29:59 PM
Absolutely spot on LOLby gib444
3/26/2026 at 2:56:34 AM
I mean if the customer stops complaining, either the bug was fixed, or the bug was not too important to begin with, or they are not a customer anymore and nobody else cares about that niche bug. In all of the above closing the ticket sounds reasonable.What is not reasonable is that they close issues with thousands of “I have this issue too” with active complains and full repros
by whatever1
3/25/2026 at 11:22:38 PM
Hi, bigcorp employee getting showered with tickets here.I don't have enough time in the day to deal with the tickets where the reporter actually tries, let alone the tickets where they don't.
If I tell you to update your shit, it's because it's wildly out of date, to the point that your configuration is impossible for me to reproduce without fucking up my setup to the point that I can't repro 8 other tickets.
by ryukoposting
3/25/2026 at 11:36:43 PM
Back when I worked at Apple I would just try it in whatever I had installed. If it didn't reproduce I'd write "Cannot reproduce in 10.x.x" and close it. Maybe a third were like that, duplicates of some other issue that was resolved long ago.Anyone that attached a repro file to their issue got attention because it was easy enough to test. Sometimes crash traces got attention, I'd open the code and check out what it was. If it was like a top 15 crash trace then I'd spend a lot longer on it.
If the ticket was long and involved like "make an iMovie and tween it in just such and such a way" then probably I'd fiddle around for 10-15 minutes before downgrading its priority and hope a repro file would come about.
There were a bunch of bug reports for a deprecated codec that I closed and one guy angrily replied that I couldn't just close issues I didn't want to fix!
Guess what buddy, nobody's ever going to fix it.
The oldest bug like that I ever fixed was a QuickDraw bug that was originally written when I was 8 years old but it was just an easy bounds check one liner.
But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.
by CoolGuySteve
3/26/2026 at 12:02:53 AM
> But the mistake OP is making is assuming this one thing that annoyed him somehow applies to the whole Apple org. Most issues were up to engineers and project managers to prioritize, every team had their own process when I was there.Except this same shit keeps happening with multiple teams.
Judging from your mention of QuickDraw, which was removed entirely from macOS in 2012, perhaps your Apple experience is now out of date.
by lapcat
3/26/2026 at 12:05:29 AM
Nah, you're just making shit up.by CoolGuySteve
3/26/2026 at 12:18:25 AM
What specifically do you claim I'm making up?by lapcat
3/26/2026 at 12:21:56 AM
That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculousby CoolGuySteve
3/26/2026 at 6:08:29 AM
> That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculouIt's pretty clear from experience that the organization policy is to not provide feedback on bug submissions. Getting a 'check it if still reproduces or we'll close it in two weeks' message after 3 years is actually a fast turnaround.
Best I've gotten was on an issue I routed to a friend who worked at Apple who promised it would get looked at, but that I wouldn't hear back.
Microsoft wouldn't fix my issues either, but at least they got back to me in a timely fashion. Usually telling me it was a known issue that they weren't going to fix.
by toast0
3/26/2026 at 12:06:48 PM
You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company.Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps.
But sometimes that duplicate marking is wrong or some subtly different issue so they ask you if it still reproduces in whatever version contains the fix before closing it.
by CoolGuySteve
3/26/2026 at 2:57:33 PM
That makes sense. But when you take 3-5 years to respond to my bug report, I'm going to take at least 3 months to respond to your response. And I'm probably not filing more bugs, because chances are I won't be at my current employer by the time you reply.When you consitently burn bug reporters, sooner or later there's nobody to file bugs.
by toast0
3/26/2026 at 3:57:54 PM
Because that's probably how long it took for someone to prioritize it.Even if it's not fixed by the dupe ticket, the volume of bug reports makes it almost certain another ticket for the same issue will come up. And if it doesn't then it probably wasn't that relevant to anyone.
by CoolGuySteve
3/26/2026 at 12:30:31 AM
Not my tickets specifically. I don't think they're out to get me individually. On the contrary, this is a common practice, which affects many developers. I just happen to be relatively loud, as far as blogging is concerned.by lapcat
3/26/2026 at 1:01:28 AM
Yes I understand that. ~50000 engineers aren't conspiring to close all tickets that way. It's a stupid line of thinking.More than likely your steps to reproduce are too laborious to receive attention relative to the value fixing the bug would provide. That's why they're asking you to verify it still happens. Seems pretty simple right?
There's also a strong chance your ticket was linked as a duplicate of some other issue that was fixed in the beta and they want you to verify that's the case but they won't expose their internal issue to you for a variety of reasons.
by CoolGuySteve
3/26/2026 at 1:13:49 AM
> ~50000 engineers aren't conspiring to close all tickets that way.I didn't say that either. It's happened to me only sporadically, but multiple times.
I agree with you that teams within Apple manage their own tickets. Perhaps some individual teams are declaring bug bankruptcy at some point, so only their bugs would go out for verification. I don't really know. I wish I did. What I do know is that multiple teams have done this at different points.
There's indisputably a company-wide DevBugs canned response for this. It's the same exact language every time. You can even Google it.
> It's a stupid line of thinking.
Please respect the HN guidelines: https://news.ycombinator.com/newsguidelines.html
> More than likely your steps to reproduce are too laborious to receive attention. That's why they're asking you to do it.
It was much more laborious for me, because I do not install the macOS betas.
> Seems pretty simple right?
No, it doesn't explain why specifically, after 3 years, they were suddenly asking me to verify with macOS 26.4 beta 4.
by lapcat
3/25/2026 at 11:34:35 PM
Yes that's a thing, but never with external customers in public betasby breppp
3/25/2026 at 11:44:08 PM
I think that's entirely dependent on the workload the company is placing on their support staff. If Apple decides the techs should be handling 10 tickets at once, then the techs have a choice:1. Tell everyone to update their shit, and close tickets if they don't.
2. Waste several hours per day uninstalling and reinstalling 10 versions of the same program.
One of these will allow you to close lots of tickets immediately, and handle the remaining ones as efficiently as possible. Yay! Good job, peon! You get a raise!
The other approach will result in a deep backlog, slow turnaround times, and lower apparent output from management's perspective. Boo! Bad job, peon! You're fired!
by ryukoposting
3/25/2026 at 11:33:56 PM
Please tell us where you work so we can avoid all of your company’s software. Unless it’s Microsoft, because we’ve already seen the results of that attitude there.by NetMageSCW
3/25/2026 at 11:48:11 PM
I don't see how it's an unreasonable request. If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically. You will be prioritized last, because my effectiveness is measured by how many tickets I close.by ryukoposting
3/26/2026 at 1:14:33 AM
just bc everyone is calling you insane: you are being extremely reasonable.by tefkah
3/26/2026 at 4:08:45 AM
Flagging isn't supposed to be used as a super downvote.There's a term for the bizarre behavior and thought processes (read: justification) by the person you're responding to. <https://en.wikipedia.org/wiki/Occupational_psychosis>
> you are being extremely reasonable
They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of the company, and 10 customers, say the same things they're saying here, and get a consensus that this is how this should all work out.
by cxr
3/26/2026 at 3:13:21 PM
Did I say it's how it should be, or did I say this is how it is?It's a reasonable request given the unreasonable nature of my working conditions, a thing I have no power to change.
by ryukoposting
3/26/2026 at 4:03:31 PM
You are an exasperatingly selfish and un-self-aware person. You should not be mentoring children. This is enshittification personified:> One of these will allow you to[…] get a raise
> given the unreasonable nature of my working conditions, a thing I have no power to change
You know that there are people who experience actual hardship, right?
by cxr
3/26/2026 at 7:47:17 PM
[dead]by gopher_space
3/25/2026 at 11:57:34 PM
> If you demand that I work with some ancient version, I then have to install and uninstall said program every time I work on your ticket specifically.You completely missed the point of the blog post. Apple was in the process of developing macOS 26.4 beta 4, and they wanted me to install the beta just to "verify" the bug.
Apple could test my bug with 26.4 beta 4 a heck of a lot easier than I could. Nobody was asking Apple to install some ancient version.
> my effectiveness is measured by how many tickets I close.
That was one of the points of the blog post: this is a perverse incentive from management.
Note what you did not say: "my effectiveness is measured by how many bugs I fix." So engineers are incentivized to close tickets even if the bugs they report are unfixed. This is how a company ends up with crappy, buggy software.
by lapcat
3/26/2026 at 12:17:41 AM
I'm with you on the Apple thing, that's asinine.The parent comment is talking about the broader practice of people telling you to update and then repro again. That's a completely legitimate thing to ask, given both the perverse corporate incentives and the basic reality that version toggling makes a tech far less efficient at solving all tickets, not just yours.
by ryukoposting
3/25/2026 at 11:53:04 PM
[flagged]by cxr
3/26/2026 at 12:33:10 AM
You missed the point entirely.I also ask to say what company you're working for so I can avoid your bullshit attitude.
And hey, you will have less bug reports that way so please tell us
by PunchyHamster
3/25/2026 at 10:06:15 PM
I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical.A bug is a bug, no matter the developers' opinion or the complexity of the bug.
by bmitc
3/26/2026 at 2:32:59 PM
However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.by account42
3/25/2026 at 9:18:45 PM
[dead]by lucasay
3/26/2026 at 2:49:25 AM
[dead]by tonetheman