I very recently had to push back on a bug that wasn’t a bug in my part of the stack. If they wanted it “fixed” in my part, it would be a feature. (Enum values from an API being localized — these were hardcoded on the backend). IMHO, these should be localized in the client, which has the current locale (I do not have the current locale and no strings are translated from this API by this API).
That was pretty fun, but I don’t think generalizing “denying a bug” as saying we are being “lazy” is a correct assumption.
I had a similar experience adding new functionality to a web application. It was a simple enough feature that I was able to supply the English myself, but I knew enough not to provide the international copy, even though the only other language we supported was a language I studied in school. I asked the product manager a few times, then created a ticket assigned to them and sent them the link. Meanwhile, my code got reviewed and deployed, behind a feature flag of course.
As soon as they found out the code was deployed, the product manager asked if we could turn on the feature. I reminded them that the reason we supported the other language was that it was a legal requirement for our customers in a certain country. They said turn in on, nobody was going to notice except a big US customer who desperately needed it. So I did.
Within a few hours we had an enraged customer on the phone. Credit to the product manager, they took full responsibility, but the initial response from the founder/head of customer success who took the call was to walk straight to my desk and ask me what the hell I did.
I agree, "denying a bug" does not equal "lazy", but rather "denying a bug one has created" does at best equal "lazy", at worst malicious (e.g. rep protection).
That was pretty fun, but I don’t think generalizing “denying a bug” as saying we are being “lazy” is a correct assumption.