Change Details

=== Story To more accurately assess the impact of Tone Check in T387918, I would like to identify edit attempts that **would have** been shown Tone Check during their edit session but **were not** because the user was bucketed into the control group. These edits would be equivalent to edits in the test group that would have caused one or more Tone Checks to be presented, except that the prompt was not shown because of the user's assigned bucket. This will allow me to directly compare edits eligible for tone check in both the test group and the control group in the AB test. === Requirements * Event sent when edit Tone Check would have been shown to user bucketed in the control group. * Equivalent to `check-shown-presave` or `check-shown-midedit` events for users sent in test group. * Event sent to identity moment Tone Check would be presented in the Sidebar * Equivalent to `window-open-from-check-[moment]` events sent for users in test group * Instrumentation can be added to `VisualEditorFeatureUse` where current edit check engagement events are tracked.

=== Story To more accurately assess the impact of Tone Check in T387918, I would like to identify edit attempts that **would have** been shown Tone Check during their edit session but **were not** because the user was bucketed into the control group. These edits would be equivalent to edits in the test group that would have caused one or more Tone Checks to be presented, except that the prompt was not shown because of the user's assigned bucket. This will allow me to directly compare edits eligible for tone check in both the test group and the control group in the AB test. === Requirements * Event sent when edit Tone Check would have been shown to user bucketed in the control group. * Equivalent to `check-shown-presave` or `check-shown-midedit` events for users sent in test group. * Event sent to identity moment Tone Check would be presented in the Sidebar * Equivalent to `window-open-from-check-[moment]` events sent for users in test group * Instrumentation can be added to `VisualEditorFeatureUse` where current edit check engagement events are tracked. === Done - [ ] `Requirements` are implemented - [ ] Editing QA verifies events are being emitted as expected - [ ] Product analytics verifies events are being stored in DB as expected

=== Story To more accurately assess the impact of Tone Check in T387918, I would like to identify edit attempts that **would have** been shown Tone Check during their edit session but **were not** because the user was bucketed into the control group. These edits would be equivalent to edits in the test group that would have caused one or more Tone Checks to be presented, except that the prompt was not shown because of the user's assigned bucket. This will allow me to directly compare edits eligible for tone check in both the test group and the control group in the AB test. === Requirements * Event sent when edit Tone Check would have been shown to user bucketed in the control group. * Equivalent to `check-shown-presave` or `check-shown-midedit` events for users sent in test group. * Event sent to identity moment Tone Check would be presented in the Sidebar * Equivalent to `window-open-from-check-[moment]` events sent for users in test group * Instrumentation can be added to `VisualEditorFeatureUse` where current edit check engagement events are tracked. === Done - [ ] `Requirements` are implemented - [ ] Editing QA verifies events are being emitted as expected - [ ] Product analytics verifies events are being stored in DB as expected