The map tile backend is in the middle of a multi year effort to migrate from the Flippity Service to the Floopity Service. The FlippityFlooper was believed to have finished the necessary format conversions for all map tiles in the US and Canada but 5% of the data sources were missed due to a bug that was discovered after the creator of FlippityFlooper had been promoted and changed teams, so those Floopity tiles are filled in from an older source. A junior engineer vibe-coded a stopgap fallback called FloopityFlipper that redirects to legacy Flippity Service when Floopity staleness is detected, but that redirect broke three months later due to a change in an injected dependency's experiment configuration. A bug was auto-filed and marked P2 by an overworked product manager who slightly misunderstood the scope, but the FloopityFlipper engineer will probably have a look once they are back from paternity leave.
I made all of that up but it's more plausible than conspiracy theories.
I mean, it's also an attentional commitment for me to remember your idiosyncratic apology-preferences. So I might continue apologizing for replying late to your email, unless you convince me that _everyone_ doesn't like this...
My main home PC is a Puget Serenity workstation from 2017. It has been rock solid and outperforms much newer laptops. And it has almost zero fan noise which is a priority for me. Unfortunately it looks like they may have discontinued the Serenity model, at least I don't see it on the website anymore.
This illustrates the difficulty of maintaining a separation between bugs and discussions:
> To be clear, I 100% believe that there is some kind of leak affecting some specific configuration of users
In this case it seems you believe a bug exists, but it isn't sufficiently well-understood and actionable to graduate to the bug tracker.
But the threshold of well-understood and actionable is fuzzy and subjective. Most bugs, in my experience, start with some amount of investigative work, and are actionable in the sense that some concrete steps would further the investigation, but full understanding is not achieved until very late in the game, around the time I am prototyping a fix.
Similarly the line between bug and feature request is often unclear. If the product breaks in specific configuration X, is it a bug, or a request to add support for configuration X?
I find it easier to have a single place for issue discussion at all stages of understanding or actionability, so that we don't have to worry about distinctions like this that feel a bit arbitrary.
This is not a standalone article but a section from Butterick's book, "Typography for Lawyers", which is hosted in full on the website. The book is an opinionated style manual, and many alternatives are described in nearby sections.
Once I realized that some people expect and are happy for you to jump in with unprompted thoughts or stories, it became easier for me to be intentional about doing so.
I think I'm a lot better now than when I was younger at adapting to a wide range of conversational styles, mostly just from paying more attention to that dynamic.
Do you feel like your conversational toolbox has evolved over time? :)
But it is quite interesting and especially learning about the security problems of the document() function (described @ 19:40-25:38) made me feel more convinced that removing XSLT is a good decision.