[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) = Scope = Does it make sense to have one schema that covers all our interfaces? Should the app editors use this schema? What about the Flow editor? What about the Wikidata description tool on Android? * Having a common schema increases the probability that you can get comparable data across all these interfaces (because it forces teams to collaborate), but it doesn't ensure it. * We should only incur the collaboration overhead if the benefits of more comparability are worth it—there's not much point in comparing, say, edit completion rate across Wikidata description editing with general page editing, because their contexts are so very different.

[Current schema](https://meta.wikimedia.org/wiki/Schema:Edit) = Use cases = * Edit completion rate * Time to loaded and time to interactive * Overall edit duration = Name = Proposition: A good schema name describes the unit of observation (e.g. an [UploadWizardStep](https://meta.wikimedia.org/wiki/Schema:UploadWizardStep) event is an individual step with the upload wizard; an [EchoInteraction](https://meta.wikimedia.org/wiki/Schema:EchoInteraction) is a single interaction with the Echo feature). If this is true, this schema should be named "EditFunnelStep" or something similar; "Edit" could easily be confused for a schema for data on edits themselves, which is actually the [mediawiki/revision/create schema](https://github.com/wikimedia/mediawiki-event-schemas/blob/master/jsonschema/mediawiki/revision/create/3.yaml). = 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) = Scope = Does it make sense to have one schema that covers all our interfaces? Should the app editors use this schema? What about the Flow editor? What about the Wikidata description tool on Android? * Having a common schema increases the probability that you can get comparable data across all these interfaces (because it forces teams to collaborate), but it doesn't ensure it. * We should only incur the collaboration overhead if the benefits of more comparability are worth it—there's not much point in comparing, say, edit completion rate across Wikidata description editing with general page editing, because their contexts are so very different.

[Current schema](https://meta.wikimedia.org/wiki/Schema:Edit) = Use cases = * Edit completion rate * Time to loaded and time to interactive * Overall edit duration = Name = Proposition: A good schema name describes the unit of observation (e.g. an [UploadWizardStep](https://meta.wikimedia.org/wiki/Schema:UploadWizardStep) event is an individual step with the upload wizard; an [EchoInteraction](https://meta.wikimedia.org/wiki/Schema:EchoInteraction) is a single interaction with the Echo feature). If this is true, this schema should be named "EditFunnelStep" or something similar; "Edit" could easily be confused for a schema for data on edits themselves, which is actually the [mediawiki/revision/create schema](https://github.com/wikimedia/mediawiki-event-schemas/blob/master/jsonschema/mediawiki/revision/create/3.yaml). = 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) = Scope = Does it make sense to have one schema that covers all our interfaces? Should the app editors use this schema? What about the Flow editor? What about the Wikidata description tool on Android? * Having a common schema increases the probability that you can get comparable data across all these interfaces (because it forces teams to collaborate), but it doesn't ensure it. * We should only incur the collaboration overhead if the benefits of more comparability are worth it—there's not much point in comparing, say, edit completion rate across Wikidata description editing with general page editing, because their contexts are so very different.