Ticket classification isn't necessarily so simple, and I can think of various reasons for using ML to classify tickets.

1. Some auto-generated ticket (e.g. a trigger from unusual hardware activity or a log entry) resembles a previous ticket that had meaningful action on it, addressed and solved by a specific team. That ticket could spend a week getting ignored or punted around when the right team can solve it in 5 minutes. ML could detect the similarity and reclassify it by that metric. 2. Human-submitted tickets are annoyingly fallible. For example, an "I can't log into my account" ticket could be auto-classified as "account recovery". Or maybe, e.g. the ticket system attaches a recent activity log from that IP address to be cross-checked by ML, which finds 5xx errors and reclassifies it for the technical team.

These are generic examples, but you can use your imagination and see how a company as huge as Amazon could benefit from this. I think it's for the purpose of minimizing the number of tickets that need to be manually reclassified because the wrong info was given to the wrong person.

In my past experience in IT, the ticketing system basically doubled as an aggregated event log, and it was a legitimately good use case. The monitoring software we ran on our thousands of client workstations and servers was extremely powerful and could capture any conceivable metric to use as a trigger for auto-generating a ticket.

So, a lot of tickets generated would simply just be data reports with some info dumped in the ticket description, designed to be auto-closed but possibly useful later as an easily-accessible timestamped reference to some data.

Lots of other auto-generated tickets were "probably not an issue but it should pass over the eyes of someone knowledgable about this server/network" tickets. Like Windows Event Log error roundups, CPU usage spikes, or specific triggers that were set up in the aftermath of some catastrophe to help preemptively avoid a repeat incident.

Anyway, tickets are a great "first line of filtration" where you can take a massive ingest of all different kinds of data (hardware metrics, system logs, network activity), apply meaningful human context ("This pattern could be a sign of xyz"), and store it in a unified database. With that use case, it's easy to imagine a company with millions of customers and millions of servers producing millions of tickets.

I've never seen a ticket system used as just a dumping ground for data in auto-closed tickets. Seems like there would be better solutions for that, particulary for data you want to find later (in my experience, the search capability of ticket systems varies from poor to "don't bother, you won't find what you're looking for")

Anything else, that needs a human to interpret or take action on, yes, ticket systems get extremely wide usage.

Right, I didn't mean using tickets as a generic event log—the assumption is that someone would have set up triggers because they actually have a reason to have the data on hand, and it's a low-friction way of getting what they need without worrying about implementing new tools or systems. In a good human system, the trigger would be disabled once that info is no longer useful. (And in a bad human system it would just stick around until nobody knows what it's for anymore, haha.)

We also had tickets that would trigger scripts upon generation, e.g. an auto-generated "low disk space" ticket would then trigger a basic "disk cleanup" script, and close itself if enough space was freed to clear the threshold. Yes, it's comical that the ticket would do that—but hell, it worked great. It ran agnostically across thousands of differently-configured machines. And whether or not it was a human who clicked the "disk cleanup" button shouldn't determine the usefulness of having that event logged in the ticket database.

Point is, the whole system was a veritable Swiss Army knife that didn't necessarily have to equate a "ticket" (database entry) to "requires human intervention", provided there was a good human system in place to leverage the tool in a way that was productive for them.

That makes sense, but a part of me is wary of introducing noise at such a scale and drowning out whatever signal remains.

Also ticketing systems in my (very) limited experience tend to be bloated pieces of software, so that adds a fun dimension to it.

Indeed, I learned pretty quickly that maintaining the line between "underreported information" and "information overload" is an indefinite challenge that evolves over time as context changes.

But the human team is what understands the big-picture context and the way it changes over time, so it makes sense for them to manage the triggers for the "this may be important" tickets—for them to then ingest and discern whether it's important. Ultimately, ticketing software is just a tool designed to distribute context-stamped information to humans who then discern what to do with it.

So I think just like all other productivity software, it's only as good as the human system in place that drives its usage. That explains the bloat as well—it's not its own system, it's a big old suite of tools that are each available to be implemented into a human system if desired, or ignored if not.

Assuming you're thinking of FaceTime, I remember there being a patent lawsuit shortly after launch that apparently lasted a couple years: https://www.bbc.com/news/technology-20236114

By that time, not only was Android looking much more competitive, but FaceTime evidently demonstrated to be a massive hit that became very powerful for Apple's branding.

I also read that FaceTime eventually went from P2P to centralized servers (maybe in response to the lawsuit?), which of course is antithetical to the premise of being open.

Lastly, just speculating, but I imagine Steve Jobs had to have been a strong advocate for making it an open standard, if not the driving force. It makes sense that the promise would have fizzled out by the time the lawsuit was over, a year after his death.

I was a teenager at the time and would watch all of Apple's keynotes. I remember them making a big deal for a while about H.264 support. It's very cool to get a glimpse of the context where engineers like yourself were likely proud of your work, and I'm glad that it was shown through the way that Apple talked about it.

I had always thought that table sorting seems like the perfect job for HTML, given its data-driven nature, and the possibility of implementing sort information into the attributes of table cell elements.

But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.

Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.

CSS now also has `reading-flow` to instruct the browser to change the reading order to match the visual order created by Flex or Grid. Unfortunately, not all browsers support it and it has some limitations.

XSL has sorting, so kind of, depending on which document you're referring to when you say DOM.