> It's not about putting the blame on specific individual or teams for their insufficient communication or testing.
We don't need to put the blame on anyone, but to your point on learning from bugs and making sure they don't happen in the future, how can that happen if we're fatalistic about why those bugs were caused?
I don't know what the Chrome team is doing differently now to prevent another situation like web audio from happening, because there was never any followup about process changes. The only thing that we were ever told during the web audio failure was that we needed to trust the Chrome team, and that they cared. But that never turned into anything tangible or visible. And X years later and X broken feature launches later, we're still having the same conversation.
If avoiding blame means we can't talk about why something went wrong, then that's a broken process. You're telling me that reaching out to developers is futile, and unless we pay a ton of attention to the mailing lists we're going to miss stuff, and that testing is the only thing that can save us. That's a regression from what I heard from Chrome devs during the web audio debacle. The team seems to have gotten more insular, not less.
We don't need to assign blame, but it would be good to actually learn from these situations. Nothing is changing, the dysfunctional communication between the Chrome dev team and developers is still just as bad today as it has ever been. Is the Chrome team going to do anything at all to help make the situation better?