@KStoller-WMF is this something you want us to work on in the short term? Should users who create accounts in this workflow be able to complete the WelcomeSurvey later, via some UX on Special:Homepage?

In T310320#7994209, @kostajh wrote:

@KStoller-WMF is this something you want us to work on in the short term? Should users who create accounts in this workflow be able to complete the WelcomeSurvey later, via some UX on Special:Homepage?

@KStoller-WMF this task is related to the work we are doing in T267273: [arwiki] Submitting a POST on a form redirected to immediately after account creation sometimes logs user out . If you could clarify if this is something we should be doing now, then I could incorporate it into the patches for T267273: [arwiki] Submitting a POST on a form redirected to immediately after account creation sometimes logs user out .

@kostajh my understanding is that this task is separate from T267273 , but certainly could be done in tandem if you think that makes sense.

This isn't urgent, but something I think we should pull in soon based on results from @nettrom_WMF 's NEWTEA Revisted data analysis. I wanted to be sure to discuss it with you and @RHo first, since I don't know enough about the account creation flow to know if it's even possible to just wait until after an edit to present the welcome survey and "get started here" prompt.

@RHo any thoughts on presenting the Welcome Survey later from the Special:Homepage? Or could/should we consider skipping the welcome survey in this case (as we already have a clear indication as to why they are creating their account).

In T310320#7994858, @KStoller-WMF wrote:

@kostajh my understanding is that this task is separate from T267273 , but certainly could be done in tandem if you think that makes sense.

It is separate, but T267273 touches the same areas of code, so if the specification is finalized I could incorporate the changes now. But on second thought, I'll just finish up with T267273 and keep in mind that we may make updates to it soon. :)

This isn't urgent, but something I think we should pull in soon based on results from @nettrom_WMF 's NEWTEA Revisted data analysis. I wanted to be sure to discuss it with you and @RHo first, since I don't know enough about the account creation flow to know if it's even possible to just wait until after an edit to present the welcome survey and "get started here"

Maybe we could do a custom version of the post-edit dialog for these users. The dialog would invite them to visit Special:Homepage or to take the welcome survey.

@RHo any thoughts on presenting the Welcome Survey later from the Special:Homepage? Or could/should we consider skipping the welcome survey in this case (as we already have a clear indication as to why they are creating their account).

In previous iterations of the homepage, we had a "Start" module that prompted the user to confirm their email, create a user page, and read a tutorial. We could probably bring back something like that again, and have it include a step for filling out the survey.

In T310320#7997836, @kostajh wrote:

In T310320#7994858, @KStoller-WMF wrote:

@kostajh my understanding is that this task is separate from T267273 , but certainly could be done in tandem if you think that makes sense.

It is separate, but T267273 touches the same areas of code, so if the specification is finalized I could incorporate the changes now. But on second thought, I'll just finish up with T267273 and keep in mind that we may make updates to it soon. :)

This isn't urgent, but something I think we should pull in soon based on results from @nettrom_WMF 's NEWTEA Revisted data analysis. I wanted to be sure to discuss it with you and @RHo first, since I don't know enough about the account creation flow to know if it's even possible to just wait until after an edit to present the welcome survey and "get started here"

Maybe we could do a custom version of the post-edit dialog for these users. The dialog would invite them to visit Special:Homepage or to take the welcome survey.

@RHo any thoughts on presenting the Welcome Survey later from the Special:Homepage? Or could/should we consider skipping the welcome survey in this case (as we already have a clear indication as to why they are creating their account).

In previous iterations of the homepage, we had a "Start" module that prompted the user to confirm their email, create a user page, and read a tutorial. We could probably bring back something like that again, and have it include a step for filling out the survey.

Hiya, my proposal would be as a first step it would be good to change one thing (and perhaps only as a variant test?), which is to take users who were already in the process of editing a page immediately back to the edit context after account creation, and only show them the option to fill in the welcome survey survey as an option after they submit the edit (or else go straight to their homepage).

I don't think we should necessarily bring back the Start module as it was in the previous iterations, since that was there more so as some other actions users could take before we had the Suggested edits module, but now we mainly want them to edit instead of doing a tutorial or creating a user page. However, we could add in an option to complete the welcome survey as a dismissible 'banner' module for any newcomer who skipped it initially (not just new accounts in the middle of an edit), perhaps with some expiry period to remove it (eg., 30d) when it is no longer relevant:

After discussion with @KStoller-WMF, what I suggested above is amended slightly so that the dialog after a new account creates an edit will only have the single CTA to go to the homepage. To recap, the following is proposal for this task:

A. Allow new accounts that were created mid-edit to complete their edit before showing a dialog to go to the homepage.

B. Show a message module with a link to complete the Welcome survey for anyone who did not complete survey.

• Uses same design as the 'banner' module but with an additional close icon to enable the user to dismiss it.
• Set an expiry period to remove the banner module 30 days if the WelcomeSurvey is not completed (and it has not already been dismissed by the user).

It would be nice to finish T267273: [arwiki] Submitting a POST on a form redirected to immediately after account creation sometimes logs user out before starting with this one, as that patch changes the hooks that we use for redirecting the user. Or put another way, perhaps the patch for this can build on top of the patch for T267273.

A. Allow new accounts that were created mid-edit to complete their edit before showing a dialog to go to the homepage.

@nettrom_WMF for instrumentation purposes, should interactions with this dialog use the existing analytics/legacy/helppanel schema? That's what we use for post-edit dialog events. It might be a stretch to include events for this in that schema, but creating a new schema seems like a lot of overhead for this one component.

@KStoller-WMF @RHo IMO we should provide a button to let the user not proceed ("Close"), "Go to my homepage" could be the progressive, blue button of course to entice the user to go there. But the user might want to admire their edit or otherwise interact with the page they're on before going on to Special:Homepage.

Also, what should happen with the guided tours? In their current configuration, as soon as the user has created their account and is back on the article page, they'll see:

I assume we should defer the display of this tour until after the user does an edit?

In T310320#8022727, @kostajh wrote:

@KStoller-WMF @RHo IMO we should provide a button to let the user not proceed ("Close"), "Go to my homepage" could be the progressive, blue button of course to entice the user to go there. But the user might want to admire their edit or otherwise interact with the page they're on before going on to Special:Homepage.

Yes, you're right @kostajh, that was my oversight. I've added the second close CTA to the dialog now.

Also, what should happen with the guided tours? In their current configuration, as soon as the user has created their account and is back on the article page, they'll see:

I assume we should defer the display of this tour until after the user does an edit?

I was originally thinking that we could keep it simple with minimal changes since the use case easily dismiss/ignore the pop-up here without changing the logic for seeing this guided tour pop-up/mobile banner. However, are you saying it is easy to change it so that this only appears after the person navigates to a different page to the one they just finished editing? If so, then yes that would be preferred.

In T310320#8022721, @kostajh wrote:

A. Allow new accounts that were created mid-edit to complete their edit before showing a dialog to go to the homepage.

@nettrom_WMF for instrumentation purposes, should interactions with this dialog use the existing analytics/legacy/helppanel schema? That's what we use for post-edit dialog events. It might be a stretch to include events for this in that schema, but creating a new schema seems like a lot of overhead for this one component.

I think using the HelpPanel schema makes sense for this as it's already used to log post-edit dialogue events. From what I can tell by checking the schema, adapting it to do this could be relatively straightforward as we have a type key in action_data for describing the context of an impression. We also already have linking to the Homepage as a possible later action. I checked the HomepageVisit schema as well to check the referer_route values and noticed that the post-edit dialogue is already there, so that's good to go.

So far I think the question I have is whether we add a new value for type in action_data for impressions in this context? It would make sense to me since it makes it easy to identify those kinds of Help Panel sessions both when looking at the data and when using it in analysis.

Please do let me know if I missed something or left open questions hanging.

In T310320#7997836, @kostajh wrote:

In T310320#7994858, @KStoller-WMF wrote:

@kostajh my understanding is that this task is separate from T267273 , but certainly could be done in tandem if you think that makes sense.

It is separate, but T267273 touches the same areas of code, so if the specification is finalized I could incorporate the changes now. But on second thought, I'll just finish up with T267273 and keep in mind that we may make updates to it soon. :)

