how does this affect the table interface? should we carry over the changes seen here?

@JFernandez-WMF can you please share the design of the table with the header and the toggle?

@JFernandez-WMF can you add a screenshot of the design including the link to the worklist wiki page? I updated the current design shared on this card to remove the filter button but wasn't able to add the button to the wiki page

Resolving this. We've decided not to pursue the morelike topic-matching approach, so the expanded trigger-volume estimate this request was scoped around is no longer needed. If topic-matching comes back on the table I'll reopen this or file a fresh request with updated scope.

Seen in Design Review: This feature can't be implemented as described; it will need deeper refinement or be dropped

This card will be moved to a V3 of the worklist

Changed the Epic to: "Promotion based on articles related to the event's worklist" to avoid confusion

Discussed with @JFernandez-WMF today: We need to decide whether to show only who is currently working on an article (from an active session) or also allow participants to claim an article they plan to work on later.

@KStoller-WMF were you able to identify other cases in your team outside these?

@JFernandez-WMF My lean is to build on the recent edit activity we already capture rather than try to detect live "editing right now" presence, which would be a much heavier lift. Does that tradeoff feel right from the design side?

Good questions @JFernandez-WMF , and I think they point us toward a simpler design. What if we reframe this from "claiming" an article to "showing that an article is being edited"? Instead of a manual claim and release action, we surface a signal we mostly already have: recent edit activity on the article.

@MHorsey looked at how to match a just-edited article against the articles on an event's worklist, so we can show an event invitation on topical similarity rather than exact worklist membership only.

Thanks @MNeisler, that clears it up. Good point that both tiers are functionally in the noise either way, less than one edit a week across the whole worklist. The organizer attention theory for small worklists is interesting too, worth keeping in mind when we talk to organizers about worklist size.

Thanks @MNeisler, this is really helpful. Let me say back what I'm taking away so I know I've got it right:

Very good point @AAlhazwani-WM. The rationale for referring to the event section is that, if a user on desktop accidentally scrolls after opening the preference link and loses the Event section visually. But since it's a common experience, we can stick with the original opt-out message

In T427207#12068528, @Mayakp.wiki wrote:

hey @OBenhmida , could you confirm if by 5% you mean the Reporting Target % Increase, and what would that be in terms of the Target engagement count ?

Target revised to 5%

Solid suggestions @Daimona , adding my suggestions to a few of them: