Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple randomly closes bug reports unless you "verify" the bug remains unfixed

lapcatsoftware.com

Post reply on HN
Print view View original

71–80 of 314 posts

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#71

Post by bloodyplonker22 »

freediddy wrote: post #23

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 actu…

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.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#72

Post by torben-friis »

integralid wrote: post #37
torben-friis wrote: post #14

Earlier quoted context omitted.

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!

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.

Either you truly need to fix the bugs, in which case the feeling is good and maybe more effort should go that way (more resources assigned to it or whatever), or you're at a scale where tackling everything is impossible and you shouldn't feel overwhelmed by seeing the noise then.

But I think modern industry pretends all it's fine to convince themselves that it's ok to chase the next feature instead.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#73

Post by dddgghhbbfblk »

jFriedensreich wrote: post #38

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.

That's impressive. I've only reported one bug to Chromium, years ago. It was a bug in their CSS engine and I included an HTML file with a full repro. It took them a few years to actually fix it since the person who was initially assigned it never bothered, eventually left Google, and nobody picked it back up for a while. But they did eventually fix it, so that's something, I suppose.

Edit: this comment elsewhere in the thread is closer to my experience: https://news.ycombinator.com/item?id=47523107 Certainly in my own stint at Google I saw the same thing--bugs below a certain priority level would just never get looked at.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#74

Post by thewebguyd »

ChrisMarshallNY wrote: post #52

> 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 e…

> they basically insist that I become an unpaid systems engineering QC person

Microsoft support is guilty of this, especially for Azure & 365 issues.

Like sorry, but you aren't paying me to debug your software. Here's a report, and here's proof of me reproducing the problem & some logs. That's all I'm going to provide. It's your software, you debug it.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#75

Post by IshKebab »

masklinn wrote: post #61
freediddy wrote: post #23

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 actu…

> Author must not have worked in enterprise software before. Or with open source projects. Fucking stalebot.

Fuck stalebot.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#76

Post by AlBugdy »

cletus wrote: post #55

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…

> Google had their own versions of things. IIRC bugs had both a priority and severity for some reason (they were the same 99% of the time) between 0 and 4.

At the company I worked with (not Google, but a major one) this was the same. We used Salesforce, the "Lightning Experience" or whatever it was called [0]. Our version was likely customized for our company, but I think the idea was the same - one, I think the "priority", was for our eyes only, one was for the customer (the "severity"). If the customer was insistent on raising the severity, we'd put it as sev1, but the priority was what we actually thought it was. I was actually surprised that for the ~4 years I was there no one made the mistake of telling the customer the priority as a mistake, especially when a lot of people were sloppily copy-pasting text from Slack or other internal tools that sometimes referred to a case as either the severity or the priority.

Those were heavy customers with SLAs, though, not supermarket apps or anything like that.

What was sad was that our internal tools, no matter how badly written, with 90's UI and awful security practices, our tools were 50 times as fast as whatever Salesforce garbage we had to deal with. Of course, there was a lot of unneeded redundancy between the tools so the complexity didn't stay in the Salesforce tool. But somehow the internal tools written by someone 10 years ago, barely maintained, who had to still deal with complex databases of who-what-when-how, felt like you had the DB locally on a supercomputer while SF felt like you were actually asking a very overworked person to manually give you your query right on each click. I'm exaggerating, but just by a bit.

[0] That name was funny because it was slow as shit. Each click took 5 to 20 seconds to update the view. I wonder what the non-Lightning version was.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#77

Post by jldugger »

hector_vasquez wrote: post #19

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…

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

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#78

Post by beembeem »

freediddy wrote: post #23

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 actu…

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.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#79

Post by groundzeros2015 »

lxgr wrote: post #46
integralid wrote: post #37

Earlier quoted context omitted.

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.

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.

Deficated?
Post reply on HN