Page MenuHomePhabricator

Tag all edits made via Wikibase View and Wikibase Client
Open, HighPublic13 Estimated Story Points

Description

Context:
Wikidata Analytics

User story:
As an Analytics PM, I want to be able to query with what interface an edit was made by the user (to perform analysis that will help us to understand our users better).

As a Wikidata user, I want to be able to filter for edits done via the Wikibase View (the regular UI) to e.g. patrol human edits.

Problem:
There is currently no way on Wikidata itself to easily find out which edits are done via the Wikibase View or Wikibase Client.

BDD:
WHEN an entity edit is made using the Wikibase View
AND the "entity-ui" tag has been configured
THEN the edit is tagged with the "entity-ui" tag

etc.

Overview over tags:

ContentTag nameAppearance on change listsFull description of meaningIs this new?
Data Bridgedata-bridgeWikidata Bridgen/aexists
Wikibase Client linkitem (the jQuery UI thing)client-linkitem-changeSitelink Change from Connected WikiAn edit that was made using the sitelinks UI on a connected wiki.new
Wikibase Client UpdateRepo (on page move/delete)client-automatic-updateAutomatic Update from Connected WikiAn edit that was made automatically because a connected page was moved or deleted.new
Wikibase View (legacy / jQuery UI)wikidata-uiWikidata User InterfaceA manual edit made using the regular user interface on Wikidata.new
Wikibase Repo (special pages)wikidata-uiWikidata User Interfacesamenew
Wikibase Termbox v2 (aka mobile termbox)wikidata-ui, termbox (these are 2 separate tags)Wikidata User Interface, Mobile Termboxsame + An edit made using the mobile termbox interface.new

For the Termbox tag, we will change the message as soon as the new termbox will go beyond mobile.

see https://www.wikidata.org/wiki/Special:Tags

Acceptance criteria:

  • these should be configurable as a list of tags, defaulting to the empty list (i.e. disabled by default / no tags) – compare T232580
  • the tags have been created and configured on Wikidata
    • tags for server-side actions – client UpdateRepo, repo special pages – could maybe be “defined by the software”, but tags for client-side / API actions will probably have to be “applied manually by users and bots” (as is the case for the Data Bridge tag already)
  • all edits on entities (e.g. Items, Properties, and Lexemes) that are done via the components in the “overview over tags” table are tagged accordingly
  • any edit made with a bot, tool, gadget, etc. (that is not using the Wikibase View as an intermediary) is not targeted with this
  • there is a Grafana dashboard that shows for a given day the total number of edits and the number of UI edits (we probably want to include other tags in the same graph in the future)

Community communications:

  • We plan to inform the community about our plans asap. Please coordinate with ComCom and Manuel when we are ready to communicate.

Open questions:

  • How should the tags be named? Suggestions are still welcome!

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Manuel updated the task description. (Show Details)

"wikidata-ui + termbox" is one or two tags? If it's one I would recommend not having it because it'll make filtering recent changes harder if there are too many tags for related things.

It's two, for exactly that reason! :)

All the implementation subtasks are done – I think we’re ready to inform the community about this and get the tags created, so that we can add the necessary configuration after next week’s train.

\o/

I'll make sure we communicate this now!

Change 713225 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[operations/mediawiki-config@master] Add tags for wikidata edits

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

Change 713225 merged by jenkins-bot:

[operations/mediawiki-config@master] Add tags for wikidata edits

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

The termbox v2 fails:

{"error":{"code":"badtags","info":"The tag \"wikidata-ui,termbox\" is not allowed to be manually applied.","disallowedtags":["wikidata-ui,termbox"],"*":"See https://www.wikidata.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."},"servedby":"mwdebug2002"}

Probably needs pipe character instead of comma? I double check.

Change 713233 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[operations/mediawiki-config@master] Don't set termbox v2 tags yet

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

Ugh, I assumed that Termbox was using a proper MediaWiki API wrapper but clearly it isn’t.

Change 713233 merged by jenkins-bot:

[operations/mediawiki-config@master] Don't set termbox v2 tags yet

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

