@ifried for more clarity, it depends on your definition of "fast", we would need to gather this data before the page even loads so we'll be working on the scale of milliseconds and could feasibly be requesting a significant number of documents.

• Topics
  • This would be Topics in LiftWing

Oh, yes you're right. I'm actually not sure.

I believe the structure would be Wp/grc/Event:something? In which case it would behave as expected

I am understanding from the comments that our preferred solution is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CampaignEvents/+/1212825 but using the user preferences timezone rather than UTC? It's not entirely clear.

I have a *relatively* working prototype, so it is *possible* to do this
The performance is TERRIBLE
Liftwing does not accept batch queries, so you have to submit each page ID individually and aggregate the scores later
Sending these requests, even on a relatively barren watchlist, is SLOW
There's very little we can do to mitigate this even with heavy caching
There are tasks open to make liftwing better for scaling (T401778: Evaluate adding caching mechanism for article topic model to make data available at scale, T418493: Integrate Article Topic model with the new caching service) but neither of these are likely to help us in the short term.

Things to be aware of:

Working prototype:

Cache clear, same result on 2 different events with two different users.

In T419731#11738496, @Daimona wrote:

In T419731#11737895, @MHorsey-WMF wrote:

Testing is inconsistent for me, this doesn't seem to show up a lot of the time on my local build, am I missing something @Daimona / @cmelo

Is this always for the same event (with a goal enabled) or different events? Have you tried clearing caches?

Testing is inconsistent for me, this doesn't seem to show up a lot of the time on my local build, am I missing something @Daimona / @cmelo

Given that an event has a goal set AND the current user is logged-in

• A progress bar should be displayed in the Contributions tab for EventDetails
• And it should have the following text & formatting:
• Header: "Progress to goal" (in bold)
• Description: "This event has a goal of {X}." where {X} is the goal target with the metric label (e.g. "2,000 articles edited")
• Progress bar should display the current progress towards the goal
• Numeric text below the bar showing current/goal (e.g. "1000/2000")

Given that an event has a goal set,

• A progress bar should be displayed in the Contributions tab for EventDetails

And it should have the following text & formatting:

• Header: "Progress to goal" (in bold)
• Description: "This event has a goal of {X}." where {X} is the goal target with the metric label (e.g. "2,000 articles edited")
• Progress bar should display the current progress towards the goal
• Numeric text below the bar showing current/goal (e.g. "1000/2000")

updated AC based on meeting 16/03/2026

I have a working prototype which has raised a number of questions:

@Daimona as this patch failed to deploy, does it require more work?

@cmelo Both me and @Daimona have worked on this so Ideally, you should be the one to test it.

@Daimona Feel free to take over if you have nothing else to do!

• Given that an event participant has successfully associated their edit with an event,
• Then they should see a success message,
• And the message should have the following copy: "Your edit has been associated with {EventName}. To see your contribution, navigate to the Contributions view of the event."
• "Contributions view of the event" should link to Contributions tab for event
• "Contributions" should reference the message with actual label of the tab
• And the message should be dismissible.

Discussion with @Catrope and @DTorsani-WMF has been fruitful. We have a defined understanding of scope and actions moving forward.
Estimation for both JS and CSS-only implementation is surprisingly small, it's relatively easy to extend the existing component, T-shirt-size: 3
Upstreaming is already in the plan, but need information about release cycles.

To summarise:

Discussion from Slack with @Catrope and @DTorsani-WMF

Significant changes were made to the pager architecture, so this fix has been rolled into a different patch. All of that work that @Daimona did has been carried over and included in the patch.

Had a great discussion with @HCoplin-WMF about this, pagination is on the list for the new API roadmap but may hold us up for up to 6 months. We can decide if we want to proceed based on this.

This is blocked by T414144, once that is complete we can finish this

Hi DBA s. Tagging to request approval for this schema change, as per https://wikitech.wikimedia.org/wiki/Schema_changes. When approved and merged, I fill file a separate task to get it applied in prod.

@Daimona has questioned if the edit count should contain page creations. I assumed it shouldn’t because we’re counting page creations separately and double counting seems weird, but he is (fairly) pointing out that we DO include them in the summary. (please correct me if I've made an error there ) @Daimona .

how to get the Parsoid HTML in MW

Further comments from Subbu: on edits, when you have Parsoid HTML available, you can count the # of nodes with mw:Extension/ref typeof

I would maybe try reaching out to the Content-Transform-Team to inquire on the feasibility of collecting and exposing the metadata.

It strikes me as a bit odd that from within MediaWiki, with the wikitext parser and everything available via PHP API, we need to use an external tool to parse wikitext. Now, it is true that, last time I checked, the wikitext parser didn't seem to expose, or collect, any metadata with statistics for the number of parser tags used. But then this means that those external tools are approximating and not counting the exact number (given also T407026#11295332); in that case, maybe we still don't need an external tool and can just do the approximation ourselves?