Note this is raised by Czech Wikipedia off-wiki instructors frequently (and I think I mentioned it in one of our checkin meetings). Two suggestions are often:

• enable growth features unconditionally for all users who identify to come from a course in welcome survey
• create a special page, similar to Special:ClaimMentee, that will allow administrators or otherwise privileged users to enable Growth features for given users

Both of them should be relatively trivial. Leaving the rest of the thinking to @kostajh, just wanted to note this here, as it was mentioned to me a couple of times before.

In T284119#7128145, @MMiller_WMF wrote:

@kostajh is going to take the lead on thinking this through and scoping (or will find an engineer on our team who can).

@Urbanecm_WMF do have interest to take this task on in the context of your work on scaling?

I was thinking we could use a query parameter at registration time, something like geOptOut=1, that would be checked in the various LocalUserCreated implementations (help panel, homepage, mentor), and that would basically prevent the code in those hooks running for users created via that path. @Ragesoss would that work for your use case?

In T284119#7128341, @Urbanecm_WMF wrote:

Note this is raised by Czech Wikipedia off-wiki instructors frequently (and I think I mentioned it in one of our checkin meetings). Two suggestions are often:

• enable growth features unconditionally for all users who identify to come from a course in welcome survey

In the past we didn't specifically enable welcome survey for 100% of users; we do that now, but I'm not sure we want to always require that.

• create a special page, similar to Special:ClaimMentee, that will allow administrators or otherwise privileged users to enable Growth features for given users

Both of them should be relatively trivial. Leaving the rest of the thinking to @kostajh, just wanted to note this here, as it was mentioned to me a couple of times before.

This idea has come up as well in the context of making it easier for QA testers or community members to toggle on features. I'm not opposed to that, but it seems outside the scope of what we need to do for this task. Therefore, I'd propose to review that in a separate task at a later time.

How are cohorts defined? Campaigns (ie. a cohort ID passed in a query parameter)? Welcome survey? Or just passing the actual configuration values as query parameters (which in some cases is supported already)?

An example of the first is UploadWizard campaigns, although it might be overkill here. (Depends on how much per-cohort customization we expect - if we foresee things like custom guidance or custom task types somewhere down the line, this is probably the way to go.)

enable growth features unconditionally for all users who identify to come from a course in welcome survey

In this case, you will have users who will select the class even if they aren't part of it. :)

We can have 3 cases here:

• private campaign registration, for instance for training that requires not to have access to (some of the) Growth features first. I should be taken into configuration when users create an account. A parameter in the URL, added by the trainer, could be a possibility.
• public campaign registration, for people signing-up for a public campaign (anyone can participate when joining). This campaign then should be accessible from the homepage, along with the default Homepage experience. But what if multiple campaigns run at the same time?
• default registration

We also need to think about users who will take the private class, and then will left alone on wiki. How do they catch up with the default experience (= using Growth features)? In the case of WikiEd campaigns, how these newcomers are assigned to mentors when the course is over?

In T284119#7128463, @kostajh wrote:

I was thinking we could use a query parameter at registration time, something like geOptOut=1, that would be checked in the various LocalUserCreated implementations (help panel, homepage, mentor), and that would basically prevent the code in those hooks running for users created via that path. @Ragesoss would that work for your use case?

For Wiki Education, a query parameter at registration would probably cover the majority of cases, although not all. The most common way student editors create their accounts is via a link like this: https://dashboard.wikiedu.org/users/auth/mediawiki_signup?origin=https://dashboard.wikiedu.org/courses/University_of_Washington/Uncommon_Leaders_-_Women_and_BIPOC_in_Science_(Spring_2021)?enroll=foo which send them to the account creation flow with params like this: https://en.wikipedia.org/w/index.php?title=Special:CreateAccount&returnto=Special%3AOAuth%2Fauthorize&returntoquery=oauth_consumer_key%3D55a30690bfdd9e3e3a2ba3c8fa455db9%26oauth_token%3D<some-token>. For that case, an extra param for opting out during account creation would probably work smoothly.

Some portion of student editors create an account independently, though — either shortly before they log in through dashboard.wikiedu.org (because they knew they were doing a Wikipedia assignment and signed up on their own) or because they already have an account. Once they've logged in and authorized Wiki Education Dashboard, when they join a course we use the options API to standardize their VisualEditor preferences. (We found this to be important because some students created accounts in the past but haven't used them, and they could have any of the settings that were default at the time of account creation, rather than the current defaults.) If we can also use an options call to standardize Growth options (is this already possible?), that will be a good fallback.

