Dan to coordinate with engineers based on technical requirements to develop product requirements, fine tune what we plan to track and coordinate with @iamjessklein to develop UI Actions
Description
Details
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | nshahquinn-wmf | T202132 EPIC: Generate one-off metric snapshots for mobile editing documentation | |||
Resolved | nshahquinn-wmf | T202133 Snapshot: usage of common editing features | |||
Resolved | MMiller_WMF | T205754 [EPIC] Growth: Understanding first day | |||
Resolved | DLynch | T202148 Instrument editing pipeline to be able to figure out which common editing features are used | |||
Resolved | DLynch | T202656 Develop minimum set of UI Actions and Product Requirements |
Event Timeline
@DLynch will be working on this task, documenting his understanding of what he'll be implementing after the discussion we had today.
There's already a bunch of discussion of implementation details in T202148.
From the meeting today: Neil / Dan endorsed the latter plan I mentioned in T202148.
That said, it's slightly more work for us in terms of places to add logging to, but I think we'd get cleaner results by logging the various AnnotationAction methods, and separately adding logging to opening the link dialog and the link context's remove-link button. Avoids the mixing up of link annotation actions with the rest of them, and doesn't overrepresent the user-action weight of things like clearing annotations from a heavily-annotated bit of text. (I.e. Neil probably has to do less data-wrangling after we've logged it.)
Neil should make a new schema, and once we know what that will be called we can land a patch for this.
We'll be sending a log event for every relevant event in a sampled session, not throttling them or logging one "feature X was used in this session" event per session or anything like that, in the forms:
- annotation.bold
- dialog.link
- dialog.image
etc.
We'd probably override the clear-annotation button in the link context popup to claim it's a dialog.link action, rather than an annotation action regardless of what it is technically.
@Neil_P._Quinn_WMF should let us know exactly what data we want to log along with those bare-bones facts. We could quite easily log the same data as is currently associated with the Edit schema, or you could just count on joining to those via the session id if that's possible.
Change 457931 had a related patch set uploaded (by DLynch; owner: DLynch):
[VisualEditor/VisualEditor@master] Tracking: various annotation and dialog actions
Patch hooks up most of the instrumentation. The rest will be in the MW extension (ve.init.mw.trackSubscriber.js), and is blocked on Neil's schema definition.
Throw this into the console to get a sense for what's being logged:
ve.trackSubscribe( 'activity.', function() { console.log.apply( console, arguments ); } );
Change 457931 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Tracking: various annotation and dialog actions
Change 467855 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (474034ad8)
Change 467855 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (474034ad8)