@Samwalton9-WMF

We talked in engineering about adding an attribute to log the source of the edit (eg. rc, watchlist, etc); this wouldn't show up in the superset dashboard, but could be queried after the fact with some effort.

Being able to know which categories of edits users are clicking on definitely sounds helpful to help us analyse which signals are impactful. Could you elaborate on what you mean by "log" here?

Change #1260180 had a related patch set uploaded (by Scardenasmolinar; author: Scardenasmolinar):

[mediawiki/extensions/PersonalDashboard@master] Add watchlist as source of risky articles feed

https://gerrit.wikimedia.org/r/1260180

I have a couple of questions that I thought about while solving this:

Should we add a visual cue to differentiate between the two types of feeds? I have added a data-feedorigin attribute to help with instrumentation, but there is nothing to distinguish them.
What if there are two edits on the same page, and one shows up in the recent changes feed and the other in the watchlist, and both are surfaced in the dashboard? Would this be a problem? I have had this happen in my local testing.

In T419838#11747285, @Scardenasmolinar wrote:

I have a couple of questions that I thought about while solving this:

Should we add a visual cue to differentiate between the two types of feeds? I have added a data-feedorigin attribute to help with instrumentation, but there is nothing to distinguish them.

This is something we're still clarifying on the design side, but at minimum I think we want to do T420917: Tag edits being shown to users because they have high Revert Risk score. The unresolved question at the moment is whether we want to label every source, i.e. whether we would write "From your Watchlist", denote that a page is watched, or not/something else. This is TBD, so for now it's OK to leave the edits unlabelled.

What if there are two edits on the same page, and one shows up in the recent changes feed and the other in the watchlist, and both are surfaced in the dashboard? Would this be a problem? I have had this happen in my local testing.

Per the acceptance criteria we should definitely be deduplicating, so that we only show a given edit once. Beyond that, we'll figure out in the design explorations I mentioned - e.g. we probably still want to denote a high revert risk score that was found via the watchlist, and if a page is watched we might want to denote that even if it came from the RC source. But all still being figured out.

We only show a given edit once

The case I'm seeing isn't a single edit but two different edits to the same article.

Ah! We should only show latest revisions, so there shouldn't ever be more than one edit for a single page.

Ahh this is a good point, we decided not to show only latest revisions for the MVP, because we were worried about not having enough edits to display. If we're adding additional sources of edits then that might be less of a concern.

I see. I reckon we should make sure we only show one edit per page in that case then - if we're showing a risky edit of a page to the user, we shouldn't also show another change from that page.

A thought that might muddy the waters here; so far we've been talking about recent changes in terms of single edits, but maybe this is a case where we want to highlight a range of edits together? I'm thinking about rc/watchlist grouping and multi-rev diffs, etc. feels like a potential future thing.

In T419838#11753073, @jsn.sherman wrote:

A thought that might muddy the waters here; so far we've been talking about recent changes in terms of single edits, but maybe this is a case where we want to highlight a range of edits together? I'm thinking about rc/watchlist grouping and multi-rev diffs, etc. feels like a potential future thing.

I can envision something like this in the more distant future where we might have different kinds of cards within the feed, perhaps moreso when we start to combine it with the newcomer homepage. eg: A catch-up card... "There have been 3 changes to a page you watch. Here they are!"

For the meantime, I think it's best to focus on making the the single-change experience great.

Change #1260180 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Add watchlist as source of risky articles feed

https://gerrit.wikimedia.org/r/1260180

Noting that the relevant URL parameter is ?personaldashboard_riskyarticleedits_wlenabled=true.

When testing I found a bug - we're filtering for high revert risk on the Watchlist too, but we want any watched-page edits, not just high revert risk ones: T422802: Remove revert risk filter from Watchlist API query in PersonalDashboard Review Changes.

{F76362331}

Because Recent Changes is selecting from things which just happened, and Watchlist is going back further, on fewer pages, my Review Changes feed does always have three RC edits, then two Watchlist edits, which is the kind of slightly-odd chunking behaviour we want to avoid in the long run. I think we'll just address this as part of our broader efforts to combine sources and prioritise, though, so I'm happy deploying this as-is.

I tested with zero, one, and many pages on my watchlist and it behaved as expected with all.