I am still sort of kind of maintaining them both (you'll notice that I joined both of their projects). No one seems to be filing any bugs though. I tried to help the Echo team a bit with their recent problems (I think I managed to merge a patch), but mostly they solved them swiftly enough without me.

In T115430#1724958, @matmarex wrote:

I am still sort of kind of maintaining them both

Does that make this task a WONTFIX/declined?

In T115430#1725610, @Jdlrobson wrote:

We are either aspiring to have a skin system that doesn't need maintaining or minimal maintaining (which can be achieved by having lots of skin choices deployed)

Is T114071: Let's discuss the skin creation process at Wikimedia-Developer-Summit-2016 related?

or to simply support Vector/Minerva (mobile skin).
In practice it seems to be the latter but it would be good to have clarity.

Where to have this discussion and who to drive it?

when we killed five of the then-nine extensions available on the site

Do we have an assessment of what we gained with that operation, in hindsight?

In T115430#1724958, @matmarex wrote:

I am still sort of kind of maintaining them both

Does that make this task a WONTFIX/declined?

In T115430#1725610, @Jdlrobson wrote:

We are either aspiring to have a skin system that doesn't need maintaining or minimal maintaining (which can be achieved by having lots of skin choices deployed)

Is T114071: Let's discuss the skin creation process at Wikimedia-Developer-Summit-2016 related?

or to simply support Vector/Minerva (mobile skin).
In practice it seems to be the latter but it would be good to have clarity.

Where to have this discussion and who to drive it?

Shouldn't new features work with every skin (In theory?), skins shouldn't have to be modified to work with new features (In principle).

In T115430#1724958, @matmarex wrote:

I am still sort of kind of maintaining them both (you'll notice that I joined both of their projects). No one seems to be filing any bugs though. I tried to help the Echo team a bit with their recent problems (I think I managed to merge a patch), but mostly they solved them swiftly enough without me.

@matmarex: Would you mind if I updated https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_skins_deployed_on_the_Wikimedia_Cluster to reflect that?

Go ahead, I'm still volunteering to maintain them.

In T115430#2069739, @Bawolff wrote:

Shouldn't new features work with every skin (In theory?), skins shouldn't have to be modified to work with new features (In principle).

That's not the development policy, no. MediaWiki's disaster-zone of skin support means it's unachievable, sadly. Scrapping the skins system and replacing it with a much-less-powerful theming concept could allow it, but no-one seems to have the appetite for that.

Given its not even possible to set your skin to cologneblue or modern in Special:Preferences without using a secret url parameter, I don't see much point in keeping these skins deployed.

11 patches during the past year indicates to me that CologneBlue is extremely stable. This is a very small number. I am struggling to find a single extension deployed on Wikimedia sites that has had fewer than that. (I found one tie: by my count the SiteMatrix extension, which implements a single special page and a single API module that haven't really changed in the past 15 years, also has had 11 non-bot patches last year. Other extensions that I thought would be trivial and requiring almost no maintenance have had more, e.g. Babel, InputBox, WikiHiero.)

I was involved in more than half of these 11 patches (either as author or reviewer) and I enjoyed working on them.

CologneBlue has just 16 localisation messages, and it is not prioritized for translation. It's not a part of the "MediaWiki (most important messages)" message group. You have to go out of your way and browse to MediaWiki → MediaWiki skins → Cologne Blue to translate it, and there are 44 other skins alongside it. I would expect that anyone who has translated it recently also did that only because they enjoyed doing it.

The last security vulnerability in CologneBlue was found in 2020 (T267278) and it was only exploitable by a rogue administrator; we haven't really considered that a security issue until a few years ago. In the same timeframe, legacy Vector has had at least 3 security problems of comparable severity. There may have been more, but it's hard to search for them, since "vector" is a common word in the context of web security (as in "attack vector"), and hard to distinguish them from modern Vector, which has had its share.

In short, I am not convinced.

In T115430#10341646, @matmarex wrote:

11 patches during the past year indicates to me that CologneBlue is extremely stable. This is a very small number. I am struggling to find a single extension deployed on Wikimedia sites that has had fewer than that. (I found one tie: by my count the SiteMatrix extension, which implements a single special page and a single API module that haven't really changed in the past 15 years, also has had 11 non-bot patches last year. Other extensions that I thought would be trivial and requiring almost no maintenance have had more, e.g. Babel, InputBox, WikiHiero.)

Skins still rely on mediawiki core and mediawiki core changes. Needing to update all extensions deployed in production slows down changes in core, slowing down new features or refactors for everyone.

I was involved in more than half of these 11 patches (either as author or reviewer) and I enjoyed working on them.

you did but one volunteer fixing one of the issues there explicitly asked me "why don't we undeploy this?" Because they were fixing issues among all deployed code and this was among them.

CologneBlue has just 16 localisation messages, and it is not prioritized for translation. It's not a part of the "MediaWiki (most important messages)" message group. You have to go out of your way and browse to MediaWiki → MediaWiki skins → Cologne Blue to translate it, and there are 44 other skins alongside it. I would expect that anyone who has translated it recently also did that only because they enjoyed doing it.

It is in MediaWiki group still and people translate that group as a whole. Not necessarily because they enjoy it and even if they do, that's not a reason to keep software in production.

The last security vulnerability in CologneBlue was found in 2020 (T267278) and it was only exploitable by a rogue administrator; we haven't really considered that a security issue until a few years ago. In the same timeframe, legacy Vector has had at least 3 security problems of comparable severity. There may have been more, but it's hard to search for them, since "vector" is a common word in the context of web security (as in "attack vector"), and hard to distinguish them from modern Vector, which has had its share.

That's still one too many. Even if vector would have let's say 9 security issues, 9 security issues is better than 10. Since any security issue in any skin can be weaponized to attack anyone.

Also there is a cost-benefit there. Vector is used by hundreds of millions of users every month, CologneBlue is used by around 100 users in enwiki, if you even go with an extremely high number of total 1000 users, that's still a significant cost for a extremely small benefit. (0.25 security issue/year to serve 1000 users = 0.00025 security issue per year per user vs. 0.75/100,000,000 (at least))

From a security risk, I would be more worried about Timeless than CologneBlue or Modern given the amount of lines of code it has.
I agree that skins that are not Monobook, Minerva, Vector and Vector 2022 have very small audiences and we shouldn't be spending development time on them.

Opportunity cost, the time and energy spent on maintaining these skins could have been spent on other parts of our infra.

I think this is key here. I can give a few examples that at least impact me / my team:

• Right now our deprecation process requires no hard deprecations until all skins in production have been patched. If I am honest, I have not deprecated code (or put off deprecation) in the past because I didn't want to have to update 6 skins + 2 hidden skins to not emit deprecation warnings (e.g. T377521). Having less skins in production in theory would allow us to be more radical with improvements in the skin system and improve skins that people actually use. It would also allow us to handle deprecation updates with less urgency.
• Echo's UI is in a dire need of a rewrite but it's made more cumbersome by skin-specific customizations. It often breaks somewhere anytime we make major changes to UI in Vector 2022.
• We have blocked the train in the past for bugs in 3rd party skins like Timeless relating to UI (e.g. T293960). I don't think this should ever happen given the size of the audiences there. This can delay roll out of important features that most of our users use.
• We get bug reports like https://phabricator.wikimedia.org/T381415 which would be easier to handle if there were fewer skins to care about.

Other approaches to consider if not removing them:

• Disable features on these old skins, particularly anything that makes use of skinStyles. I have no idea why Echo needs to render in Modern as an overla for example and not just be a link to Special:Notifications. This is already happening to some extent and would be made easier by more mature configuration such as T360452. These skins should be as basic as possible.
• If we want to keep these skins, it would be great if errors/warnings from them were not counted as production errors so issues with them can be handled with less urgency.

In T115430#10401445, @Jdlrobson-WMF wrote:

We get bug reports like https://phabricator.wikimedia.org/T381415 which would be easier to handle if there were fewer skins to care about.

I do not disagree with the majority of your comment, since on-wiki developers also have to support more skins (in gadgets, user scripts, template styles etc.) than it is frankly needed, but this I would like to take an issue with. Solving bug report like T381415 is not complicated by the amount of skins, it is complicated by a lack of tangible action. In general, WMF has a very double-sided approach to skinning: we have too many skins to support, but those skins that are there do not get any support at all if they aren’t default in English Wikipedia or other projects that can complain loudly enough about the introduced regressions. Over the course of development of Vector 2022, there were around 10-15 bugs that were introduced to other much more used skins because of something that needed fixing in Vector 2022. As T381415 shows, they are still being introduced and then everyone takes much time fixing them. If we need to retire certain skins due to low usage, that approach needs to change first.

In T115430#10401445, @Jdlrobson-WMF wrote:

Opportunity cost, the time and energy spent on maintaining these skins could have been spent on other parts of our infra.

I think this is key here. I can give a few examples that at least impact me / my team:

• Right now our deprecation process requires no hard deprecations until all skins in production have been patched. If I am honest, I have not deprecated code (or put off deprecation) in the past because I didn't want to have to update 6 skins + 2 hidden skins to not emit deprecation warnings (e.g. T377521). Having less skins in production in theory would allow us to be more radical with improvements in the skin system and improve skins that people actually use. It would also allow us to handle deprecation updates with less urgency.
• …
• We get bug reports like T381415 which would be easier to handle if there were fewer skins to care about.

One of the goals of my work on MediaWiki skins, back in 2014, was to put third-party skin developers on equal footing with WMF developers. For better or worse, you get to feel the pain of the deprecation treadmill as much as anyone else now…

I don't think that removing skins is a good solution for the MediaWiki ecosystem. Rather we should be smarter about what we're deprecating, and avoid making unplanned breaking changes like T381415, to avoid creating this work for ourselves and everyone else.

One of the goals of my work on MediaWiki skins, back in 2014, was to put third-party skin developers on equal footing with WMF developers. For better or worse, you get to feel the pain of the deprecation treadmill as much as anyone else now…

Sure, and as someone who pushes the majority of the patches to 3rd parties I am very much in support of this. I am sorry if my post came across differently.

However, there is a difference between submitting patches across the course of a release and submitting patches in the space of a week for a train deployment. I'd rather not have to patch Timeless, Modern, CologneBlue, Vector, Vector 2022, Monobook, Minerva, WikimediaApiPortal, ContentTranslationSkin in the space of a week every time we do a deprecation. Particularly when some deprecations are not as trivial as changing a function name. Ideally skins like CologneBlue and Modern can be patched at a later date (and also allows us to check deprecation warnings are working as expected for skins that are not running in production).

You mention T381415 but I see that as a bug in Codex and unrelated to skins. The codex link mixin should be using @color-link, not @color-progressive. Having these skins in production helps us identify these bugs earlier, but having less skins in production doesn't make much difference other than meaning more skins to patch prior to a deployment.