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

Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.

> Author must not have worked in enterprise software before.

Or with open source projects. Fucking stalebot.

I got reeeeally good at producing repro gifs that I could plug straight inline into email replies to "can't repro"; it's forever clear that most developers either don't know how to test the product they are building, or simply can't be bothered to try.

I've been on both sides of this. Absolutely sucks as a user falling prey to stalebot or some poor sap pretending to be stalebot, but when I was working in enterprise tech support it was a huge relief to close a case and get it off my plate, for any reason. We had to take 2 new cases per day minimum, update each case (I often had 20+) every few days minimum. Only a small minority were a quick and easy solution (like security vulns with a fix ready we could send the customer were the easiest). We were stuck with our cases also, you couldn't give them to someone else unless you were out sick pretty much, and you'd get them back when you returned unless by some miracle the other guy fixed their problem. An inactivity close on a stalled case was comforting, I was finally free. I think they started cracking down after a bit and said you had to check in with them 3 times x days apart first instead of just immediately closing after no word for 2 weeks, and then they wanted you to call them first. Absolute nightmare.

I think as long as the issue isn't stuck with any one person then it's easier to leave open until it's actually fixed, like the 20+ year old Mozilla bug reports. Big corpo bureaucratic nonsense just ruins everything.

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

We do this. Because frankly, very often the bug has been reported by others and has been fixed, we just can't connect the dots in our ticketing system.

That's of course less than ideal, but given that a lot of tickets we get are often very poorly described it's hard. It's one aspect I have genuine hope AI can help us with.

Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.

I wish someone had told me how common this was back when I worked myself to death fixing every UI abnormality that no one except some misincentivized testers used to report at my first job. At the time I thought it was dishonest to say something was irreproducible and it'd be beneath me to patch an issue knowing it'll sprout ten others.

I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.

> Of course, the only way to counter this is by saying "Yes I verified it" without actually verifying it.

I'm not going to lie. That's not who I am. If Apple really wants to close a bug report when the bug isn't fixed, that's on their conscience, if they have one.

I've worked with enterprise software. The result its that people will eventually just wait a few hours/days and lie if they even care enough to do that. The perverse incentives destroy what utility a bug tracker could bring. Int theory transparency could help by changing the incentives if third parties analyze the metrics and call out bullshit to an audicence that matters.

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.

I mean if the customer stops complaining, either the bug was fixed, or the bug was not too important to begin with, or they are not a customer anymore and nobody else cares about that niche bug. In all of the above closing the ticket sounds reasonable.

What is not reasonable is that they close issues with thousands of “I have this issue too” with active complains and full repros

Hi, bigcorp employee getting showered with tickets here.

I don't have enough time in the day to deal with the tickets where the reporter actually tries, let alone the tickets where they don't.

If I tell you to update your shit, it's because it's wildly out of date, to the point that your configuration is impossible for me to reproduce without fucking up my setup to the point that I can't repro 8 other tickets.

I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical.

A bug is a bug, no matter the developers' opinion or the complexity of the bug.

[dead]

[dead]