HN

Comments (166)

• Menu

  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.
• Menu

  ChrisMarshallNY
  > perhaps praying that the bug had magically disappeared on its own, with no effort from Apple.I suspect that this is a common approach. It maybe even works, often enough, to make it standard practice.For myself, I've stopped submitting bug reports.It's not the being ignored, that bothers me; it's when they pay attention, they basically insist that I become an unpaid systems engineering QC person, and go through enormous effort to prove the bug exists.
• Menu

  BrenBarn
  All kinds of open source projects do this too. It's really annoying. It's one thing if the authors actually try and fail to verify the bug, but these days it seems like most projects just close "stale" bugs as a matter of course. This is equivalent to assuming that any given bug is automatically fixed after X amount of time, which is pretty absurd.
• Menu

  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.
• Menu

  cletus
  Story time. I used to work for Facebook (and Google) and lots of games were played around bugs.At some point the leadership introduced an SLA for high then medium priority bugs. Why? because bugs would sit in queues for years. The result? Bugs would often get downgraded in priority at or close to the SLA. People even wrote automated rules to see if their bugs filed got downgraded to alert them.Another trick was to throw it back to the user, usually after months, ostensibly to request information, to ask "is this still a problem?" or just adding "could not reproduce". Often you'd get no response. sometimes the person was no longer on the team or with the company. Or they just lost interest or didn't notice. Great, it's off your plate.If you waited long enough, you could say it was "no longer relevant" because that version of the app or API had been deprecated. It's also a good reason to bounce it back with "is still this relevant?"Probably the most Machiavellian trick I saw was to merge your bug with another one vaguely similar that you didn't own. Why? Because this was hard to unwind and not always obvious.Anyone who runs a call center or customer line knows this: you want to throw it back at the customer because a certain percentage will give up. It's a bit like health insurance companies automatically sending a denial for a prior authorization: to make people give up.I once submitted some clear bugs to a supermarket's app and I got a response asking me to call some 800 number and make a report. My bug report was a complete way to reproduce the issue. I knew what was going on. Somebody simply wanted to mark the issue as "resolved". I'm never going to do that.I don't think you can trust engineering teams (or, worse, individuals) to "own" bugs. They're not going to want to do them. They need to be owned by a QA team or a program team that will collate similar bugs and verify something is actually fixed.Google had their own versions of things. IIRC bugs had both a priority and s everity for some reason (they were the same 99% of the time) between 0 and 4. So a standard bug was p2/s2. p0/s0 was the most severe and meant a serious user-facing outage. People would often change a p2/s2 to p3/s3, which basically meant "I'm never going to do this and I will never look at it again".I've basically given up on filing bug reports because I'm aware of all these games and getting someone to actually pay attention is incredibly difficult. So much of this comes down to stupid organizational-level metrics about bug resolution SLAs and policies.
• 16mb
  I’ve been dealing with ElevenLabs pulling this same garbage.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
• Menu

  jFriedensreich
  My only positive experience reporting bugs post early startup was with the chromium team, i get usually assigned to a dedicated reproducer that verifies and is reachable for helping them recreate in a matter of a few days. I had two experiences where bugs were taking less than a week from report to fix in canary.
• Menu

  cozzyd
  to be fair this is pretty common spring cleaning in any bugzilla...
• 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.
• LorenPechtel
  Observation: Long, long ago I submitted a bug to Microsoft. I was new at the time and didn't distill it down to the minimum, just gave a scenario that would 100% reproduce. I was contacted months later because someone looked at it and couldn't reproduce.Yeah, I had found one manifestation of something else that they fixed by the time someone looked at it. The fix in the notes didn't look anything like my bug, only by observing that it now worked I was able to figure out that I had been the blind man trying to describe an elephant.
• Menu

  tottenhm
  In Scotland, they close an issue by taking a vote of "OK", "Broken", or "Not Proven".I believe they also have attorneys. Perhaps that's how Apple could make bug-tracking more effective -- hire a prosecuting attorney and a defending attorney for each bug.
• PunchyHamster
  That happens constantly everywhere, see github bots sometimes outright closing "stale" issues with nobody even trying to look at them
• Menu

  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.
• 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.
• Ensorceled
  I love that when I search for an odd behaviour or bug in macos or iOS, most of the time I will find a years old bug report with some irrelevant or useless "work around".This is not too unusual. I've completely given up on bug reports, it's almost always a complete waste of my time.I'm currently going around in circles with a serious performance issue with two different vendors. They want logs, process lists and now real time data. It's an issue multiple people have complained about in their forums and on reddit. The fact that this exact same thing is going on with TWO different companies ...
• s_u_d_o
  How can a user “verify” that the bug remains unfixed? So when a user reports a report, the user should check if the bug was solved after each update?
• Menu

  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.
• throwaway85825
  Can confirm. Java causes a bug in an Apple IO library that hasn't been fixed for years.
• jas-
  The sheer volume of bug reports negates the perceived importance
• kibwen
  Stop wasting your life chomping at the bit to do unpaid labor for the sole benefit of megacorps.
• arbirk
  The radar count is probably nearing a billion at this point
• dboreham
  There's a breed of Dilbert Manager that loves to do this everywhere. Optimizing for "fewer open bugs" I imagine.
• egorfine
  > Why do I file bug reports with Apple Feedback Assistant?It is known for decades that Apple largely ignores bugreports.
• Menu

  themafia
  > FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tabIf 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.
• SilverElfin
  Anthropic does this too
• mikkupikku
  Bug Bankruptcy.
• josefritzishere
  Devious.
• _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
  so what, jetbrains just doesn't fix them
• knorker
  Oh you sweet summer child. Everyone else does this.Yes, I hate it too.Put yourself in the position of the employee on the other side. They currently have 647 bugs in their backlog. And they also have actual work to do that's not even related to these bugs.You come to work. Over night there's 369 emails (after many filters have been applied), 27 new bugs (14 of which are against a previous version). You triage. If you think 8h is enough to deal with 369 emails (67 of which are actionable. But which 67?) and actually close 27 bugs, then… well then you'd be assigned another 82 bugs and get put on email lists for advisory committees.Before you jump to "why don't they just…", you should stop yourself and acknowledge that this in an unsolved problem. Ignore them, let them pile up? That's not a solution? Close them? No! It's still a problem! Ask you to verify it (and implicitly confirm that you still care)? That's… a bit better actually."Just hire more experts"… experts who are skilled enough, yet happy to work all day trying to reproduce these bugs? Sure, you can try. But it's extremely not a "why don't they just…".
• maltyxxx
  [dead]
• lucasay
  [dead]
• leontloveless
  [dead]
• wenldev
  [dead]
• tim-tday
  Fuck those guys.
• Menu

  DonThomasitos
  What else should they do? Stop releasing any updates until they reproduced any obscure bug report?