There is some bot that will match your issue to some other 3 vaguely related issue, then auto close in 3 days. The other vaguely related issues are auto closed for inactivity. Nothing is ever fixed, which is why they can't keep the thing from messing with your scroll position for years now.
Mozilla is famous for having 20 year old bug reports that gets fixed after all that time.
If you're not testing your code under extreme latency it will almost certainly fail in all kinds of hilarious ways.
I spend a lot of time with 4G as my only internet connection. It makes me feel that most software is quickly produced, poorly tested, and thrown out the door on a whim.
When I close an old bug that is not actionable, I do feel bad about it. But keeping the bug open when realistically I can't really do anything with it might be worse.
In any case I would have said it sounds difficult on every front
https://devblogs.microsoft.com/oldnewthing/20241108-00/?p=11...
I've heard this from others before but I really don't understand the mindset.
What's the harm in keeping the bug open?
Each and every Radar (Apple's internal issue tracker is called Radar, and each issue is called a Radar) follows a state machine, going from the untriaged state to the done state. One hard-coded state in this is Verify. Each and every bug, once Fixed, cannot move to Closed without passing through the Verify state. It seems like a cool idea on the surface. It means that Apple assumes and demands that everything must be verified as fixed (or feature complete) by someone. Quite the corporate value to hold the line on, and it goes back decades.
I seriously hated the Verify state. It caused many pathologies. Imagine trying to run a burndown of your sprint when zero of the Radars are closed, because they have to be verified in production before being closed, meaning you cannot verify until after the release. Another pathology is that lots (thousands and thousands) of Radars end up stranded in Verify. Many, many engineers finish their fix, check it in, it gets released and then they move on. This led to a pathology that the writer of this post got caught up in: There is lots of "org health" reporting that goes out showing how many Radars are unverified and how long your Radars stay in the unverified state on average. A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this.
1. Apple engineers actually attempted to fix the bug.
2. Feedback Assistant "Please verify with the latest beta" matches the Radar "Verify" state.
I don't believe either of those are true.
In this case the bug wasn't fixed.
> A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this.
The simple solution here: you should also be graded on closing bugs that get re-opened.
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.
I’ll fill out a bug report, wait a few days to a week to get a response, which are often AI generated, and then 48 hours afterward their bot marks it as stale. Telling me to check if it’s still broken or they assume it’s fixed lol
A good compromise might be select high quality bugs or users with good rep and disable auto-closing for them. In the age of AI it shouldn't be too hard to correlate all those low quality duplicates and figure out what's worth keeping alive, no?
cozzyd•36m ago
jeffbee•33m ago
methodical•26m ago
jeffbee•23m ago
Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.
convolvatron•22m ago
if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.
otherwise you're just throwing away useful information.
edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
jeffbee•20m ago
eszed•17m ago
Barbing•9m ago
Apple has done the best job of creating this expectation.
Apple Feedback = compliments (and ideas)
Public Web = complaints & bug reports
Apple Support = important bug reports (can create feedback first then call immmediately)
—
Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541
ComputerGuru•17m ago
gortok•33m ago
The sentiment feels like software folks are optimizing for the local optimum.
It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a policy.
jlarocco•27m ago
As a software developer, I don't have any problem with this. If a bug doesn't bother somebody enough for them to follow up, then spend time fixing bugs for people who will. Apple isn't obligated to fix anybody's bug.
It's not like they were nagging him about it - it's been years, and they had major releases in the mean time. Quite possible it was fixed as a side effect of something else.
Noaidi•25m ago
…yet
eszed•24m ago
Barbing•11m ago
:)
Funny at first but I’m coming around to that perspective
gortok•9m ago
I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated).
We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph.
Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more."
We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.
kace91•27m ago
You feeling accomplished by seeing an empty list is not the goal!
integralid•11m ago
lxgr•7m ago
That way, you’re at least not deluding yourself about your own capacity to triage and fix problems, and can hopefully search for and reopen issues that are resurfaced.
fweimer•11m ago
These auto-closing policies usually originate from somewhere else.
brigade•10m ago
Plus, I’ve been in jobs where fixing bugs ends up being implicitly discouraged; if you fix a bug then it invites questions from above for why the bug existed, whether the fix could cause another bug, how another regression will be prevented and so on. But simply ignoring bug reports never triggered attention.