Discussion
Apple randomly closes bug reports unless you “verify” the bug remains unfixed
cozzyd: to be fair this is pretty common spring cleaning in any bugzilla...
jeffbee: It's very common but it's still a poor practice.
stefan_: My favorite is the Claude Code bugtracker, on GitHub of course: https://github.com/anthropics/claude-code/issuesThere 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.
kvirani: Oh so it jumping to the top happens to others too?
hector_vasquez: Former Apple employee here. This is a deeper quirk of Apple culture than one would guess.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.
zer00eyz: Interesting insight to what should be a good internal process if users followed up.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.
eminence32: I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test.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.
hart_russell: A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it
wat10000: That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.
Barbing: Ignorant question, if privacy didn’t matter and they had an atomically identical machine, would there still be plenty of edge cases where it was the printer or the Wi-Fi causing the issue?In any case I would have said it sounds difficult on every front
youarentrightjr: > keeping the bug open when realistically I can't really do anything with it might be worseI've heard this from others before but I really don't understand the mindset.What's the harm in keeping the bug open?
eminence32: I don't work at Apple, so I can't comment on that. But that doesn't always help. There's been plenty of times where I have a full HAR file from the user and I can clearly see that something went wrong, but that doesn't always mean I can reproduce the issue. (I recognize a HAR file doesn't represent the complete state of the world, but it's often one of the best things a backend developer can get)
fragmede: Reminds me of this Raymond Chen Microsoft blog post:https://devblogs.microsoft.com/oldnewthing/20241108-00/?p=11...
gjvc: [delayed]
_blk: The replies here suggest that many of us have been on both sides and that Apple's behavior it's a great way to trade bug triaging time on the org side for a few frustrated reporters on the customer side. The problem is it frustrates the most diligent of bug reporters who put time into filing high quality issues resulting in overall lower bug submission quality.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?
gjvc: [delayed]
gortok: I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue."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.
kace91: I've seen this in many teams and it always drives me nuts: "hey this ticket is old and we didn't bother, let's delete it to keep the board clean".You feeling accomplished by seeing an empty list is not the goal!
integralid: Feeling overwhelmed by insurmountable mountain of bugs and issues is not the way either. We can argue that closing the tickets is not the best way, but if realistically nobody will ever look at them, why not make the developers feel better.
lxgr: Move them to a deficated status. “Never triaged”, “lost”, “won’t do”, what have you.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.
mikkupikku: Bug Bankruptcy.
freediddy: 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.
Leherenn: 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").
jlarocco: Considering Apple is one of the largest companies in the world, raking in money, what consequential effects are you talking about? It certainly doesn't seem to hurt their bottom line, which is the only thing they care about.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.
gortok: > It certainly doesn't seem to hurt their bottom line, which is the only thing they care about.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.
methodical: Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
eszed: Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
Barbing: >creates the user expectation that "no one looks at theseApple has done the best job of creating this expectation.Apple Feedback = compliments (and ideas)Public Web = complaints & bug reportsApple Support = important bug reports (can create feedback first then call immmediately)—Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541
kibwen: Stop wasting your life chomping at the bit to do unpaid labor for the sole benefit of megacorps.
spike021: At work I literally just spent a half hour meeting with colleagues doing backlog management to clear out old bugs that were random one-offs and never came up again.Pretty standard process.
yuters: I've submitted a couple of issues for their [javascript library for Live Photos](https://developer.apple.com/documentation/LivePhotosKitJS).One being that the most recent version is on their cdn but not their [npm package](https://www.npmjs.com/package/livephotoskit?activeTab=readme) which was never updated for 7 years. You know what they did with this issue? They've marked it as "Unable to diagnose".Also I've mentioned something about their documentation not being up to date for a function definition. This issue has remained open for 4 years now.
wat10000: I should be more precise. Capturing the system state isn’t too hard. Turning that into a reproducer may be quite hard, because of things like you say. There are certainly a lot of bugs that such a capture would make easier to figure out, but it wouldn’t be a panacea.
bloodyplonker22: 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.
jldugger: > 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.I think most teams use verify as a "closed" state to hide all that messiness. But sure, zero bugs is a project management fiction and produces perverse outcomes.
masklinn: > Author must not have worked in enterprise software before.Or with open source projects. Fucking stalebot.
IshKebab: Fuck stalebot.
jas-: The sheer volume of bug reports negates the perceived importance
groundzeros2015: Deficated?
