Change Details

[Current schema](https://meta.wikimedia.org/wiki/Schema:Edit) == Session identification == * The schema defines `editingSessionId` as "a string of 32 alphanumeric characters, unique to the current page view session; used for grouping events". ** [mw.user](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.user) provides a number of different methods for generating session IDs. ** MobileFrontend [uses sessionId()](https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/304c176f291b68dd300448d12d7133236ec5c8cc/resources/mobile.startup/user.js#L64). ** The visual editor [uses generateRandomSessionId()](https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/4a41a1aa4c6c98465bf4818ed8b8dad621c2712f/modules/ve-mw/init/ve.init.mw.trackSubscriber.js#L20) ** The 2010 wikitext editor [uses MWCryptRand::generateHex(32)](https://github.com/wikimedia/mediawiki-extensions-WikiEditor/blob/38a70500a0d26f10e32df0ed8924f4c10277e3f6/includes/WikiEditorHooks.php#L270). ** @Tbayer says @phuedx has additional information about `mw.user.sessionId()` * Our current implementation of editing sessions is tightly coupled to a page view. However, this doesn't map very well to what we think of as a single edit session: on desktop, switching between the visual editor and the wikitext editor while retaining changes causes a new page view, while on MobileFrontend, aborting an edit using the back button and then reopening the editor (which doesn't preserve your changes) all happens in one page view. * We don't use the core EventLogging code for client-side session token generation and sampling. **Issues:** * The new ability to switch back-and-forth between the visual editor and wikitext invalidates some key assumptions (for example, we probably want to update `action.init.mechanism`) * How should we account for "micro-editing experiences" like Flow? Should they be included in this schema at all? * Even with T124676 resolved, the table is still quite large. Consider whether to drop mostly unused fields like `page.title` or normalize the schema (T123958) * Do our `action.saveFailure.type` values cover all the options? ** For example, T197499 deals with a save failure because the wiki is in read-only mode, which isn't covered. * Problems with hive refinement (T202348) * Does it make sense to have one schema that covers all our interfaces?

[Current schema](https://meta.wikimedia.org/wiki/Schema:Edit) = Use cases = * Edit completion rate * Time to loaded and time to interactive * Overall edit duration == Session identification == * The schema defines `editingSessionId` as "a string of 32 alphanumeric characters, unique to the current page view session; used for grouping events". ** [mw.user](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.user) provides a number of different methods for generating session IDs. ** MobileFrontend [uses sessionId()](https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/304c176f291b68dd300448d12d7133236ec5c8cc/resources/mobile.startup/user.js#L64). ** The visual editor [uses generateRandomSessionId()](https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/4a41a1aa4c6c98465bf4818ed8b8dad621c2712f/modules/ve-mw/init/ve.init.mw.trackSubscriber.js#L20) ** The 2010 wikitext editor [uses MWCryptRand::generateHex(32)](https://github.com/wikimedia/mediawiki-extensions-WikiEditor/blob/38a70500a0d26f10e32df0ed8924f4c10277e3f6/includes/WikiEditorHooks.php#L270). ** @Tbayer says @phuedx has additional information about `mw.user.sessionId()` * Our current implementation of editing sessions is tightly coupled to a page view. However, this doesn't map very well to what we think of as a single edit session: on desktop, switching between the visual editor and the wikitext editor while retaining changes causes a new page view, while on MobileFrontend, aborting an edit using the back button and then reopening the editor (which doesn't preserve your changes) all happens in one page view. * We don't use the core EventLogging code for client-side session token generation and sampling. **Issues:** * The new ability to switch back-and-forth between the visual editor and wikitext invalidates some key assumptions (for example, we probably want to update `action.init.mechanism`) * How should we account for "micro-editing experiences" like Flow? Should they be included in this schema at all? * Even with T124676 resolved, the table is still quite large. Consider whether to drop mostly unused fields like `page.title` or normalize the schema (T123958) * Do our `action.saveFailure.type` values cover all the options? ** For example, T197499 deals with a save failure because the wiki is in read-only mode, which isn't covered. * Problems with hive refinement (T202348) * Does it make sense to have one schema that covers all our interfaces?

[Current schema](https://meta.wikimedia.org/wiki/Schema:Edit) = Use cases = * Edit completion rate * Time to loaded and time to interactive * Overall edit duration == Session identification == * The schema defines `editingSessionId` as "a string of 32 alphanumeric characters, unique to the current page view session; used for grouping events". ** [mw.user](https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.user) provides a number of different methods for generating session IDs. ** MobileFrontend [uses sessionId()](https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/304c176f291b68dd300448d12d7133236ec5c8cc/resources/mobile.startup/user.js#L64). ** The visual editor [uses generateRandomSessionId()](https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/4a41a1aa4c6c98465bf4818ed8b8dad621c2712f/modules/ve-mw/init/ve.init.mw.trackSubscriber.js#L20) ** The 2010 wikitext editor [uses MWCryptRand::generateHex(32)](https://github.com/wikimedia/mediawiki-extensions-WikiEditor/blob/38a70500a0d26f10e32df0ed8924f4c10277e3f6/includes/WikiEditorHooks.php#L270). ** @Tbayer says @phuedx has additional information about `mw.user.sessionId()` * Our current implementation of editing sessions is tightly coupled to a page view. However, this doesn't map very well to what we think of as a single edit session: on desktop, switching between the visual editor and the wikitext editor while retaining changes causes a new page view, while on MobileFrontend, aborting an edit using the back button and then reopening the editor (which doesn't preserve your changes) all happens in one page view. * We don't use the core EventLogging code for client-side session token generation and sampling. **Issues:** * The new ability to switch back-and-forth between the visual editor and wikitext invalidates some key assumptions (for example, we probably want to update `action.init.mechanism`) * How should we account for "micro-editing experiences" like Flow? Should they be included in this schema at all? * Even with T124676 resolved, the table is still quite large. Consider whether to drop mostly unused fields like `page.title` or normalize the schema (T123958) * Do our `action.saveFailure.type` values cover all the options? ** For example, T197499 deals with a save failure because the wiki is in read-only mode, which isn't covered. * Problems with hive refinement (T202348) * Does it make sense to have one schema that covers all our interfaces?