Page editing instrumentation

Some areas in which we need data to make some design decisions.

Click tracking

 * Preview
 * Show Changes
 * Marking as a minor edit
 * Move (separate issue and it requires JavaScript on every page, so deferred for now)

Click tracking + content analysis

 * Edit Summaries (How many users provide edit summaries)

Disclaimer
Any data from simple action tracking will lack rigor &mdash; it's a precursor to an experiment, not a valid experiment with testable hypotheses.

Design

 * when Editing (because action is "edit" or "submit"), upon submit events ([Save page] / [Show preview] / [Show changes], possibly others) record the event (using Extension:E3 Experiments' event tracking built on Extension:ClickTracking, as used on Community Portal)
 * besides the usual ClickTracking info, include
 * whether "This is a minor edit?" is checked or not
 * the edit Summary text itself (see )
 * page name and revision

Data format
Sample log lines: As Extension:E3 Experiments/Architecture explains, this is mostly Extension:ClickTracking standard stuff:
 * wiki
 * project@version, i.e. editEvent version 1
 * server timestamp
 * 1 = user is logged in to the wiki, 0 = anonymous
 * anonymized session ID
 * namespace of page (0 = main)
 * user's lifetime edits (if logged in)
 * user's edits in last 6 - 3 - 1 months (if logged in) &mdash; the granular edit counts from UserDailyContribs whether you wanted them or not
 * The final field is additional information specific to this event, for this the format is
 * (with every '@' in editSummary, if any, replaced by '_').

Questions

 * Do we really want to track each click to check and uncheck "This is a minor edit?" Or just record it as part of the [Save page] / [Show preview] / [Show changes] event logging?
 * A: The latter. We log the state of "This is a minor edit?" as true/false when logging form submit events
 * Can we check to see if the summary text was changed from the suggested defaults? Like, there's defaults when you undo or rollback.
 * A: Maybe... on load look at input#wpSummary.mw-summary, remember contents, upon submit see if the contents have changed from e.g. "Undid revision 507859909 by ...". Problem is, on save after preview or show changes, the initial contents will be what the user entered last time. Maybe include the text of the summary (limited to 255 in the HTML form) in the click action, and let later post-processing figure out if it's a stock message. For now, we just store the wpSummary text; analysis is left as "a simple exercise for the reader".