These are notes towards creating a unified log of editing-related events.
Stakeholders Partial list, as I become aware of the interested parties:
- YuviPanda: maintaining the mobile apps and their client-side logging
- Ori: recently instrumented EditConflict
- Analytics: need more comprehensive funnel data
- Eloquence: need conflict data for collaborative, realtime editing planning
- LTretikov: need funnel and die-off data for strategic planning
- Whole page
- Comment only
- Null (no content changed)
- Undo / rollback
- Begin edit session: an edit page impression is sent to the client's browser. This contains a temporary token which must be included with the edit submission. This token is used to group lifecycle events for the edit session.
- Submit edit
- Edit succeeded
- Edit failed
Unified log implementation
Schema:Edit looks like the best starting point. Let's make this useful for editor die-off analysis as a first goal.
Records high-level event types used to model edit sessions
- begin edit impression
- api action=visualeditor, paction=parse
- api action=visualeditoredit
Implemented by Schema:EditDebugging.
Probably, introduce a second log stream with low-level details, for example:
Clicks (events from existing Edit:Schema)
- edit-conflict: an edit was submitted and failed because of a conflict
- edit-hook-aborted: a hook prevented the edit (expand if possible)
- edit-blocked: user was blocked from editing
- edit-overflow: content too big
- edit-read-only: Edit failed because the page is read-only (from the user's point of view)
- edit-rate-limited: this edit was throttled
- edit-blank: edit failed because it was going to create an empty page or a blank section
- edit-no-create: the title was protected
- edit-article-deleted: someone pulled the rug out
- edit-summary-needed: a "need summary" rule was triggered
- edit-spam-blocked: core spam detection
- edit-parse-error: failed to parse...
- edit-generic-failure: other unknown edit failures
- lost-session: the token or login expired
- edit-rebased: an edit was submitted and was successfully fast-forwarded to a new parent
Add server-side logging in WikiPage and EditPage.
Add platform details: isApi, isMobile...
How is "latency" calculated, and can the concept be generalized or abandoned?
Look at the existing log databases to audit for various edit platform messages.
- EditPage::internalAttemptSave is not instrumented by hooks. Clean up the failure code paths, push the logic a level deeper, and add hooks to the new wrapping function. https://gerrit.wikimedia.org/r/#/c/141113/ https://gerrit.wikimedia.org/r/#/c/141114/
- We might have to rely on a client-side event for mobile editing "begin".