Mentioned in SAL (#wikimedia-operations) [2021-08-16T10:32:24Z] <ladsgroup@deploy1002> Synchronized wmf-config/Wikibase.php: Config: [[gerrit:713225|Add tags for wikidata edits (T236893)]] (duration: 00m 58s)

Change 713824 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[operations/mediawiki-config@master] Revert \"Don't set termbox v2 tags yet\"

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

Change 713824 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert \"Don't set termbox v2 tags yet\"

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

Mentioned in SAL (#wikimedia-operations) [2021-08-19T11:40:26Z] <lucaswerkmeister-wmde@deploy1002> Synchronized php-1.37.0-wmf.19/extensions/Wikibase/view/lib/wikibase-termbox/: Backport: [[gerrit:713513|Update termbox (T236893, T286775)]] (duration: 01m 08s)

Mentioned in SAL (#wikimedia-operations) [2021-08-19T11:42:00Z] <lucaswerkmeister-wmde@deploy1002> Synchronized wmf-config/Wikibase.php: Config: [[gerrit:713824|Revert "Don't set termbox v2 tags yet" (T236893, T286775)]] (duration: 01m 06s)

Mentioned in SAL (#wikimedia-operations) [2021-08-19T12:11:19Z] <lucaswerkmeister-wmde@deploy1002> Synchronized php-1.37.0-wmf.18/extensions/Wikibase/view/lib/wikibase-termbox/: Backport: [[gerrit:713523|Update termbox (T236893, T286775)]] (duration: 01m 08s)

Re-opening so that we can continue with the last AC (Grafana dashboard).

Change 715710 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[analytics/wmde/scripts@master] Introduce script to get stats on edits having certain tags

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

Change 715710 merged by jenkins-bot:

[analytics/wmde/scripts@master] Introduce script to get stats on edits having certain tags

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

Change 715817 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[analytics/wmde/scripts@production] Introduce script to get stats on edits having certain tags

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

Change 715817 merged by jenkins-bot:

[analytics/wmde/scripts@production] Introduce script to get stats on edits having certain tags

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

@Ladsgroup if we wanted to collect more granular data it might even be easier to add this to https://github.com/wikimedia/analytics-wmde-scripts/blob/master/src/wikidata/recentChanges.php#L89-L97 which already looks at tags every minute.
I'm aware the AC says "per day" for the Grafana visualization, but that would still be possible while collecting minutely data, that could then also be more easily compared to the other panels on the wikidata-edits dashboard.

Thoughts?

Oh I saw that when deploying. I honestly think we should do it the other way around and move everything to the new script instead. The old code calls the API of recentchanges and goes through them. It looks very wasteful to me (I can be convinced otherwise).

We should probably also check EntitySchema edits.

We deprioritized EntitySchema edits for this first iteration so that one is on purpose. But your Lexeme edit is indeed strange: Lexeme edits should get tagged (and many are, just as intended). I'll have a look at it, thx!

Thx! Then let's add JS edit-tagging where we missed it to complete the tagging of lexeme edits!

Change 720679 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/WikibaseLexeme@master] Wire UI tags to EntityChangersFactory

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

Change 720762 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[analytics/wmde/scripts@master] Fix file permission of recentchanges tags

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

Change 720762 merged by jenkins-bot:

[analytics/wmde/scripts@master] Fix file permission of recentchanges tags

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

Change 720697 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[analytics/wmde/scripts@production] Fix file permission of recentchanges tags

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

Change 720697 merged by jenkins-bot:

[analytics/wmde/scripts@production] Fix file permission of recentchanges tags

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

Change 720679 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Wire UI tags to EntityChangersFactory

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

Oh I saw that when deploying. I honestly think we should do it the other way around and move everything to the new script instead. The old code calls the API of recentchanges and goes through them. It looks very wasteful to me (I can be convinced otherwise).

For most of this dashboard we specifically want minutely data and for it to be as close to live as possible., so the rest of the dashboard should remain as it is.
Perhaps this new panel should live on a different dashboard entirely as it's quite jaring to try and compare it with the other data that is there right now.

Right now it does not matter where the panel lives. I will need to reorganize all of our dashboards anyways at some point. So a different or new dashboard would work if it helps!