Thanks for taking on this task, @Tgr. Just wanted to make sure you saw this comment–does it make sense to you to build on top of the redirection patch for T267273: [arwiki] Submitting a POST on a form redirected to immediately after account creation sometimes logs user out so we don't have to redo that one?

In T310320#8068459, @kostajh wrote:

does it make sense to you to build on top of the redirection patch for T26273: pywikipedia Code Review so we don't have to redo that one?

Either that, or I'll just update the (yet-to-be-written) code when that patch lands. I don't think there is a lot of overlap in any case, just an extra line or two in the condition checks for post-login redirection.

@nettrom_WMF do we want to differentiate somehow between users arriving from registration and users arriving from the homepage for analytics? Currently the only analytics-related parameter is a _welcomesurveytoken URL query parameter, which is a random token that's used both on the survey page and whatever page the user is sent to afterwards.

Change 818069 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Add WelcomeSurveyReminder homepage module

https://gerrit.wikimedia.org/r/818069

@KStoller-WMF this is how I'm defining "anyone who did not complete the welcome survey" in the WIP patch:

• The user has not submitted the survey.
• The user isn't past the survey data retention period (~60 days after registration; after that there is no way to tell whether they filled out the survey, and this task doesn't seem worth adding a new data storage mechanism).
• The user has not pressed the "Skip" button on the survey.
• The user is not in an A/B test group which is not supposed to get the survey.

Let me know if that works or you'd like to handle some of those cases differently.

Change 818288 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Delay showing the welcome survey if the user was editing

https://gerrit.wikimedia.org/r/818288

In T310320#8068399, @Tgr wrote:

In T310320#8023299, @nettrom_WMF wrote:

I think using the HelpPanel schema makes sense for this as it's already used to log post-edit dialogue events.

What happens if the help panel is disabled on that wiki? It's unlikely to happen in practice, but theoretically possible.

I guess we can just skip logging in that edge case.

Apologies for not seeing this sooner, but since I agree with you that we can skip logging in this case it wasn't critical. From my perspective we'll most likely get enough data from other wikis to understand how this works.

In T310320#8110976, @Tgr wrote:

@nettrom_WMF do we want to differentiate somehow between users arriving from registration and users arriving from the homepage for analytics? Currently the only analytics-related parameter is a _welcomesurveytoken URL query parameter, which is a random token that's used both on the survey page and whatever page the user is sent to afterwards.

I don't think we need to add anything extra because I think measuring the time between registration and submitting the survey will be a good proxy here. Once this is in place we'll probably have a bimodal distribution of survey responses with one group submitting a minute or two after registration and the rest showing up later. It's that delay that's important to me, not necessarily how they got to the survey.

In T310320#8111349, @Tgr wrote:

@KStoller-WMF this is how I'm defining "anyone who did not complete the welcome survey" in the WIP patch:

• The user has not submitted the survey.
• The user isn't past the survey data retention period (~60 days after registration; after that there is no way to tell whether they filled out the survey, and this task doesn't seem worth adding a new data storage mechanism).
• The user has not pressed the "Skip" button on the survey.
• The user is not in an A/B test group which is not supposed to get the survey.

This sounds good to me. Thank you!

This is ready for desktop.

I'm not really sure what to do about mobile. Minerva apparently reloads the page after an edit is saved, right after the postedit hook is run, so the hook isn't really useful for showing a notice. The pageview after that reload is a normal pageview, undifferentiable from any others. We could probably pass state in the form of a cookie, but it would further complicate the already very complex logic for tracking mid-edit registrations, and the user will see the mobile discovery notice which says more or less the same thing - is there enough added value in the fancier dialog-based notice to do it?

@Tgr So we can ensure Growth features no longer "interrupt" a mobile user who just signed up before they complete an edit, but we can't then add the notice to visit their newcomer homepage after they save an edit (unless we add some messy/complex logic). Is that correct?

If I'm understanding that right, and like you said, the user will still see the mobile discovery notice which says more or less the same thing, then I think this all sounds fine and we can proceed without adding the fancier dialog-based notice.

In T310320#8149030, @KStoller-WMF wrote:

