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

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

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.

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

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.

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.

[…] 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?

In T249659#6096443, @thiemowmde wrote:

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