Summary
Extend event discovery so that editors who frequently work on articles that are topically similar to those in an event's worklist - not just editors who edit worklist articles directly - are surfaced candidate events via a post-publication dialog. This uses the CirrusSearch MoreLike API to derive a set of topically related articles for each worklist, then matches incoming edits against that expanded set.
User Stories
As an event organizer, I want events to be surfaced to editors who regularly contribute to articles in the same topic area as my worklist, so that we can reach a wider pool of potential participants who are genuinely interested in the subject matter.
As an editor with a topical interest, I want to be made aware of events related to the articles I care about, even if I haven't edited a specific worklist article, so that I can discover and join events that are relevant to my editing focus.
As an editor, I want to be able to opt out of post-publication event promotions that are triggered by topical similarity, so that I remain in control of the notifications I receive.
As an event organizer, I want to understand which similarity-based recommendations are reaching editors and driving registrations, so that I can evaluate whether topic-based promotion is an effective discovery mechanism for my event.
Background
As part of the broader worklist feature (see parent epic), we can already detect when a registered or unregistered editor edits an article that appears directly in an event's worklist and act accordingly — suppressing the post-publication dialog for registered participants or showing an event invitation to unregistered editors.
However, topical proximity is a richer signal than exact article membership. An event on "Women in Science" might have 20 articles in its worklist, but an editor who regularly works on a related biography or institution article is just as likely to be a good candidate for that event. The CirrusSearch MoreLike API allows us to query for articles that are textually and topically similar to a given article, giving us a scalable way to expand the reach of event discovery without requiring organizers to manually curate an exhaustive list.
This epic covers:
- Integrating the CirrusSearch MoreLike API to compute a set of topically similar articles for each event worklist.
- Persisting and refreshing those similar-article sets efficiently.
- Extending the post-publication event promotion check to include similar articles (in addition to exact worklist matches).
- Ensuring promotion attribution is clear — users should understand why they are seeing an event recommendation.
- Respecting the existing opt-out preferences and per-event deduplication rules established in the base worklist epic.
This work is scoped to the event promotion/discovery path only. It does not change the suppression-of-post-publication-dialog behavior for registered participants (which is triggered only on direct worklist matches).
Reference
- CirrusSearch MoreLike documentation — the API used to retrieve topically similar articles
- microtask-generator.toolforge.org & fast-api.toolforge.org — existing tools that derive article quality and topic metadata from categories; useful reference for how topical grouping has been approached in the Wikimedia tooling ecosystem
- Worklist epic — defines the event promotion dialog UX, opt-out preference, and per-event deduplication rules that this epic builds on
Acceptance Criteria
Similar article computation
- When an event organizer adds the first article to a worklist, a background job is enqueued to query CirrusSearch MoreLike for each article in the worklist and store the resulting set of similar articles (title + wiki).
- The similar-article set is refreshed whenever the worklist changes (articles added or removed) and at a regular interval (e.g. daily) while the event is upcoming or ongoing.
- The number of similar articles returned per worklist article is configurable (e.g. top-N by MoreLike score, with a sensible default). The combined similar-article set across all worklist articles is deduplicated.
- Worklist articles themselves are excluded from the similar-article set.
Post-publication promotion via similar articles
- When an editor saves an edit, if the edited article is in the similar-article set for an active or upcoming event — and the editor is not a registered participant — the system checks event promotion eligibility using the same rules as for direct worklist matches (i.e., the editor has not already been shown this event, and has not opted out of all topic-based event promotions).
- If eligible, the editor is shown the existing post-publication event discovery dialog. The dialog text indicates that the recommendation is based on topical similarity to the event's articles (not a direct worklist match), so the user understands why the event is being suggested.
- A user is shown any given event at most once via this promotion path (same deduplication rule as the base epic).
- Direct worklist matches continue to take priority: if the edited article is in the worklist directly, the existing behavior from the base epic applies, and the MoreLike path is not evaluated separately.
Opt-out and preferences
- The existing "opt out of all post-publication event discovery dialogs" preference (defined in the base epic) also suppresses MoreLike-triggered promotions.
- No additional opt-out is required specifically for MoreLike promotions.
Observability
- Promotion events triggered via MoreLike similarity are instrumented distinctly from those triggered by direct worklist matches, so that the two paths can be analyzed separately in analytics.
- A basic metric is available: number of MoreLike-triggered promotions → event page visits → registrations.
Out of scope
- Exposing the similar-article set to organizers or participants in the UI (this could be a future enhancement).
- Using MoreLike to assist organizers in building worklists (separate feature).
- Any changes to the dialog suppression behavior for registered participants.
Dependencies
- CirrusSearch MoreLike API must be available on the target wiki(s).
Open Questions
- What is the right value for N (number of similar articles per worklist article)? We should run a spike to understand MoreLike result quality and volume before committing to a default.
- How do we handle wikis where CirrusSearch is not available? Graceful degradation (fall back to direct-match-only promotion) or skip these wikis entirely?
- Should the MoreLike query be scoped to the same wiki as the worklist article, or can cross-wiki similarity be explored?
- What is the acceptable staleness window for the similar-article set? Daily refresh seems reasonable, but this should be validated against expected event durations and edit frequencies.