@Tgr So we can ensure Growth features no longer "interrupt" a mobile user who just signed up before they complete an edit, but we can't then add the notice to visit their newcomer homepage after they save an edit (unless we add some messy/complex logic). Is that correct?

That's correct.

In T310320#8141846, @Tgr wrote:

This is ready for desktop.

I'm not really sure what to do about mobile. Minerva apparently reloads the page after an edit is saved, right after the postedit hook is run, so the hook isn't really useful for showing a notice.

My understanding is that this shouldn't happen anymore, per T219420: Update page dynamically after save on mobile.

@KStoller-WMF @nettrom_WMF should we instrument the dialog? I assume we'd want to log:

• impression
• closing
• clicking "Homepage"

For the reminder banner on Special:Homepage, the patch has:

Clicks on the survey and skip links will be logged with the link
IDs welcomesurvey-reminder and welcomesurvey-skip. Survey visits
and survey->homepage visits will be logged the same way they would
be during registration.

In T310320#8188404, @kostajh wrote:

@KStoller-WMF @nettrom_WMF should we instrument the dialog? I assume we'd want to log:

• impression
• closing
• clicking "Homepage"

Sure, that makes sense to me.

In T310320#8188404, @kostajh wrote:

@KStoller-WMF @nettrom_WMF should we instrument the dialog? I assume we'd want to log:

• impression
• closing
• clicking "Homepage"

For the reminder banner on Special:Homepage, the patch has:

Clicks on the survey and skip links will be logged with the link
IDs welcomesurvey-reminder and welcomesurvey-skip. Survey visits
and survey->homepage visits will be logged the same way they would
be during registration.

I'm a little bit confused about what we're looking to instrument here, but I'm sure that the answer is "yes" to the instrumentation question regardless of what we're instrumenting :)

We originally discussed instrumenting the post-edit dialogue using the HelpPanel schema and I agreed with that in T310320#8023299. Is that the dialogue you were asking about instrumenting, @kostajh ? I'm still in favour of instrumenting it, and the three actions you propose are also what I figured we'd collect data on. The only concern I have here is the one mentioned in my comment, that we set a different value for the context if possible to make it easy to distinguish it from other post-edit dialogues.

For the banner on the Homepage, clicking a link with ID welcomesurvey-reminder means they followed the link to the survey, and welcomesurvey-skip means the closed the banner asking to not see it again? Those look good to me!

Change 828676 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[schemas/event/secondary@master] analytics/legacy/helppanel: Add new actions related to mid-edit signup

https://gerrit.wikimedia.org/r/828676

Change 828676 merged by jenkins-bot:

[schemas/event/secondary@master] analytics/legacy/helppanel: Add new actions related to mid-edit signup

https://gerrit.wikimedia.org/r/828676

Change 818069 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add WelcomeSurveyReminder homepage module

https://gerrit.wikimedia.org/r/818069

Change 818288 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Delay showing the welcome survey if the user was editing

https://gerrit.wikimedia.org/r/818288

@Etonkovidova this is going to be in MW-1.40-notes (1.40.0-wmf.1; 2022-09-12), could you please do some QA in betalabs and testwiki today, so that if any adjustments or fixes are needed we could backport them in time for group2 deployment?

In T310320#8231506, @kostajh wrote:

@Etonkovidova this is going to be in MW-1.40-notes (1.40.0-wmf.1; 2022-09-12), could you please do some QA in betalabs and testwiki today, so that if any adjustments or fixes are needed we could backport them in time for group2 deployment?

@Etonkovidova @KStoller-WMF see here for some of the UX issues with the process when using VisualEditor on desktop: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/818288/16#message-d5c2cdd7c5c742b5a0055e001cc5fc91f9f310f9

In T310320#8245256, @kostajh wrote:

In T310320#8231506, @kostajh wrote:

@Etonkovidova this is going to be in MW-1.40-notes (1.40.0-wmf.1; 2022-09-12), could you please do some QA in betalabs and testwiki today, so that if any adjustments or fixes are needed we could backport them in time for group2 deployment?

@Etonkovidova @KStoller-WMF see here for some of the UX issues with the process when using VisualEditor on desktop: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/818288/16#message-d5c2cdd7c5c742b5a0055e001cc5fc91f9f310f9

