Change 620014 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Remove misbehaving config migration code

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

Remove bogus code. This does not change anything. It will only have an effect when the feature goes out of Beta on another wiki.

This migration currently is having an effect, it's a rolling change which is continually opting out users on our small default wikis. We're opting out roughly 350 people per day, because of predominantly bad beta preferences.

I would say, we should make this a must-have for remediation (I'll boldly edit the task description, feel free to revert).

More good news: I think we have an accurate technique for undoing exactly the migrated full opt-outs! There's no way to manually remove the beta opt-out, so whenever it gets deleted we know that a migration happened. If the user toggled to full opt-out within a short time window (a few seconds) of removing the beta opt-out, we know that the migration was triggered and this is an erroneous opt-out.

I can explore this possibility by doing some processing of user preferences history.

It's not clear what to do with this potential list of known-migrated users, we'll have to discuss again. We still face the question of whether the user intentionally opted out of the beta feature or not. What we can say with confidence is that any full-feature opted-out users not on this list did intentionally opt out and we shouldn't include them in a "bulk forgiveness" action in the future.

After discussing, we realized that the impact of the migration is much larger than we thought. All beta opt-out users will also be opted out of the full feature, and we're only seeing a tiny fraction of this group convert to a database "full" record because that only happens when visiting the preferences page. This causes us to lean more towards leaving the migration in place for the moment, so that we can appropriately communicate with the users ahead of time.

Another update: a filter was added to the property audit log as of Aug 4th. Beyond that date, we will no longer have a record of twocolconflict* preference changes. If we want to get audit logging again, we must add the preferences to WikimediaEvents PrefUpdateInstrumentation.php.

Change 621535 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/WikimediaEvents@master] Track TwoColConflict migration preferences

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

Change 621535 abandoned by Awight:
[mediawiki/extensions/WikimediaEvents@master] Track TwoColConflict migration preferences

Reason:
This turns out to not do what I had hoped. I would also need a record of a beta preference which doesn't appear on the page, but this will never be part of the input to the hook.

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

A final note about the preference audit logging: It doesn't contain all of the information we would have needed, we can't actually reconstruct who was migrated. A migration done during an unrelated preferences change causes no logging at all. I tried most combinations of values locally, read through the logged values on production, and there's no case in which we can see the migration unambiguously.

For unknown reasons, the beta preference occasionally appears in audit logging even on wikis where the feature is default, which seems buggy. Sometimes both the full and beta preferences are toggled to true at the same time. This doesn't really matter to us, it's just a strange artifact.

Change 620014 abandoned by Thiemo Kreuz (WMDE):

[mediawiki/extensions/TwoColConflict@master] Remove remaining opt-out migration code

Reason:

Easier to redo when needed.

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