Sorry that this conversation is going in circles. At first, I was talking about the culture of migrating to a new system when it supports ~75% of the features (by importance) of the old, rather than closer to 100%. I would find it reasonable for some team to judge that RSS support is not in the crucial 75% (and its lack would not constitute production breakage); clearly you disagree. That's fine.
As for the rest, I was just explaining the general idea of a production freeze. If you're going to stop trying to make changes by a certain date "to be safe"; then that's the freeze date. Equivalently: people keep trying (and sometimes rushing) to do things until the actual freeze date. The date is early enough (quite a bit earlier than Dec 24) so that there's still enough time and people left to fix things or roll back, if there are genuine emergencies. This replaces the risk of production breakage with the risk of embarrassment/questions from asking for approval for an emergency fix during the freeze period, so people will still only do things they're fairly confident will be safe. Anyway, none of this is relevant unless lack of RSS support is considered a production breakage, which is the very point of disagreement here.
Sorry about the "few weeks / months" comment; I was editing it out while you were posting your comment. But yes, when deciding whether something is a blocker, it's safer to assume that it can take indefinitely long (until it actually exists), even if you think (or have been promised) that it will be quick. It's the difference between taking the mean versus the 95th percentile of the distribution of time estimates.
The freeze "until after the new year" is just the end-of-year freeze to avoid production breakage when a lot of people are on vacation: it's an extension of the principle of not deploying on Friday evenings / weekends; lots of companies have such a freeze. Once you've decided a couple of months earlier to do a migration, doing it "before the freeze" is also a natural deadline to pick, for migrating to the new infrastructure, and for people working on the old infrastructure to complete the migration and move to other projects. I'm not on the team but these all seem like logical choices.
And yes, in the decision between "keep maintaining a custom infrastructure" and "switch to a common infrastructure", someone must have decided that RSS support is not an essential feature whose lack should block (or indefinitely postpone) the migration; this seems reasonable and what my previous post was about, including the "probably just not a big factor" bit you quoted above. It looks like they're planning to add this support though.
• The people working on web.dev decided to migrate to a common Google site platform, so that they could focus on content rather than maintaining an ad-hoc infrastructure,
• That platform happens not to support RSS (yet), so they've done the best they can in the meantime, filing a bug with the platform, creating the https://developer.chrome.com/feeds info page acknowledging the issue, and even creating unofficial feeds.
You could phrase this as “someone in Google management who decided that RSS could be broken”, but relative to the big decision of whether to spend effort maintaining your own custom infrastructure or just focus on the content, the presence or absence of RSS support is probably just not a big factor.
[One could imagine a culture of "never migrate to a new system unless it fully supports every single functionality of the old system", but that (just like "never launch a product/feature unless you're confident you're going to support it forever") is simply not in Google's culture, where there are always ongoing migrations between "the old system that is deprecated and the new system that is not ready yet" — but that is "just" a cultural problem rather than anyone consciously deciding that RSS could be broken.]
Well it's all gradual and diffuse; for that matter there are still pockets of the "old Google" around today. My point here was just about, in a big company, different teams having their own domains that you don't/can't interfere in, rather than a free-for-all where everyone feels part of the same whole and can just jump in. (Which was probably never going to work anyway, so maybe encouraging such a culture in the first place is what Google did wrong.)
This is actually ironic in light of popular HN sentiment in Google-related articles, where many seem to imagine Google acting as a single whole, rather than different teams working in their own interests and not thinking of the big picture. E.g. people in this thread imagining that "Google" thought about RSS support and made a decision based on advertising revenue (or whatever imaginative reason), when in fact the team working on the "DevSite" infrastructure probably barely thought about RSS at all. Maybe they should have, but the reality that RSS (unfortunately) doesn't matter much seems harder to swallow for many, than theories about maliciously breaking it.
This is hilarious big-company shit, that engineer on Chrome devrel team finds it easier to actually just write his own unofficial RSS feed-generator and make it public [1] — the feed for this blog is at [2] — than for the "Internal issues have been filed with the DevSite team" to get worked on [3]. And who knows when this will rise to a priority for that team?
In the old Google, it would have been easier for anyone to just fix this internally.
(Disclaimer: work at Google but not on anything related to this; all my information comes from links in this HN thread. Which is ironic / symptom of the same problem.)
That's the same as the link I was responding to, and that's why I wrote “relative to” — the Ads team pushing on Chrome for revenue shows Google in a poor light relative to an imagined world where Chrome never cares about Google revenue, but a good light relative to an imagined world where everything that Chrome does is for revenue or some short-term profit to Google, rather than what's good for users.
Well, it's a line I've heard a few times over the years, and it's also being stated externally (https://twitter.com/searchliaison/status/1709726778170786297 says “The organic (IE: non-sponsored) results you see in Search are not affected by our ads systems.”) so I'm fairly sure it's still true.
That email thread you linked is between the Ads and Chrome (not Search) teams, is about the number of search queries (not the results of search queries), and “ranking tweaks” there refers to the ranking that Chrome uses to show the suggestions in the omnibox (address bar). (To get a sense of these “ranking tweaks”, try this experiment in a (new?) Chrome profile with default settings: type "flowers" in the Chrome address bar and don't hit Enter, and look at the suggestions: what mix of search suggestions, entities, and bookmarks/history do you see? Try again with other commercial queries like “insurance” and “mortgage”, and also some less commercial queries like, I don't know, “Minnesota” or “economics”.)
(And FWIW, I think that whole email thread actually shows Google in a “good” light relative to the popular impression here on HN as a company whose every action is some Machiavellian scheme to increase ads revenue: it shows that Chrome actually launched something to production before its negative impact on revenue became a concern, that Ads leads had to work hard to persuade them to either roll back or find some other way to undo the decrease in search query volume, that starting to include search query volume as a launch criterion would be a “cultural shift” for Chrome, etc: that Ads having an influence on Chrome is a rare occurrence.)
More precisely, the slide shows, for an advertiser who is bidding on the keywords “+kids +clothing” and has this sort of broad match enabled, three columns of examples of searches that would also match:
1. (because of [kids → children]) ads with keywords “+kids +clothing” would also match searches like “clothing for young child” and “newborn children's clothing”
2. (because of [kids clothing → kidswear]) ads with keywords “+kids +clothing” would also match searches like ”nikolai kidswear” and “kidswear outlet”
3. (because of [clothing → apparel / outlet]) ads with keywords “+kids +clothing” would also match searches like “creative apparel for kids” and “kids outfits”
That is what the slide's title (“Advertisers benefit via closing recall gaps”) refers to: the gaps in recall (matching) are being closed, by being broader.
The WIRED article misunderstood the slide, and was entirely based on the premise that if you searched for “children’s clothing” you'd get results for “NIKOLAI-brand kidswear” which is not true (and would indeed have been “startling”, not to mention obvious, if it were true). In fact, the organic (non-ads) part of the search results in Google are always completely independent of anything in ads, something that the Search team in Google have maintained for several decades as a fundamental principle.
Another side of “for nerds” is that early Google managed to attract employees from academia. I remember the buzz in the academic world when a professor (Matt Welsh) gave up tenure at Harvard to join Google: some others followed. Even more, it attracted top students who otherwise had their heart set on academia: within the (delusional) world of students who consider being a professor as the highest ideal, I remember hearing the opinion that if you can't get a tenure-track job, Google is a pretty good second choice because it's “just like a university”: you had (so the story went) freedom to do whatever you wanted, smart peers, “talks at Google” from the best speakers, … and there were perks (free food, laundry, etc) that appealed to students.
I myself ended up joining Google when my academic path was interrupted, despite thinking I'd never do that. Google employees were already complaining in the early 2010s about the changing culture, but there was still enough of it left, and by all accounts, early Google was a magical place.
As for the rest, I was just explaining the general idea of a production freeze. If you're going to stop trying to make changes by a certain date "to be safe"; then that's the freeze date. Equivalently: people keep trying (and sometimes rushing) to do things until the actual freeze date. The date is early enough (quite a bit earlier than Dec 24) so that there's still enough time and people left to fix things or roll back, if there are genuine emergencies. This replaces the risk of production breakage with the risk of embarrassment/questions from asking for approval for an emergency fix during the freeze period, so people will still only do things they're fairly confident will be safe. Anyway, none of this is relevant unless lack of RSS support is considered a production breakage, which is the very point of disagreement here.
Sorry about the "few weeks / months" comment; I was editing it out while you were posting your comment. But yes, when deciding whether something is a blocker, it's safer to assume that it can take indefinitely long (until it actually exists), even if you think (or have been promised) that it will be quick. It's the difference between taking the mean versus the 95th percentile of the distribution of time estimates.