I guess it is OK. What happens:

• Logged-out user is editing article in VE on desktop, clicks "Create account" prompt from VE
• That opens a new tab; user fills out account creation form, and then is prompted to go to WelcomeSurvey.
• WelcomeSurvey offers to take user back to the article they were editing

Tab 1 has the article with any unsaved changes the user may have already made; Tab 2 has the article in View mode. If the user goes to Tab 1 and presses save, VE will tell them that they're now logged-in, and that their changes will be associated with the logged-in user if they proceed. If they press "Try again", the edit is associated with the new user.

Hmmm, yeah that does still sound like a somewhat confusing flow, but it also sounds like there are some technical reasons why it's a challenge to improve.

I thought we were skipping the Welcome Survey for users who started account creation while mid-edit?

In T310320#8245327, @KStoller-WMF wrote:

Hmmm, yeah that does still sound like a somewhat confusing flow, but it also sounds like there are some technical reasons why it's a challenge to improve.

I thought we were skipping the Welcome Survey for users who started account creation while mid-edit?

Um, right. I will look at it later, unless @Tgr does first. But IIRC we have some limitations based on VE opening the account creation link in a new tab/window.

To recap the relevant part of the gerrit discussion:

• VE omits the returntoquery parameter that the same "log in or register if you don't want your IP address published" (anoneditwarning) notice does use in core. This means it won't return to the editor after going through the signup process. Since we are triggering welcome survey skipping based on whether the user is going to return to editing, the survey won't be skipped. This might be an oversight on VE's part; when the logic was added in Ia28f59a341e1a04b4d143abbfe5c63e4a420056f, it matched the core logic which also didn't have returntoquery, and then VE did not get updated when core was. Easy to fix, I'm not sure how useful it would be though since...
• VE adds target=_blank to the links in the notices, forcing them to open in a new window. This is an understandable choice, even though in theory the editor would recover the contents if you navigate away and then return, but that still seems disruptive. But then, returning to the same page in the new window seems more confusing than useful. Opening the editor in the new window would be even more so. Typically, if you log in in a popup, that popup should close when you are finished.
• The VE UX stays logged out if you log in in a separate window, and still shows the anoneditwarning warning, even though the edit will not actually be anonymous if you save it. (This comes with all kinds if side issues, e.g. the save options are different for an anonymous and a logged-in user, such as the "minor" flag or the watchlist options not being available for anons.) This is obviously bad but not easy to fix - the old wikitext editor can be refreshed by doing a preview, but I don't think VE has anything similar.

Maybe what could be done is:

• make returnto point to something like Special:FinishLogin when the link opens in a new window;
• make Special:FinishLogin close the current window;
• before doing that, have it call back to the parent window and trigger an autologin attemept, which will at least refresh the user menu on CentralAuth wikis, although it won't do anything useful in vanilla MediaWiki.
• As a stretch goal, maybe add target=_blank to the wikitext editor as well, and have the JS callback do a preview in that case.

Change 833108 had a related patch set uploaded (by Nettrom; author: Nettrom):

[schemas/event/secondary@master] Add Welcome Survey reminder to the module list

https://gerrit.wikimedia.org/r/833108

Change 833323 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833323

Change 833108 merged by jenkins-bot:

[schemas/event/secondary@master] Add Welcome Survey reminder to the module list

https://gerrit.wikimedia.org/r/833108

Change 833323 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833323

In T310320#8245693, @Tgr wrote:

To recap the relevant part of the gerrit discussion:

• VE omits the returntoquery parameter that the same "log in or register if you don't want your IP address published" (anoneditwarning) notice does use in core. This means it won't return to the editor after going through the signup process. Since we are triggering welcome survey skipping based on whether the user is going to return to editing, the survey won't be skipped. This might be an oversight on VE's part; when the logic was added in Ia28f59a341e1a04b4d143abbfe5c63e4a420056f, it matched the core logic which also didn't have returntoquery, and then VE did not get updated when core was. Easy to fix, I'm not sure how useful it would be though since...
• VE adds target=_blank to the links in the notices, forcing them to open in a new window. This is an understandable choice, even though in theory the editor would recover the contents if you navigate away and then return, but that still seems disruptive. But then, returning to the same page in the new window seems more confusing than useful. Opening the editor in the new window would be even more so. Typically, if you log in in a popup, that popup should close when you are finished.
• The VE UX stays logged out if you log in in a separate window, and still shows the anoneditwarning warning, even though the edit will not actually be anonymous if you save it. (This comes with all kinds if side issues, e.g. the save options are different for an anonymous and a logged-in user, such as the "minor" flag or the watchlist options not being available for anons.) This is obviously bad but not easy to fix - the old wikitext editor can be refreshed by doing a preview, but I don't think VE has anything similar.