In T284119#7129342, @Ragesoss wrote:

In T284119#7128463, @kostajh wrote:

I was thinking we could use a query parameter at registration time, something like geOptOut=1, that would be checked in the various LocalUserCreated implementations (help panel, homepage, mentor), and that would basically prevent the code in those hooks running for users created via that path. @Ragesoss would that work for your use case?

We don't have code to opt out from growth features, but we still have geForceVariant query parameter, which we used for testing onboarding with C or D variant as desired. Those variants are now a legacy and we no longer use them, but the code is still there (and can be used for other variants; for enwiki, only control as of now).

Any user who registers via https://en.wikipedia.org/wiki/Special:CreateAccount?geForceVariant=control should end up in the control group (ie. the control homepage experience, not control as in "no homepage at all") regardless of current A/B percentage. I just tried it at enwiki (which is in dark mode, and its A/B testing percentage is 0, meaning no new accounts get the homepage), and the parameter works as expected.

In case we remove control variant, geForceVariant=control will still work (as in, opt in), as any user who's in an invalid variant automatically gets whatever is the current default variant for new users.

For Wiki Education, a query parameter at registration would probably cover the majority of cases, although not all. The most common way student editors create their accounts is via a link like this: https://dashboard.wikiedu.org/users/auth/mediawiki_signup?origin=https://dashboard.wikiedu.org/courses/University_of_Washington/Uncommon_Leaders_-_Women_and_BIPOC_in_Science_(Spring_2021)?enroll=foo which send them to the account creation flow with params like this: https://en.wikipedia.org/w/index.php?title=Special:CreateAccount&returnto=Special%3AOAuth%2Fauthorize&returntoquery=oauth_consumer_key%3D55a30690bfdd9e3e3a2ba3c8fa455db9%26oauth_token%3D<some-token>. For that case, an extra param for opting out during account creation would probably work smoothly.

Some portion of student editors create an account independently, though — either shortly before they log in through dashboard.wikiedu.org (because they knew they were doing a Wikipedia assignment and signed up on their own) or because they already have an account. Once they've logged in and authorized Wiki Education Dashboard, when they join a course we use the options API to standardize their VisualEditor preferences. (We found this to be important because some students created accounts in the past but haven't used them, and they could have any of the settings that were default at the time of account creation, rather than the current defaults.) If we can also use an options call to standardize Growth options (is this already possible?), that will be a good fallback.

Considering you are capable to do options calls, it means you should now be do pretty much everything, as we control homepage behavior via (mostly hidden) user preferences.

The main preferences are growthexperiments-homepage-enable and growthexperiments-help-panel-tog-help-panel, which enable (1)/disable (0) the homepage and the help panel (with our code deciding the values, they're either both 0 or both 1, and I do not recommend setting only one of them to 1 and the other one to 0, as doing so could have unintended consequences, cf T284088). growthexperiments-homepage-variant is there to control the A/B testing homepage variant (currently, such test runs only on Growth's pilot wikis [arwiki, bnwiki, cswiki, viwiki], on other wikis, this will be control in all cases). There are also some other preferences that can be used to taylor the behavior more (ie. pre-select certain topics), but for assuring there will be one experience, those three should be enough (or two if opt-out is the desired outcome).

I hope this helps. Let me know if there are any questions.

@Urbanecm_WMF thank you! this is very helpful.

I think it makes sense to add geForceVariant=control to all the account creation links on both Wiki Education Dashboard and Programs & Events Dashboard, as this won't matter for languages that aren't currently doing testing and it will keep new users from en.wiki editathons and such out of the experiment group over the next few months as well.

For the options call, we only do that on Wiki Education Dashboard currently, so I think it makes sense to add disabling the homepage and help panel to the call we already make when a user enrolls in a Wiki Education course. Then we can re-evaluate once the homepage and help tabs become the default experience for new users.

In T284119#7132419, @Ragesoss wrote:

I think it makes sense to add geForceVariant=control to all the account creation links on both Wiki Education Dashboard and Programs & Events Dashboard, as this won't matter for languages that aren't currently doing testing and it will keep new users from en.wiki editathons and such out of the experiment group over the next few months as well.

@nettrom_WMF any concerns about that?

In T284119#7132419, @Ragesoss wrote:

@Urbanecm_WMF thank you! this is very helpful.

I'm glad I could help :).

I think it makes sense to add geForceVariant=control to all the account creation links on both Wiki Education Dashboard and Programs & Events Dashboard, as this won't matter for languages that aren't currently doing testing and it will keep new users from en.wiki editathons and such out of the experiment group over the next few months as well.

