Think about the opposite. Imagine we pickup a bug in a live application and update it citing "our QA standards". This magical word does not absolve us of the fact that we let a bug through to production. And it's implied that we'll do better next time to pick up this kind of bug.
Is that really something you are challenging? Which pieces of popular software you can think of are bug-free? And are you thinking of more than a handful?
And they themselves were responding to someone criticizing media for using "editorial standards" as an excuse when they "retract a release".
And I explained how we are the same and supposedly strive to not release bad content/software, we just don't get to magically absolve fault with an excuse that "it doesn't meet our QA standards" as an analogy to "editorial standards".
Anywho, the whole thing breaks down when we have to beat it with a stick. It's a discussion, assume a charitable interpretation.
They got an opinion piece with an extraordinary claim about something the writer saw in a slide presented at a trial. She wrote the entire article about it creating theories and then how it needs to be stopped. Not to mention, she had previously worked with a competitive search engine. The central piece of fact checking was seeing that slide, that would have been the second question after "Are you sure you saw something like that?". The entire article hinges on that one slide she saw and what she understood from it.
This is not a case of missing a boundary condition. This is missing the central premise. At any level, it would be inexcusable.
PS: In a sense, as the artifacts are becoming public, i think more such confusions would surface in the coming weeks where merely misunderstanding what is on the slide would lead to a lot of rumors. Probably best we have an initial case and some intuition that this can happen.
There's a wide spectrum of how fucked your software can be when you release it without it being a huge deal, like if I push a broken release for my hypothetical build system that jumbles the error messages a little that's probably fine, if I push a broken build of the google dot com landing page that's raising a few more sirens and I really shouldn't make a habit of it, if I deploy critically broken firmware to your pacemaker or your crewed rocket ship I should probably be exiled from the field. I imagine there's a similar spectrum for journalists and we can't really figure out where on the spectrum to the article from the OP should be with just analogies to a different field. Complaining about a trend of publications slipping towards the yolo'ier end of the spectrum doesn't seem on its face hypocritical.
Editorial standards should stop bad stories from being published. Saying "we retracted this story because it doesn't meet our editorial standards" begs the question "why are you publishing things that don't meet your editorial standards in the first place?"
It doesn't take responsibility for or explain the mistakes in the article. It doesn't state that the article had factual errors. It's a frustrating cop-out. I sincerely hope this is a temporary measure while Wired gets a more comprehensive retraction put together.
Publications can simultaneously be praised for “rolling back a bad build” while being criticised for letting that build roll out to prod in the first place.
This would be like the SWE equivalent of pushing to production without code review. It's not an excusable mistake like when a bug gets through.
I think you might just be disappointed in humanity, rather than any particular agency or person. Humans come together to get the right answer eventually; not multiple times a day, every day, without fail. Sometimes the software doesn't do what you want. Sometimes that article has a factual error. Eventually we figure it out. It's not the end of the world.