|
|
|
|
|
|
by Orphis
1775 days ago
|
|
|
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. |
|
|
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.