it looks like the proposed taxonomy will be

• language agnostic (with language-specific labels)
• defined in a php class in the WikimediaMessages extension
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/1100553/6/includes/ArticleTopicFiltersRegistry.php

Should we use ORES (extension) or not?

Though it's technically feasible to implement without ORES using a deferred update that calls the Liftwing API to store the topics on the recentchanges table, this seems counter to how we're currently using machine learning filters on Recent Changes (through the ORES extension).

ORES is the extension which integrates data from an ORES(now Liftwing) services into the RecentChanges view.

Per documentation:

It is installed on several Wikimedia sites, but no longer deployed to new ones.

For wikis that do not want machine learning UI filters in Recent Changes this extension would not be installed. For wikis that do want the machine learning UI filters in Recent Changes it is installed already, and if not we have already identified a process for installing it in T382171: Install ORES extension on idwiki.

How to store this data on rc table? Do we want to?

In my opinion we don't want to store this on the recent changes table because the data modeling would be awkward (we'd have to store the topics in a JSON blob since many topics can belong to one article and therefore one recent change as well).
Since ORES extension is the current implementation for adding machine learning filters to Recent Changes I suggest keeping it there until we can replace it or refactor it.

The ORES extension does not currently have any integration with the article topic model API, however we could very easily add to the LiftwingService class (when the API is available; it looks like the current docs are still under construction).
We could then store the article topic classification in the oresc_class column or another column like oresc_class_text. (Scaling considerations make me lean toward oresc_class_text as oresc_class is a tinyint as mentioned here ).
We then don't even need to retrieve all topics from the WikimediaMessages extension as we'd have the topic in the ores_class_text column.
We could then build upon the query builder's join conditions like we are for the other filters.
This method uses the ChangesListSpecialPageStructuredFilters hook.

Moving to engineering review to get some feedback from other engineers.

The findings look good to me; thanks for your research!

@Scardenasmolinar looked at this today and approved the findings; we'll need to create a task to implement this feature in ORES. I'll leave it open until that is done.

In T381569#10505529, @jsn.sherman wrote:

@Scardenasmolinar looked at this today and approved the findings; we'll need to create a task to implement this feature in ORES. I'll leave it open until that is done.

Correction (the above was a quick note from an engineering meeting): we can use T245906: Expose ORES topics in recent changes filters, which is in the product backlog. I'm going to stall it out since this is waiting on other work.