Tagging this for Readers Web as they might want to weigh in (it's mostly their support work, after all).

This should not just be about skins but also about extensions. In either case I basically only see two markers: Supported by WMF and Not supported by WMF however this would be called in the end. More fine-graned markers would need a continuous assessment I do not see will happen, neither for skins nor for extensions. Even when looking at extensions supported by WMF there are some which only get critical fixes. So this does not help much since we are still up for interpretation about every piece of software. As much as I would love to see something like this become reality I do not see how.

cc @Nirzar and @ovasileva

From a technical perspective, I'm not sure what the goal would be. If a skin is available in the preferences the user should expect it to be of a certain standard. If it's experimental it should probably be in the gadgets panel e.g. "Enable unsupported skins". The average user should not be expected to comprehend that a skin that looks nice might have bugs. It should just work. All code should be assumed to have bugs and if the bugs are serious it shouldn't be made an option.

Thus, as a practical matter, people using a volunteer-supported skin may encounter more skin-related bugs,

I'm not sure this is true or fair. I think we hold all code contributors to an equal standard.

especially if something in MediaWiki changes suddenly, before the volunteer dev is aware of the change/back from holiday/has time to update its code.

If this happens then whoever is making those MediaWiki changes should probably be asked why they are introducing bugs to the production ecosystem. If this is happening I'd also expect ReleaseEngineering to appear with a big stick.

Generally when reading web build things now, we provide mechanisms to disable features on skins we do not support. For example the RelatedArticles extension maintains a skin whitelist: https://github.com/wikimedia/mediawiki-extensions-RelatedArticles/blob/master/extension.json#L165 to avoid enabling the feature on a skin we do not support. It would be good to standardise this in some way, as increasingly we are seeing compatibility problems between skins and new feature and this doesn't seem like a good pattern.

From the end-user perspective, disabling features in certain skins is the same thing as a skin-related bug. Imagine that I hear about a cool new feature, and enable it. But it's not there, because I'm using the "wrong" skin. From my point of view, that's a "bug": I enabled a feature that didn't work.

<s>BTW, Related Pages worked just fine for me at the Haitian Wikipedia on Vector last year, but now it's disappeared (and I'd like it back, please).</s> (Never mind, it's working today. Maybe I just didn't wait long enough for it to load yesterday.)

Should the "Skin" section of Special:Preferences#mw-prefsection-rendering contain a note about support levels?

For consistency, I wonder if that's already the case in other areas. When installing and choosing the MSSQL backend, is there any note about its support level?

We already have beta features.
If a <skin/functionality/extension/insert-other-word-here> isn't 'mature/maintained enough [anymore?]', I'd expect it to be under "beta".
Nothing specific about skins here IMHO and no need for a skin-specific solution.
The problem is agreeing on a definition of 'mature/maintained enough', of course.

Related (but for MW extensions only): T173544: High quality extension levels tagging

Similar suggestion in [excerpt]

In T154371#3780692, @Billinghurst wrote:

I was meaning an inline information where it currently appears that identifies it as beta. If there is scope to add leads to information about the skin, its trial, and where feedback is welcomed. At the moment there is simply no context to the skin, it has appeared as a new skin with the same level of importance and permanence as others.

@ovasileva wondering if we have any thoughts around this, given by the end of desktop imporvements we'll be changing the support level for legacy Vector.

Our current approach is to hide skins to new users in Special:Preferences that we don't actively support. I don't think it makes sense to distinguish between volunteer and WMF skins. From a users point of view they shouldn't need to know how we make skins. That would be incredibly confusing.

Ideally, we would use Html::warningBox to show a message on https://en.wikipedia.org/wiki/Special:Preferences?useskin=modern telling users they are using an unsupported skin. I'd accept a patch for that, but I don't think we need to do anything beyond that. That could be done inside Special:Preferences page.

If communities want to mark skins in some way, they are also free to override MediaWIki:skinname-timeless to display differently e.g. Timeless (volunteer skin)

I currently see these four skin options in prefs at enwiki:

• Vector
• MinervaNeue
• MonoBook
• Timeless

Work-me happens to know that 50% of these skins are officially supported by the WMF and 50% of these skins are not. As an end user, how am I supposed to discover that MonoBook and Timeless are unsupported?

Not "supported by WMF" does not necessarily mean "unsupported". Other entities and volunteers exist.
How and why is it relevant for me as an end user to know?

In T178422#7492229, @Aklapper wrote:

Not "supported by WMF" does not necessarily mean "unsupported". Other entities and volunteers exist.
How and why is it relevant for me as an end user to know?

I would suggest that it is useful information, because if I -- as a user who is looking at preferences, and potentially altering many defaults -- encounter problems with one of my changes, then I might try changing my skin if I had noticed that some were more supported than others.

I really like the diversity of skins we offer (and I wish we could easily/feasibly have many more, as some websites do), but I am also aware that not many people (potentially only just 1 or 2 people) are looking at bugs & feature-requests related to the non-official skins; partially per personal-familiarity, partially via the table at mw:Developers/Maintainers#...skins...