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.

The caveats:

• First, as with other change tags, this registers whether the user was using the mobile version of the website, not whether they were using a mobile device.
  • Particularly because many moderator workflows are (AIUI) not well supported on the mobile website, it's possible/likely that lots of moderators manually switch to the desktop website on their phones, which would > mean the numbers of mobile moderator actions according to this are going to be a significant undercount.
  • And determining "mobile" based on the device itself would be a huge task, because at the moment we don't use definition anywhere
• Second, (because we aren't sure if this functionality is widely known or used), the implementation may be partial (e.g. some actions may not have mobile tags) or buggy (e.g. in test queries Neal noticed that this > > automated AbuseFilter block has mobile and VE tags, probably because the edit which triggered the block was a mobile VE edit, which means it's not a mobile moderator action).

It looks like the change tagging system already supports tags on log actions, and mobile tagging is implemented for at least some things, (thanks for the find, @nshahquinn-wmf!), so we may have a third option now.

Weekly update

• Completed additionally requested visualization (new crosstabs, aesthetic changes, corrections, etc.)
• Helped relevant stakeholders start qualitative coding by providing them with the needed data

Weekly update

• Finish updating, running, and debugging R scripts (analysis, viz) for new/updated questions in the following sections:
  • Phabricator
  • Continuous integration
  • Deployment
  • API
  • MediaWiki Core backend
  • Overall
• Cleaned data
• Ran all code, debug
• Generated all initial visualizations

For Global Readers Survey Non-English

Closing this task. Work is underway, and it is being documented via the following tickets:

• Finish updating R scripts (cleaning, wrangling) per survey changes/additions

For Global Readers Survey Non-English

For Global Readers Survey English

• Queried and wrangled response data
• Joined with session data
• Completed data pulls for state iii/iv analyses
  • session length
  • topics
  • language
  • (top) pageviews
  • other webrequest data
• Completed calculation and application of weights

Weekly update:

Weekly update

Weekly update:

Weekly update

• Finished testing, revisions
• Deployed survey Dec 4, on schedule 🎉
• And currently...
  • Monitoring response rates
  • Monitoring for bugs/other issues
  • Continuing to update survey codebook

Weekly update

Weekly udpate:

Weekly update:

Weekly update:

Weekly update:

Weekly update:

Weekly update:

• Queried the QS data
• Wrangled response data for analysis next week: cleaned; accounted for dupes, click-backs; reshaped
• Next week: join with session data; begin stage ii analysis

Weekly update:

Weekly update

Weekly update:

Weekly update