@thcipriani who can work with us from Release-Engineering-Team to clarify this task and document its outcomes?

Hey! Thanks for thinking of the train folks :)

It sounds like this code will be riding the train this quarter. I know very little about the code and the risks here, so it's tricky to give you a direct answer about my level of concern.

As a starting point could you tell me a little more:

• How are you planning to roll this out? Sounds like code will be riding train and you're planning for an extended period on testwikis (via config...somewhere?) tell me more.
• How would someone deploying this code know if something is going horribly wrong? We keep an eye on log messages and 503s and the like—is that sufficient?
• What's the revert plan look like if something goes awry? Normal rollback ok? Or are there other considerations (changes to serialized objects between versions is the main thing I note that seems to bite us—but a disagreement between what's persisted and what's in the code is where problems arise)?

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

In T355882#9491485, @thcipriani wrote:

Hey! Thanks for thinking of the train folks :)

It sounds like this code will be riding the train this quarter. I know very little about the code and the risks here, so it's tricky to give you a direct answer about my level of concern.

As a starting point could you tell me a little more:

• How are you planning to roll this out? Sounds like code will be riding train and you're planning for an extended period on testwikis (via config...somewhere?) tell me more.

The plan is to deploy to:

1. testwiki (with loginwiki and metawiki as supporting actors)
2. pilot wikis (some weeks after testwiki rollout)
3. rollout to rest of the WMF managed wikis over a duration yet-to-be-determined

The important line in the config is $wgAutoCreateTempUser['enabled'] = true;. If you look in CommonSettings-labs.php you'll see a couple of other related settings. But that is the global switch.

• How would someone deploying this code know if something is going horribly wrong? We keep an eye on log messages and 503s and the like—is that sufficient?

Yes, I think that would suffice.

• What's the revert plan look like if something goes awry? Normal rollback ok? Or are there other considerations (changes to serialized objects between versions is the main thing I note that seems to bite us—but a disagreement between what's persisted and what's in the code is where problems arise)?

A normal rollback of the config would be fine. However, there is a special consideration, in that once temporary accounts have been created on the wiki, and the global feature flag is switched off, we need a way to make sure that those users are logged-out, and continue to appear as temporary users. We're discussing that in T356524: Ensure temp accounts can be safely disabled after being enabled.

Most of these questions are in our Risky Change Template. The week something risky is going out, it's a nice template to use to give us a heads up, most of the time that suffices. This change seems pretty fundamental, so we might need more. But let's start with there and see.

That sounds good.

Overall, I think the important thing for Release Engineering and specifically train drivers to know would be, after testwiki rollout:

• testwiki would reflect an editing paradigm (temporary accounts) that is *not* the same as all other wikis. So, during that time it would probably make sense to review logs from other group0 wikis more closely. And WMF teams should probably do any anonymous editing related QA on test2.wikipedia.org

@thcipriani https://www.mediawiki.org/wiki/Help:Temporary_accounts/How_it_works is also a useful reference, that is probably a good idea for RelEng folks to read before we enable this on testwiki.

Adding Quality-and-Test-Engineering-Team as well, cc @Jrbranaa

Summary of meeting notes:

• We'll provide documentation on how to switch off the feature (T356524)
• No major concerns from Release Engineering about enabling this on testwiki from a release train perspective

As such, I think we can resolve this task. (cc @TAdeleye_WMF @Tchanders)

Sounds good to me. Thanks @kostajh