Page MenuHomePhabricator

Migrate beta feature opt-outs
Closed, ResolvedPublic1 Estimated Story Points

Description

Copy over any opt-out beta preferences so these users still have the legacy conflict workflow after deploying TwoColConflict as the new default.

We skipped this migration for the "small default" release, but it needs to be completed before going default on the remaining wikis.

beta preferencenew preferencebehavior
no preferenceopted-in or no preference yetdefault to enabled
no preferenceopted-outdisabled
opted-inopted-in or no preference yetenabled; delete beta preference
opted-inopted-outdisabled; delete beta preference
opted-outopted-in or no preference yetdisabled; set new preference to opt-out; delete beta preference
opted-outopted-outdisabled; delete beta preference

The logic is simple: If a beta opt-out exists, copy that to an opt-out for the new preference, overwriting it. The beta preference is removed to prevent this from happening a second time (for example, after the user opts-in).

Event Timeline

awight created this task.Apr 7 2020, 8:23 PM
Restricted Application added a project: archived--TCB-Team. · View Herald TranscriptApr 7 2020, 8:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

We have decided to migrate the preferences according to the table above.

Lena_WMDE renamed this task from [full default] Decide whether we will migrate opt-in preferences when switching to opt-out to [full default] Migrate opt-in preferences when switching to opt-out.Apr 9 2020, 9:18 AM
Lena_WMDE set the point value for this task to 3.
Lena_WMDE renamed this task from [full default] Migrate opt-in preferences when switching to opt-out to Migrate opt-in preferences when switching to opt-out.Apr 9 2020, 9:23 AM
awight updated the task description. (Show Details)Apr 9 2020, 9:52 AM
awight claimed this task.Apr 16 2020, 8:00 AM
awight moved this task from Sprint Backlog to Doing on the WMDE-QWERTY-Sprint-2020-04-15 board.
awight updated the task description. (Show Details)

Change 589267 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] Use constants for preference keys

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

awight updated the task description. (Show Details)Apr 16 2020, 8:26 AM

Change 589267 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Use constants for preference keys

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

Change 589280 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] Rearrange beta features check

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

Change 589310 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] Internally rename opt-out key

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

Change 589280 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Rearrange beta features check

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

I'm finding some awkwardness:

  • Since we default the new preference to true, there's no way to tell whether the user has explicitly opted-in. Without the null case, we can't safely fall back to the beta feature preference.
  • If we remove the default value of true, then the preference will default to false although the user hasn't explicitly opted-out.

All I can think of is to hook into UserLoadOptions and do the beta preference fallback to calculate a correct default value.

awight updated the task description. (Show Details)Apr 16 2020, 4:00 PM
awight updated the task description. (Show Details)Apr 16 2020, 4:09 PM

Change 589349 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/TwoColConflict@master] [WIP] Respect beta opt-out if present

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

awight updated the task description. (Show Details)Apr 16 2020, 4:23 PM

Change 589310 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Internally rename opt-out key

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

As far as I can tell, technical limitations are going to force a slight change of plans. It's impossible to distinguish a definite opt-in to the new preference, from the absence of any preference (null). This means the fallback logic can't be quite as simple as I'd hoped. My new proposal is below, @Lena_WMDE please let me know if this looks reasonable and I'll go ahead.

beta preferencenew preferencebehavior
no preferenceopted-in or no preference yetdefault to enabled
no preferenceopted-outdisabled
opted-inopted-in or no preference yetenabled; delete beta preference
opted-inopted-outdisabled; delete beta preference
opted-outopted-in or no preference yetdisabled; set new preference to opt-out; delete beta preference
opted-outopted-outdisabled; delete beta preference

The only drawback would be for an infimitesimal edge-case group: people who have opted out of the beta feature, then been defaulted in to the new preferences, then opted-out, and opted-in again (!!!) will suddenly be opted-out after this change--but this group is by definition good at toggling preferences, so I'm not worried.

Now that we have a migration in place, the problem will eventually reduce to only the first two rows, which is trivially always correct.

Thanks @awight ! The edge case group seems minimal, and as you said those people will be familiar with changing their preferences, so happy for you to go ahead.

awight renamed this task from Migrate opt-in preferences when switching to opt-out to Migrate beta feature opt-outs.Apr 22 2020, 9:59 PM
awight updated the task description. (Show Details)
awight changed the point value for this task from 3 to 1.

[…] edge-case group: people who have opted out of the beta feature, then been defaulted in to the new preferences, then opted-out, and opted-in again (!!!) will suddenly be opted-out after this change […]

I'm not sure if the part "then opted-out, and opted-in again (!!!)" is true. I think this edge-case group might be a bit bigger: People who have opted-out of the Beta feature, got the feature re-enabled in our small default deployment, but never did anything about this (for whatever reason, maybe they just didn't notice, maybe they are fine with it now, we don't know).

I think we still need to do it exactly like that. I just want to point this out explicitly: We will disable the feature for some users that have it enabled for more than a month. @Lena_WMDE, can you please approve again?

I'm not sure if the part "then opted-out, and opted-in again (!!!)" is true. I think this edge-case group might be a bit bigger: People who have opted-out of the Beta feature, got the feature re-enabled in our small default deployment, but never did anything about this (for whatever reason, maybe they just didn't notice, maybe they are fine with it now, we don't know).

I think you're right about that, thanks for calling it out.

Change 593485 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Harden swap algorithm against possibly incomplete input

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

Thanks @thiemowmde for making sure we are aware of the implications. I think this is of course not ideal but fine as long as we implement T246103 to show a message on the legacy interface informating the user about the new interface before we migrate the preferences.

Change 589349 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Respect and migrate Beta opt-out if present

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

WMDE-Fisch closed this task as Resolved.May 12 2020, 11:54 AM
WMDE-Fisch moved this task from Demo to Done on the WMDE-QWERTY-Sprint-2020-04-29 board.