I think there are some $wg*EnablePercentage configuration variables like $wgGEMentorshipNewAccountEnablePercentage.
Then, if a newcomer who was assigned to A/B test restores their settings by clicking the "Restore all default settings (in all sections)" link on Special:Preferences, the user would lose the assignment state?
If my guess is right, I don't think it is ideal and it would be confusing users.
Would be my guess right?
Thank you.
Hi @Lens0021, apologies for not seeing this sooner.
The behavior is indeed confusing and this issue has come up for other extensions as well (e.g. T49895 - I think there was a more generic task for it but can't find it now).
The naive expectation would be that "restore defaults" brings your account to the state it was in right after you registered, but actually that state is different for different user accounts (A/B testing is one possible reason for that; there are others), and we (Wikimedia) don't have the storage capacity to snapshot the account's state at registration, so reset will have to use a "canonical default state" that's the same for all users, and not necessarily the same as that specific user's starting state. I guess smaller wikis could store per-user snapshots, but MediaWiki development being largely driven by Wikimedia needs, this is how the preferences system ended up.
There is a proposal at T54777#7724456 which I think might solve this (and will be needed for storage efficiency reasons as well).
The other approach I can think of would be to mark certain user preferences as reset-proof, but 1) reset is useful to bring the account to a known-good state and bugs caused by reset-proof preferences could not be fixed that way; and 2) the preferences codebase is old and not very flexible so I'm not sure how easy that would be.
Or, I guess, a new hook could be added to allow extensions to customize user options reset, but that feels like overkill.
What do you think?
Thank you! I didn't find the task before and I didn't expect the issue is so old. 3.7GB of preference data overwhelms me. Anyway, I'm glad to know it is a known issue.
Or, I guess, a new hook could be added to allow extensions to customize user options reset, but that feels like overkill.
The UserResetAllOptions hook was removed and it is why I've thought about this problem. I didn't understand why the hook was removed but after reading the comments on the tasks, I feel it is not good to store preferences automatically. I've seen the Desktop Improvements project used numeric user ids for A/B testing, so it may be a solution they use.
Thank you for responding me.
Hm, that's a good point. We were planning to look at feature flags based on deterministic hashes for a different reason (we have several of feature flags, and in the last half year expanded from just a small handful of wikis to all Wikipedias, so the storage costs have become nontrivial) but it would also solve the UX problem with preferences reset.
