Change 763369 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Add tests modelling behaviour for existing skin default.

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

I've captured the requirements that @ovasileva gave me in the tests above.
In terms of making these tests pass, I think this should be possibly using UserGetDefaultOptions or LoadUserOptions hook and checking the user object and the current values.

However, I should note there is a contradiction here on the original request (it undos the acceptance criteria " Configuration has no effect on users who have set a skin version preference." of T251415).

The documentation for the existing configuration states that this value is "The version ('2' for latest, '1' for legacy) of the Vector skin to use when an existing user has not specified a preference. This configuration is not used for new accounts (see VectorDefaultSkinVersionForNewAccounts) and is impermanent"

However, when a user saves a preference they are specifying a preference...

I think we can capture the desired behavior if wanted, but I should note in doing so we will be changing the meaning of this preference from "when a user has not specified a preference" to "when a user is using the defaults ".

To describe what this means in simple turns:

• If I currently select Vector on English Wikipedia, I am not selecting Vector but I am specifying that I want the "default logged in skin" whatever that is. That means if the defaults ever change my preferences change with it.
• If I currently select Vector 2022 on French Wikipedia, I am not selecting Vector 2022 but I am specifying that I want the "default skin". This means that if the

In the previous setup, if I opted into Vector 2022 and then opted out into Vector skin, I would be permenantely in the Vector skin, unaffected by any defaults. In the new setup I can be thrown back into the Vector 2022 at any time, based on what the web team decides.

Change 763369 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] Add tests modelling behaviour for existing skin default.

Reason:

Please fork when you are ready to work on making these tests pass.

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

@ovasileva just checking in here, as presumably this is a blocker for deployment and we need to start thinking about this now if we're going to do that.

I'm pretty sure this is basically ancient T22553: User "Default Skin" preference which I also arrived at in T180860#6254253. (Only found this today due to the discussion in Discord continuing after everyone but @sgrabarczuk went to lunch.)

@ovasileva given the deployment plan for English Wikipedia it seems like this should be declined?

In T300919#8513740, @Jdlrobson wrote:

@ovasileva given the deployment plan for English Wikipedia it seems like this should be declined?

Leaving open for now as we might need it for other Wikipedias

Would it be possible to convert this into a spike?

Change 891925 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] [WIP] Allow different skin for anonymous and logged in users.

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

@Ladsgroup as a heads up - depending on the outcome of the English Wikipedia RFC it's possible we may need to introduce a configuration flag that allows a different default skin for anonymous users to logged in users. We're not sure what that looks like, but I'm currently trying to work out how technically we might achieve that.

My personal preference involve a code change - it would be a maintenance script. I think if we did that, we'd want to coordinate that with you since that would require a lot of database writes in a short period of time using the exisiting userOptions maintenance script.

Alternatively, we can add a configuration variable specifically to allow a different skin for anonymous users. I've tried to demonstrate roughly what that would look like in my WIP patch (https://gerrit.wikimedia.org/r/891925). I don't think it would change anything regarding total number of database rows, but I believe it would lead to similar activity we saw during the roll out with more database writes (particularly since many users may want to opt back into Vector 2022 skin).

We'll likely reach out to you in the next 2 weeks to talk about this more. Do you think anyone else should be involved in such a conversation?

Just that I saw the comment and I'm planning to respond ASAP. It's just a bit hectic today.

So running the maint script to set the skin would break things. user_options table is pretty big (and non-normalized making it overly big but I don't expect it to be fixed now). There is a lot of overlapping concern and discussion in T54777: user_properties table bloat and I think the Tim's suggestion in T54777#7724456 would actually address your concerns here.

Note that I'll be ooo between March 3-27. We can have a discussion this week if it's urgent.

To be more explicit: T321527: Support conditional defaults for user properties

So running the maint script to set the skin would break things

Could you expand on this @Ladsgroup - what exactly would it break?

I think the Tim's suggestion in T54777#7724456 would actually address your concerns here.

Yes, that actually sounds like a more generalized solution then T300919. I'm going to ask some questions there to see if I can understand it better.

In T300919#8654004, @Jdlrobson wrote:

So running the maint script to set the skin would break things

Could you expand on this @Ladsgroup - what exactly would it break?

user_properties table is one of the biggest tables in mw atm because it's not well designed (repeats strings literally millions of times). And unlike other pretty large tables such as externallinks or pagelinks, it's "hot" which means it should be read from memory as much as possible (it's called innodb buffer pool in our infra) and that has a limited capacity. Adding millions of more rows to it can at least in paper double that table's size, make it read more from disks -> general slow down -> high risk of outage.

T321527 would avoid adding many more rows + the property name should be normalized (that's not a blocker here but should be done regardless)

Change 891925 abandoned by Jdlrobson:

[mediawiki/core@master] [WIP] Allow different skin for anonymous and logged in users.

Reason:

Proof of concept. Will circle back to this later if needed.

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

I would rather avoid doing this if we can, and it's not clear if we need it, so doesn't seem ready to estimate.