Some kind of acknowledgement would be nice, but nost of our feedback reports fall on deaf ears.
Apple randomly closes bug reports unless you "verify" the bug remains unfixed
211–220 of 314 posts
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#212Story 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…
> 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
I've seen this at a couple places... I think it's supposed to help model things like if something is totally down, that's an S0... But if it's the site for the Olympics and it's a year with no Olympics, it's not a P0.
Personally, that kind of detail doesn't seem to matter to me, and it's hard to get people to agree to standards about it, so the data quality isn't likely to be good, so it can't be used for reporting. A single priority value is probably more useful. Priority helps responsible parties decide what issue to fix first, and helps reporters guess when their issue might be addressed.
> 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 learned this behavior because closing with wontfix would upset people who filed issues for things that I understand, but am not going to change. I'm done with it, but you're going to reopen it if I close it, so whatever, I'll leave it open and ignore it. Stalebot is terrible, but it will accept responsibility for closing these kinds of things.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#213Earlier quoted context omitted.
There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.
What if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes? That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goos…
> Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.
Truenas literally takes this approach to bugs.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#214Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#215Earlier quoted context omitted.
I used to think that there is no harm in keeping the bug open. I think if you honestly feel that you have the time and resources to go back to the bug and fix it, then by all means keep it open. But I find that sometimes I can tell from experience that the IR is not actionable and that it will never be fixed. Some examples: * There's not enough info to reproduce the issue and the user either can't or won't be able to…
What does it cost you to keep the bug open?
Their team's bug close metrics
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#216Author 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.
[flagged]
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#217Earlier quoted context omitted.
Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
[flagged]
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#218Earlier quoted context omitted.
It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others). The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills your…
> It's rather unreasonable to be annoyed. I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.
Not really no, you got the support you were willing to pay for.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#219Expected behaviour, closing article.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#220Earlier quoted context omitted.
I used to think that there is no harm in keeping the bug open. I think if you honestly feel that you have the time and resources to go back to the bug and fix it, then by all means keep it open. But I find that sometimes I can tell from experience that the IR is not actionable and that it will never be fixed. Some examples: * There's not enough info to reproduce the issue and the user either can't or won't be able to…
I think asking someone if they can still reproduce an issue is valid. Especially if it was trivially reproducible for them, and now it isn't, that seems like a fine resolution, and the bug should be closed. But in the other cases, closing the bug seems to me to be a way to perturb metrics. It might be true that you'll never fix a given bug, but shouldn't there be a record of the "known defects", or "errata" as some c…
Bug reports are not known defects, at any kind of scale half of them will be already fixed, misunderstandings, bad data in, or related to an unusual setup.
Closing the bug is a way of saying: sorry this doesn’t look too important and we don’t have time to look at this given the other more important things (bugs/features) we plan to work on.
If it’s closed as stale after 6-12 months (multiple humans will have seen it) OR triaged by a human and marked as won’t fix I think that’s reasonable.