Jump to content

User:Awight/Edit logging

From Wikitech

These are notes towards creating a unified log of editing-related events.

Existing initiatives

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


  • 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)


  • 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.