It might be worth waiting for @nettrom_WMF or @MMiller_WMF to comment here, on the general issue of forcing people to be in a certain variant. I only intended to comment on the technical ways to do it.

For the options call, we only do that on Wiki Education Dashboard currently, so I think it makes sense to add disabling the homepage and help panel to the call we already make when a user enrolls in a Wiki Education course. Then we can re-evaluate once the homepage and help tabs become the default experience for new users.

Note: We still keep a small control group (with no Growth features at all), to be able to compare with the default scenario. Not sure when/if we'll stop having that group.

In T284119#7132671, @Tgr wrote:

In T284119#7132419, @Ragesoss wrote:

I think it makes sense to add geForceVariant=control to all the account creation links on both Wiki Education Dashboard and Programs & Events Dashboard, as this won't matter for languages that aren't currently doing testing and it will keep new users from en.wiki editathons and such out of the experiment group over the next few months as well.

@nettrom_WMF any concerns about that?

I'm absolutely in favour of making it possible to control whether users get the features or not so that things like Wiki Ed and campaigns can make things work for them. What I need is some way to reliably identify those users so they can be excluded from analysis when needed (such as when comparing the control group with the group getting the Growth features, which relies on random assignment). This identification should preferably be persistent.

I think we discussed using the ServerSideAccountCreation schema to capture something like this last time this topic came up (it already has a campaign field), but I can work with other solutions as well (e.g. a hidden preference, or changing the variant preference to reflect that the user was not randomly assigned (but that would require us to also handle that when reassigning variants)).

Is there a method available right now that I could implement to mark Wiki Education users? Some of them are new accounts where we could set an additional param in the account creation URL, but some create their accounts on their own before joining a course on the Dashboard. But we do attempt to make an options edit immediately after a user self-enrolls in a course, so rolling some kind of identification setting into that will probably be the most reliable way to handle it. (This does not happen for cases where the instructor adds the username to the course, rather than the user doing it themselves while signed in to the Dashboard, but that's relatively rare... and those accounts won't get opted out of any experimental features anway.)

For Programs & Events Dashboard, we don't do an options edit when a user joins a course. It might (or might not) still make sense to try to set them to the control group in the case that they create an account starting from a Programs & Events Dashboard link, if it's simple to set a campaign field or similar via URL param. There are also accounts that get created via the 'request account' feature, where a user puts in their desired username and email and then the Dashboard creates an account for them (via OAuth API action, using the account of the program organizer or a Dashboard admin). The account creation API call could also be modified to set a campaign if that's helpful (and if it's possible).

In T284119#7149341, @Ragesoss wrote:

Is there a method available right now that I could implement to mark Wiki Education users?

I think that mostly depends on "do we want to force-enable the features, or force-disable". by reading this task, it's still not clear to me which one of those two things is desired here.

In T284119#7149725, @Urbanecm_WMF wrote:

In T284119#7149341, @Ragesoss wrote:

Is there a method available right now that I could implement to mark Wiki Education users?

I think that mostly depends on "do we want to force-enable the features, or force-disable". by reading this task, it's still not clear to me which one of those two things is desired here.

At least during the testing period before these become the standard for all new users, I'd like to force-disable them for Wiki Education student editors.

Change 700670 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Make it possible to opt-out of Growth features

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

Change 700671 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Make it possible for users to opt-out of Growth features

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

Change 700670 abandoned by Urbanecm:

[mediawiki/extensions/GrowthExperiments@master] Make it possible to opt-out of Growth features

Reason:

Per discussion, let's go with I08ab0e4f9d instead.

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

Change 701719 had a related patch set uploaded (by Kosta Harlan; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@wmf/1.37.0-wmf.11] Make it possible to force opt-in/opt-out to Growth features during account creation

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

Change 700671 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Make it possible to force opt-in/opt-out to Growth features during account creation

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

Change 701719 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.37.0-wmf.11] Make it possible to force opt-in/opt-out to Growth features during account creation

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

