Addshore created this task.
Addshore added subscribers: Addshore, Lydia_Pintscher.
Addshore added projects: WMDE-Analytics-Engineering, Wikidata.
Herald added subscribers: StudiesWorld, Aklapper.

TASK DESCRIPTION
  It may make sense to split this task when it comes to implementation..
  Everything explained below has an inherent, make some way to display the 
data... (grafana)
  
  JavaScript events can be tracked directly to graphite using  
https://www.mediawiki.org/wiki/ResourceLoader/Modules#mw.track
  We would want to track events as counters (implementation example on the 
wikipage)
  
https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/master/modules/ext.wikimediaEvents.statsd.js#L43-59
  
  **Track every click to an edit link**
  
  As far as I know this can be done somewhere in 
jquery.wikibase.edittoolbar.js, potentially with the "afterstartediting" event.
  event.target could be used to track the type of edit link.
  
  The resulting metric name should be something 
like"wikibase.ui.event.edit.start.TYPE"
  
  **Track every render of the Special edit pages**
  
  This should be split up:
  
    # The UI edit links should also contain a parameter, for example 
http://localhost/w/index.php/Special:SetLabelDescriptionAliases/Q12/en-gb?fromUI=1
 fromUI can then be checked in the PHP and calls with this parameters can be 
tracked, as "wikibase.ui.specialpage.uimiss.TYPE"
    # The special pages should also contain a small amount of JS code to track 
users using the special page when they have JS. Something like 
"wikibase.ui.specialpage.js.TYPE"
    # The special page should also track the number of calls regardless of the 
fromUI parameter existing or not. "wikibase.ui.specialpage.all.TYPE"
  
  The three change above would allow the tracking of:
  
    - Special page usage vs JS UI usage
    - People that choose to use the Special pages (both with and without JS)
    - People that end up on the Special pages due to clicking before the JS has 
loaded fully
  
  **Track errors surfaced throguh the UI**
  
  These could be tracked in the JS, although it may make more sense for these 
to be tracked in PHP in the API.
  It could be possible to distinguish API calls that are made by the UI vs API 
calls made by bots if an extra parameter is passed to the UI, perhaps fromUI=1 
again as mentioned above.
  Error counts of key errors could then simply be sent to statsd in PHP.
  Example metric name could be: "wikibase.api.error.NAME"
  
  **Track usage of key gadgets**
  
  With the JS tracking needed in the first point I imagine some nice methods 
will be used similar to the example linked.
  This could allow gadget to record the number of clicks on key buttons (such 
as opening the gadget)
  Firstly this should be done with the LabelLister gadget
  For example: "wikibase.ui.gadget.NAME.EVENT"
  Note: we don't really want to track very much here, at most 1 or 2 key events 
per gadget...."
  
  **Track collapses & expands**
  
  Very similar to the first point expands and collapses of sections should be 
recorded.
  This should again be recorded with the type of element being expanded or 
collapsed.
  For example: "wikibase.ui.event.expand.TYPE"

TASK DETAIL
  https://phabricator.wikimedia.org/T125404

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Aklapper, Lydia_Pintscher, Addshore, StudiesWorld, Izno, Wikidata-bugs, 
aude, Mbch331



_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to