Independent of Apple, I think we need an industry wide of saying "I'm not an idiot, this bug report is real". I've been on both sides (in a moderately used OSS project). The main problem is that the attending doesn't have a good way to filtering the noise from the signal. As a result, the likes of Apple (and the other FAANGs) implement these aggregate-and-discard blackholes for bug reports. "Only a 0.1% increase in crashes? Ship it" is the way the story goes sadly.
>The main problem is that the attending doesn't have a good way to filtering the noise from the signal.
Even if you could filter the noise; there's still a non-zero chance it won't get prioritized. I imagine in Apple's case you could have very real bug reports that only affect 500,000 people and they can't allocate time to fix this. I think there's a tendency to anthropomorphize companies (and OSS projects) as an all knowing person who can fix every problem and has infinite time. In reality there might be 10 people (or in OSS, just 1 person) in the company uniquely capable of triaging your issue in under an hour. The rest would be just as lost as you would be in a new code base and they have to weigh fixing your bug report vs the other opportunities they have (and I'm sure at Apple, closing Radar tickets wont get you promoted).
Maybe after two years of engineering experience you get one “this is real” token to use on an issue. If you use it and the issue actually is real you get the token back. If not you have to do two more years of engineering work to get a new token.
As an OSS maintainer, the way to show this is to show up with a full reproduction. "Run exactly this and it crashes".
Can't reproduce it? Well... you can of course still report it but "I'm not an idiot" is a pretty weak signal. Everyone gets lost in the weeds, and debugging a problem only for it to be an issue in some unstated part of the project is very exhausting.
As someone that has recently opened a bug report on a popular open source project, with a very simple and 100% effective reproduction process, I had a back and forth with the maintainer telling me to "what happens if you do X instead?"
What is the point of me providing an example case if the ones that know the internals of their code don't try to reproduce my bug?
Yeah, I know OSS devs do not have time/are unpaid. My point is however complete your bug report is, nothing guarantees it won't go stale without anyone having taken a real look at it. In my experience 90% of bug reports, on OSS or commercial products, die this way.
