Change Details

**Issues:** * 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. * 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)

**Issues:** * 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. * 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) * We don't use the core EventLogging code for client-side session token generation and sampling.

**Issues:** * 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. * 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) * We don't use the core EventLogging code for client-side session token generation and sampling.