Hi Amir @Ladsgroup, I'm just seeing this. We're currently preparing our KRs for the coming months and exploring ways to improve the benefits of Wikidata edits for editors. Your suggestion aligns with what we would like to propose regarding finding the most viable ways to improve the editing experience by showing Wikidata notifications that are high-value to editors. So thanks for putting this on our radar.

In T429686#12119487, @Ifeatu_Nnaobi_WMDE wrote:

Hi Amir @Ladsgroup, I'm just seeing this. We're currently preparing our KRs for the coming months and exploring ways to improve the benefits of Wikidata edits for editors. Your suggestion aligns with what we would like to propose regarding finding the most viable ways to improve the editing experience by showing Wikidata notifications that are high-value to editors. So thanks for putting this on our radar.

Thanks for response! Let me know if I can help on anything. I'd suggest this can be a feature flag and for start, we can enable it on several specific Wikipedias like Egyptian Arabic, Norwegian, Tatar or Ukrainian where the noise to signal ratio is incredibly high which would both avoid mass roll out and the backlash but still give us a pretty decent performance improvement on those wikis.

Thank you! I've worked it into the proposal and will reach out once it's been approved.

One observation: The numbers might shake out a bit differently because I assume the number of autopatrolled edits is not evenly distributed between edits that actually end up on a client wiki and those that don't. I don't know how skewed the distribution is. (Still think this is worth pursuing though, just calling it out for completeness.)

Right, I did a sample of 1000 rows in enwiki (analytics-mysql enwiki -e "select rc_params from recentchanges where rc_source = 'wb' order by rand() limit 1000;" > injected_rows). Then extracted rev_ids and then checked them against rc table of wikidata:

ladsgroup@stat1009:~$ cat injected_rows3 | sort | uniq -c | sort -nr
    963 2
     18 0
     17 1

Still 96.5% of edits injected on enwiki are auto patrolled. I can try it for other wikis as well.

frwiki it's 95.4%:

958 2
 34 0
  8 1

Perfect. Thank you!

This task description should reflect the product impact of such a change: we would *only* be supporting the vandalism-patrolling workflow, it's not a clear issue of "signal vs. noise" if you consider that users might have other motivations in mind. I would suggest doing some user research on that question before committing to patrolling-only.

As an alternative we can remove recent change rows of Wikidata patrolled edits in client that is older than 24 hours.

In T429686#12134425, @Bugreporter wrote:

As an alternative we can remove recent change rows of Wikidata patrolled edits in client that is older than 24 hours.

That won't help in db queries as most rc queries scan based on most recent timestamps so we end up keeping stuff that make things slow but throwing away stuff that won't have a major impact on the perf anyway.

In T429686#12131536, @awight wrote:

This task description should reflect the product impact of such a change: we would *only* be supporting the vandalism-patrolling workflow, it's not a clear issue of "signal vs. noise" if you consider that users might have other motivations in mind. I would suggest doing some user research on that question before committing to patrolling-only.

I'd argue using rc or watchlist of client wikis for anything but detecting vandlism on wikidata is the wrong solution (that could be a valid problem but not the right solution). I agree some talks with communities would be nice.