Mentioned in SAL (#wikimedia-operations) [2021-06-28T18:31:39Z] <urbanecm@deploy1002> Synchronized php-1.37.0-wmf.11/extensions/GrowthExperiments/includes/HomepageHooks.php: rEGREecf1d6c47c6c: Make it possible to force opt-in/opt-out to Growth features during account creation (T284119; T284800; 1/3) (duration: 00m 58s)

Mentioned in SAL (#wikimedia-operations) [2021-06-28T18:32:59Z] <urbanecm@deploy1002> Synchronized php-1.37.0-wmf.11/extensions/GrowthExperiments/includes/HelpPanelHooks.php: rEGREecf1d6c47c6c: Make it possible to force opt-in/opt-out to Growth features during account creation (T284119; T284800; 2/3) (duration: 00m 55s)

Mentioned in SAL (#wikimedia-operations) [2021-06-28T18:34:09Z] <urbanecm@deploy1002> Synchronized php-1.37.0-wmf.11/extensions/GrowthExperiments/includes/WelcomeSurveyHooks.php: rEGREecf1d6c47c6c: Make it possible to force opt-in/opt-out to Growth features during account creation (T284119; T284800; 3/3) (duration: 00m 55s)

This is done. You can use geEnabled=0 as a query parameter on Special:CreateAccount to opt out of all Growth features, or geEnabled=1 to force-enable all of them. The geEnabled=1 flag can also be combined with geForceVariant to opt the user into the control or link-recommendation experiment groups.

@Ragesoss You should now have a stable way to opt out/in for any account using the geEnabled flag. Feel free to use it in the dashboard :).

I expect there's nothing else to do here from your POV.

@Ragesoss -- I just wanted to check in and see if the solution here worked for you. Let us know!

@MMiller_WMF : I haven't implemented it yet — it's near the top of my TODO list — but I think it should work fine. I'll report back once I do implement and deploy it, likely this week. Thanks!

I'm working on this now, and I have a few questions.

• Does this parameter work only while a wiki is using experiment groups, or would it also disable the growth features on a wiki where the newcomer homepage is on for all new users? (I don't think this makes an immediate difference, as both dashboard.wikiedu.org and outreachdashboard.wmflabs.org currently send users to en.wikipedia.org for new account creation anyway, but I want to understand whether the behavior will change if/when the homepage becomes default.)

• Does this also work for accounts created via the API, and if so, is the parameter name the same? (We only rarely use the API for account creation from dashboard.wikiedu.org, so if not, I don't think it's a significant problem.)

In T284119#7270644, @Ragesoss wrote:

I'm working on this now, and I have a few questions.

• Does this parameter work only while a wiki is using experiment groups, or would it also disable the growth features on a wiki where the newcomer homepage is on for all new users? (I don't think this makes an immediate difference, as both dashboard.wikiedu.org and outreachdashboard.wmflabs.org currently send users to en.wikipedia.org for new account creation anyway, but I want to understand whether the behavior will change if/when the homepage becomes default.)

Even if the Special:Homepage is configured to be enabled to 100% of new user accounts, you can still use this query parameter flag to opt out.

If in the future, we no longer have a user preference that conditions whether Special:Homepage is enabled, then that query parameter flag wouldn't work. But we don't have any short/medium term plans around that, as far as I know.

• Does this also work for accounts created via the API, and if so, is the parameter name the same? (We only rarely use the API for account creation from dashboard.wikiedu.org, so if not, I don't think it's a significant problem.)

No, I don't believe it does.

@kostajh thanks much!

I've deployed this for both P&E Dashboard and Wiki Education Dashboard. I'll plan on undoing it once Homepage becomes the default on en.wikipedia.

It would work for the account creation API as well, I think, although you'd get an invalid parameter warning as the parameter is not formally registered.

In T284119#7272774, @Tgr wrote:

It would work for the account creation API as well, I think, although you'd get an invalid parameter warning as the parameter is not formally registered.

It's definitely not a behavior we tried to test -- so even if it works, I don't think it should be relied upon.

In T284119#7272798, @Urbanecm_WMF wrote:

In T284119#7272774, @Tgr wrote:

It would work for the account creation API as well, I think, although you'd get an invalid parameter warning as the parameter is not formally registered.

It's definitely not a behavior we tried to test -- so even if it works, I don't think it should be relied upon.

Noted. I won't implement it for API account creation.

@Ragesoss -- thanks for the update! Did you end up implementing it such that all users have the features on? Or so that all users have the features off?

In T284119#7275669, @MMiller_WMF wrote:

@Ragesoss -- thanks for the update! Did you end up implementing it such that all users have the features on? Or so that all users have the features off?

off. New accounts for student editors in Wiki Education-supported are a mix of independently created accounts (for example, because the instructor starts by telling the student they will need to create Wikipedia accounts) and accounts created via a "sign up with Wikipedia" link from the Dashboard (typically, because the instructor distributed a Dashboard enrollment link, which results in the UI below).

I want to minimize the frequency of classmates having different experiences, so my plan is to go the off route until it's default or approaching 100%.