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.

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.

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

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.

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.

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?

My favorite is the Claude Code bugtracker, on GitHub of course: https://github.com/anthropics/claude-code/issues

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.

The sheer volume of bug reports negates the perceived importance

Stop wasting your life chomping at the bit to do unpaid labor for the sole benefit of megacorps.

The radar count is probably nearing a billion at this point