@amastilovic I'm going to mark this as declined, since last quarter we discovered that we can't automate the moderators models until there's an update to our dbt-airflow configuration that accommodates for models that have monthly and daily/hourly data sources they need to pull from. You created this ticket regarding the fix that's needed: https://phabricator.wikimedia.org/T430579.

Update from Fri, Jul 31

Update from Fri, Jul 17

@Milimetric @Snwachukwu The models for which I've requested backfilling are upstream from your heartbeat_active_uwer_mart model, so you'll need to backfill your model afterwards. Do you want me to add that to this ticket? Or will you handle the backfilling for that model?

🎉 WE 1.5.7 Close-out report: https://app.asana.com/1/3758245663860/project/1214268089527795/status/1216466281744285

Update from Fri, Jul 10

I'm making the following revisions to the task description:

Update from Thurs, July 2

@JMonton-WMF Per the updated metadata noted in the tables above,

I just checked, and the row counts for May 16 and May 17 match now. 🎉

@AKhatun_WMF thank you for all the information!

[updated Jul 2, 2026]

The following model backfill needs to be rerun without sync_all_columns

Update from Fri, June 25

@nshahquinn-wmf It looks like the 0.004% increase in total edits and content edits is due to duplication of a single user. See my comment in the MR for details.

Update from Fri, June 19

@Ahoelzl Thanks for following up. For the MAM metrics work, we were able to go with Option C: joining the change tag table with the logging table, and then seeing which of the relevant moderator actions have mobile tags and which ones don't. Option B (adding access_method to existing event streams) would likely be very useful for future analytics work, but it is no longer a dependency for WE1.5 hypotheses.

Update from Fri, June 12

Update from Fri, June 5

@CMyrick-WMF, for Phase 1 MWH incremental, would it be okay to not include user block events in MWH Incremental?

Could you get the data you need for your metrics from the event.mediawiki_user_blocks change Hive table? This is an old legacy stream we want to decommission one day, so while it has performer, but it does not have user_central_id. If you need user_central_id you can join with MWH or MediaWiki centralauth tables?

Update from Fri, May 29

@JAllemandou I think the bug may be exclusive to the '2026-02' snapshot.

Update from Fri, May 22

Update from Fri, May 15

Update from Fri, May 8

We currently have revision_tags for revision actions (i.e. where event_entity = 'revision'). Would it be possible and not-very-difficult to get change tags for for non-revision actions? Currently I have to join the logging table with the change tags table to get this information. --But if that's out of the scope of this project, I understand.

is a Wikidata ID field (for the corresponding page ID)

Update from Fri, May 1

In T424918#11874018, @AKhatun_WMF wrote:

@CMyrick-WMF: You should (if you haven't already) deduplicate on wiki_id, rev_id. As we've already noticed, other events (deletes/moves) can contain the same old rev_id, hence a produce duplicate of the edit-types. Plus, sometimes the same event is duplicated too, due to reprocessing for instance.

This analysis should also give you some idea of why the data isn't the same.

Updates from Fri, Apr 24

Update from Fri, Apr 10

Update from Fri, Apr 3

Update from Fri, Mar 27

In T419434#11732458, @Samwalton9-WMF wrote:

In T419434#11725009, @jsn.sherman wrote:

Specific Request: We would like a general audit of the code to see in what circumstances those log actions get a mobile tag applied and whether there are obvious bugs.

That is a very large request; different wikis use different extensions with different configuration, leading to different outcomes. There are also a large number of user scripts and external tools in use that can basically do whatever they want.

Could we perhaps take a broad approach here and simply look at the common paths (i.e. native MediaWiki interfaces, bundled extensions, API)?

I also wonder if this needs to be a code audit, versus some QA/testing? Like, sit down and take each of these actions on a desktop device, on a mobile device, and perhaps edge cases like desktop-mode-on-a-mobile-device or minerva-skin-on-desktop, and then record the log outcome? We could then perhaps just code-dive if anything doesn't behave as expected?

Update from Fri, Mar 20

Update from Fri, Mar 13

Update from Fri, Mar 6

Update from Fri, Feb 27

Weekly update:

In T419459#11694199, @Dreamy_Jazz wrote:

In T419459#11694193, @CMyrick-WMF wrote:

Does this mean (1) we do not store whether the user running the check did so via mobile or desktop, and/or (2) these checks do not receive a "mobile" or "mobile edit" change tag when performed on mobile?

Yes, both of these are the case.

Essentially we have no data on whether the user running the check was using a mobile device or desktop device. The only way to get this data that I can think of is the web request logs or for a small subset of the recent rows in cu_log the /analytics/legacy/specialinvestigate/1.1.0 eventlogging schema may have this data(?)

For any large scale collection of this data, we would need to migrate cu_log to the logging table which is a very large technical effort

In T419459#11694212, @Dreamy_Jazz wrote:

If a general overview of desktop vs mobile is useful, a vast majority of the rows in cu_log will have been made by users either using a desktop device, as the tools are not well optimised for mobile devices. Of those using mobile, most will be using the desktop view

In T419459#11691177, @Aklapper wrote:

Can you please associate one or more active project tags with this task (via the Add Action... → Change Project Tags dropdown)? That will allow to see a task when looking at project workboards or searching for tasks in certain projects, and get notified about a task when watching a related project tag. Thanks!

Thanks so much for all the info @Dreamy_Jazz. I've added more context to the description, so that my use case and its connection to OKR work is clearer.