[gpm]

> proper announcements in ALL the relevant mailing lists and release notes.

I can't emphasize enough that mailing lists are worthless for this. Your average web developer reads no mailing lists, I'd be surprised if even 5% did, and those 5% are going to be clustered. Release notes (that anyone reads) come too late, since people only read them once users are already installing the broken browser.

Announcements that you actually expect to be read need to be in a much higher profile place, it looks like this is an appropriate blog: https://www.blog.google/products/chrome/ - even then it should be written with the goal of it being picked up by places like reddit/HN/twitter/news. Even then you should expect that most web developers won't find out, and most who do find out won't change anything in regards to your announcement that your new version of the browser is going to break compatibility with their perfectly functional website, incentives just won't align for many of them to fix it pre-emptively.

That last part is why I advocate for indicating the issue in a user visible but non-breaking way first, that's going to be the only way to get funding/time to update to your new version for many websites.

[danShumway]

I'll add onto this, putting an announcement out needs to be followed up by checking to see if the announcement has gained any traction.

Announcing breaking changes is not a checklist that can be filled out and then ignored. Put out an announcement, see if any other sites or prominent developers pick up on it, if they haven't picked up on it then the job isn't done and the change needs to be advertised more.

Maybe for some things posting it to the blog might be enough, and the major stakeholders that need to know will pick it up. Then you can move on to the next steps. But if they don't see it, and you don't see any reaction to the blog posts, then don't just move onto stage 2 because "they had their chance, if it breaks now it's their fault." :)

Have some standards of what level of conversation and preparation you expect to see from web developers before you consider the community adequately informed.

[TeMPOraL]

Another idea that could reach a significant fraction of web developers: have the crawler check for potential use of deprecated features and alert the website owners through Google Search Console e-mail flow (using a separate message from regular GSC updates). The people who read GCP reports are likely to get worried and forward it to devs responsible for the site.

Another variant of this: surface such warnings on Google Analytics page/report. The easiest way to get software developers to do something is to convince sales&marketing that conversions will drop if they don't do it.

[Orphis]

Here's an example of a major bank website with some user visible non-breaking issue I saw recently: https://youtu.be/GFvaRgFf4LU?t=482 . It seems that it's been visible for a while, yet is not fixed. It's actually quite common to see errors unfixed in software as you may know.

No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed. Some will never be fixed until they actually stops working. Some will just never be updated at all.

Maybe you're one of the people who take their car to the repair shop when the engine light is on, but there are also many others who will just ignore it as the car still drives "fine" (for now at least).

Regarding your suggestion of using Reddit, HN, Twitter, news, it's not always possible or relevant. I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.

Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself. All sides can maybe do better at broadcasting information about some changes, or voice their opinion better and sooner, but it's not an easy problem with an easy solution.

[danShumway]

> No matter what you do, some websites will only be fixed a long time after very obvious warnings are displayed.

Okay, let's try another angle. Does the Chrome team have any stats at all about how many developers were informed about this change and were able to adapt to it before it went live?

You're right, some people are going to slip through the cracks, that's inevitable. How many people? How does the Chrome team determine if they're doing a good enough job with communication, what metrics for developer uptake are even being measured here? Is the Chrome team watching any public spaces like Twitter or Reddit to see whether or not changes are actually being seen and disseminated in developer communities?

You're phrasing this as if it's just a subset of developers who didn't realize what was going on. I would surprised if that's the case, I suspect the vast majority of developers did not realize what was going on.

> I've seen a lot of very interesting publications just not getting any traction on those are they're boring in nature or cater to experts mainly. They're also read only by a fraction of users.

Also can't stress this enough, still more users than read the mailing lists. They will still get more traction than Chrome's existing announcements. You don't have to stop posting to the mailing lists, just put a little bit of effort into going into communities where developers actually spend time.

We know that developers don't read the mailing lists. So let's try to find out what they do read.

> Unfortunately, if you're hit by any issue, you shouldn't be only asking what others should do for you, but also what you can do to catch those issues in the future yourself.

Definitely, but this is a really tone-deaf response to people telling the Chrome team that they have a problem with communication.

This is also one of my evergreen complaints about how breaking changes work in Chrome -- it always ends up being phrased as either the developers fault or an unsolveable problem. The best we can get is "all sides can maybe do better at broadcasting information". Yes, we have to treat Chrome like it might break our stuff randomly. We have to constantly be engaged in the web standards process, even when it's exhausting, even when it means we're drinking a firehose of information. Yes, we need to set up automated testing for all of our projects, we can't put sites up online and expect them to keep working.

We do our best to mitigate the problems that the Chrome team is causing by refusing to proactively reach out, by refusing to do anything beyond just posting their changes and giving people time to read them. And we don't get any indication that the process is ever going to improve.

Please meet us halfway.

Or at least the Chrome team could take your own advice and ask itself what it can do to make messaging more effective, rather than "only asking what developers should do for them" to make breaking changes go more smoothly.

[fomine3]

Announcement of SameSite=Lax by default was good. They were posted on web.dev.

[danShumway]

There's always room for improvement on all of this stuff, but I'm generally in agreement, I thought the SameSite=Lax rollout went a lot more smoothly, and I saw people outside of Chrome mailing lists talking about it and sounding alarms that sites might break.

I try to pay attention to upcoming potentially breaking changes, but I didn't know about the iframe changes (luckily they didn't affect any of my projects). I did hear about the SameSite changes from multiple sources, it felt like there was a real effort there to try and break the news into the mainstream.

I also think a big part of what made SameSite=Lax better was that it wasn't just Chrome notifying people about the changes, it was other developers in the community helping to spread the word. I saw multiple blog posts and Twitter threads warning about it.

I don't think the model of "Chrome announces something then wipes its hands and steps away" works in the real world. Developers need to be included in efforts to spread awareness, because there are communities that the Chrome team doesn't have access to, and not everyone pays attention to what the Chrome team posts. It's better if multiple stakeholders both inside and outside of Chrome are invested in getting the word out.

It sounds to me like a big part of the complaint about the removal is that there isn't currently a good replacement for `alert` in intro tutorials, or a clear process for sites that depend on `alert` to quickly move to something else. I don't expect the Chrome team to understand that in advance, the web is enormous and they are going to miss use-cases, no single team can predict the full impact of every browser change. But early awareness of changes and early interaction with communities outside of the main mailing lists will make it more likely that developers and communities raise these issues so they can be addressed before there's a PR fallout.