Maybe what could be done is:

• make returnto point to something like Special:FinishLogin when the link opens in a new window;
• make Special:FinishLogin close the current window;
• before doing that, have it call back to the parent window and trigger an autologin attemept, which will at least refresh the user menu on CentralAuth wikis, although it won't do anything useful in vanilla MediaWiki.
• As a stretch goal, maybe add target=_blank to the wikitext editor as well, and have the JS callback do a preview in that case.

I'm moving this part into T318142: Account creation + Growth tools: Improve UX for desktop VisualEditor

Change 833037 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.1] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833037

Change 833038 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.2] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833038

Change 833037 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.1] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833037

Change 833038 merged by Urbanecm:

[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.2] Update HomepageModule schema version

https://gerrit.wikimedia.org/r/833038

Mentioned in SAL (#wikimedia-operations) [2022-09-20T13:39:57Z] <urbanecm@deploy1002> Synchronized php-1.40.0-wmf.1/extensions/GrowthExperiments/extension.json: 1a27e05a7ca53a063d5f9e284d6a09546ac8691c: Update HomepageModule schema version (T310320) (duration: 03m 52s)

Mentioned in SAL (#wikimedia-operations) [2022-09-20T13:43:37Z] <urbanecm@deploy1002> Synchronized php-1.40.0-wmf.2/extensions/GrowthExperiments/extension.json: 1ac09d4709c645558f644a885fadc49c05cc04b9: Update HomepageModule schema version (T310320) (duration: 03m 39s)

Checking in wmf.2

• an anon user edits an article in VE - sees create account in the VE warning
• click on the create an account link - Special:CreateAccount pag opens in a new tab
• after an account is created, a user is taken to previously edited article in Read mode
  • a user doesn't see WelcomeSurvey
  • a user doesn't see the Homepage guided tour
• only when visiting Special:Homepage, a user sees the banner

In T310320#8245256, @kostajh wrote:

In T310320#8231506, @kostajh wrote:

@Etonkovidova this is going to be in MW-1.40-notes (1.40.0-wmf.1; 2022-09-12), could you please do some QA in betalabs and testwiki today, so that if any adjustments or fixes are needed we could backport them in time for group2 deployment?

@Etonkovidova @KStoller-WMF see here for some of the UX issues with the process when using VisualEditor on desktop: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/818288/16#message-d5c2cdd7c5c742b5a0055e001cc5fc91f9f310f9

Thanks, @kostajh! I've looked through those and tested with quite few scenarios on betalabs and testwiki wmf.2 and wmf.3 (with couple of tests on production lang wiki). The challenge was to get into a control (Homepage-enabled group).

Generally, all specs are in place. The screenshots are for illustration (no issues were found):

There are some scenarios, actually the steps in some scenarios, that might be confusing for users, but they are minor and mostly related to VE workflows (as it was pointed out in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/818288/16#message-d5c2cdd7c5c742b5a0055e001cc5fc91f9f310f9). I list them below just as testing notes (could be useful for further QA follow-up if needed):

(1) Anon users during editing see two links to Create account - from the VE warning and from the tool menu:

(2) (an old issue) If anon users, after seeing the VE warning, duly create an account and log in, the warning will still be displayed:

(3) On testwiki wmf.3, a new user account was not in the group with enabled Homepage by default, but the message was displayed after a user finishes the edit.

When a user clicked on "Go to my Homepage", the following page is displayed:

(4) If anon user edits in the Source editor and, then, creates an account, gets returned to the source editor - and publishes an edit, then the message will be flashed momentarily before a page switches to the Read mode.