At account creation time, if the user is assigned variant C, the suggested edits module should be pre-initiated. In variant D, it's not pre-initiated.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | MMiller_WMF | T238887 [EPIC] Growth: Homepage variant tests | |||
| Resolved | RHo | T246533 Variant tests: "initiation part 2" test (C vs. D) | |||
| Resolved | MMiller_WMF | T250331 Variant tests: C-desktop | |||
| Resolved | MMiller_WMF | T250440 Variant tests: C-mobile | |||
| Resolved | Catrope | T258023 Variant C: pre-initiate suggested edits module on account creation |
Event Timeline
Comment Actions
Change 613312 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] Homepage: Store and manage variants
Comment Actions
Change 613312 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Store and manage variants
Comment Actions
@MMiller_WMF - just to let you know (no issues found):
- Checked in betalabs where it's set to 50/50 for C and D variants.
- variants won't be assigned to users who manually enable Homepage?
Comment Actions
This looks good to me in beta. To be resolved after feature is in production.
@Etonkovidova -- for your question about assigning variants, I will file a task about that.
Comment Actions
@Catrope -- I noticed something that needs to be fixed. When the user first arrives, there should be a pulsing blue dot on the topic filter button in the module (like we do in Variant A if someone initiates the module without having selected topics in the onboarding). Here's the original requirement from T250331: Variant tests: C-desktop:
- Suggested edits module
- The initiated suggested edits module is already present on the page upon arrival, including the pulsing blue dot on the topic filter.
- The module has an "i" icon in the upper right, which opens up the "Onboarding" sequence described below.
Comment Actions
The pulsating blue dot on the topic filter button is broken in all variants (not just C/D, but A as well). It looks like it was broken by this refactoring change, which was merged in early May.
Comment Actions
Change 631882 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] GrowthTasksApi: Correctly distinguish when topic filters were never set
Comment Actions
@nettrom_WMF @MMiller_WMF starting with the next train, you'll see action_data for se-task-impression events with contents like taskCount=null;topics=null;newcomerTaskToken=ecfee1a7970a92c96d40, is topics=null ok or would you like the output to be an empty string, as topics=.
Comment Actions
Change 631882 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] GrowthTasksApi: Correctly distinguish when topic filters were never set
Comment Actions
@kostajh -- I think null is okay, but what did the output look like before when no topics are selected? I believe it just did not have that topics parameter. Is that right? Why did we change this?
Comment Actions
@MMiller_WMF before the patch, it looked like taskTypes=copyedit,links;topics=;taskCount=70;newcomerTaskToken=TOKEN
@Catrope made the patch to fix detection of when a user never set their topic filters (so that the user can see the pulsing blue dot), and that relies on using null instead of '' (empty string). We can adjust the newcomer task logging so that we output topics=; as it was before this patch, but it seems like null should be OK since we use that for taskCount currently (and I've also seen it for taskTypes although having trouble reproducing that; it seems like a bug).