User:Awight/Edit logging
These are notes towards creating a unified log of editing-related events.
Existing initiatives
- Schema:Edit
- https://wikimedia.mingle.thoughtworks.com/projects/analytics/cards/1372
- Schema:MobileWikiAppEdit
- Schema:NewEditorEdit
- Schema:EditConflict
- Schema:PageContentSaveComplete
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
Edit scenarios
Platform
- Desktop
- Mobile
- App
- API
Edit type
- Whole page
- Section
- Comment only
- Null (no content changed)
- Undo / rollback
Edit events
- 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.
Core events
Implemented by Schema:EditLifecycle and https://gerrit.wikimedia.org/r/#/c/141097/
Records high-level event types used to model edit sessions
- click
- begin edit impression
- api action=visualeditor, paction=parse
- saveAttempt
- api action=visualeditoredit
- saveSuccessful
- saveFailed
Debugging events
Implemented by Schema:EditDebugging.
Probably, introduce a second log stream with low-level details, for example:
Clicks (events from existing Edit:Schema)
Failures
- 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
Informational
- 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.
Issues
- 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".