I'm glad that Timeless will be bundled. I'd also like to consider bundling Chameleon, which is used on many third-party MediaWiki sites. Are there other skins that should be considered?

Makes sense, if it works.

I'd also recommend perhaps just going through all the ones we maintain in gerrit and seeing what seems reasonable of the lot, as there's currently not very many of them, and even fewer which are fully usable (sufficiently implemented, not made for a very specific single purpose, etc). Referencing https://wikiapiary.com/wiki/Skin:Skins gives an idea of existing usage, though it's going to be highly skewed toward skins deployed to wikifarms as well as just older skins, especially if they've been more advertised.

Given that none of the current ones besides minerva and now timeless support mobile (vector and monobook are partway there, but vector's option isn't entirely usable, and monobook's isn't even merged), though, you may also want to consider prioritising any that include built-in mobile support in particular - if we're talking for 1.31, I know GreyStuff also does currently, but there are likely others too now, as there's been something of a push to actually start doing this of late. And for 1.32 and onward, expect there to be more.

Chameleon is built on Bootstrap 3 and supports mobile.

Yes, I have gone through the ones listed on WikiApiary, and no others jumped out at me, but I could easily be missing one that others are familiar with.

Try doing it the other way around - just because something is in gerrit and might be a viable option does not mean people necessarily know about it, which is what wikiapiary is about - whether or not they're known. And the whole point of putting options in the installer is so that people realise there are options and actually have them with immediacy.

And I mean you might check if Chameleon would actually work with the installer, meet the general requirements here, etc. I haven't checked specifically, but the installation process was a tad... strange, as I recall. If that can be simplified in general it'd be useful even outside the installer.

Agreed. I have looked in gerrit as well. I'm just saying that I'm open to hearing from others who have had success with other skins that I do not have familiarity with.

Yes, Chameleon is normally installed with composer. That's a whole other conversation. It would have to be checked to see if it would work with the installer. Further, I don't recall if there's a default layout configuration or whether one needs to do that manually, which would be a showstopper. And, if we're going to go through the same process as with the extensions, it would need other checks, like a security and license review, etc.

In T178349#4187601, @CCicalese_WMF wrote:

Yes, Chameleon is normally installed with composer. That's a whole other conversation. It would have to be checked to see if it would work with the installer.

It's not an installer problem, it's a build problem. The script probably won't handle it nicely (my assumption, without having tried obviously)

Further, I don't recall if there's a default layout configuration or whether one needs to do that manually, which would be a showstopper.

Yes.

And, if we're going to go through the same process as with the extensions, it would need other checks, like a security and license review, etc.

Also this.

I think it's best if we skip Chameleon this round.

Okay, of skins I've worked with that might be worth looking into:

• BlueSky: Wouldn't necessarily recommend at present; I rewrote it two years ago and never finished putting all the features back, so it's kind of... barebones? Technically mostly works, but no mobile support yet, no themes (originally came with a bunch of different colour options for site admins to choose), etc. Once back to original feature set, should absolutely be included.
• GreyStuff: Probably pretty solid, with mobile support and a simple look. Probably needs a go over for some of the interface message parsing to make sure it's actually using methods that make sense, as it's an old monobook fork, so there could be some security issues there.
• HasSomeColours: is not even the right skin. I don't know what's going on there. My brain just... decided it should exist a couple days ago.
• Metrolook: A vector derivative not unlike some of the chameleon variants. Apparently pretty popular.
• Refreshed: Brickipedia skin, has mobile support, but kind of weird to install.
• Splash: Skin I made for my personal wiki that turned out to be surprisingly popular among wikis with more fantasy themes. Lacks mobile support and built-in configurability, though.
• Wordpress conversions: Bouquet, DeskMessMirrored, Dusk, DuskToDawn - simple things, but might be useful for folks who want blog-like setups to have something like these? Dunno.

Basically Timeless and Minerva Neue are the only ones that should have already had the reviews to just drop in, which I guess explains why... they were.

In T178349#4188521, @Isarra wrote:

Okay, of skins I've worked with that might be worth looking into:

• GreyStuff: Probably pretty solid, with mobile support and a simple look. Probably needs a go over for some of the interface message parsing to make sure it's actually using methods that make sense, as it's an old monobook fork, so there could be some security issues there.

I don't think there are any gaping security vulnerabilities lurking in there. The code seems to be using Html methods sanely. There are some unrelated things which could be improved, e.g. combining the two addModules calls into one in SkinGreyStuff#initPage, using short array syntax in SkinGreyStuff#setupSkinUserCss, replacing Sanitizer#escapeId calls in the GreyStuffTemplate class with whatever is the modern/present-day equivalent for that method as IIRC it was deprecated in MW 1.30...but security vulnerabilities? I don't think there are any more security vulnerabilities than what there are generally associated with the admin ability to edit interface messages (e.g. MediaWiki:Common.js etc.). (Note that this is not an official security review by any means, I merely glanced over the code instead of carefully examining every method and testing it out to make sure everything's safe.)

• Refreshed: Brickipedia skin, has mobile support, but kind of weird to install.

Refreshed uses the (nowadays archived and unsupported) WikiFont for icons in a few places. This means that when cloning the skin from git, you need to initialize the WikiFont submodule with the right command or the skin will look utterly broken. When not using git, the installation steps are described on the skin's info page on MW.org. The task about switching Refreshed to use OOJS icons instead of WikiFont is T155083.

• Splash: Skin I made for my personal wiki that turned out to be surprisingly popular among wikis with more fantasy themes. Lacks mobile support and built-in configurability, though.

Mobile support is presumably a feature users will essentially expect to simply "be there", given that some sites have more mobile traffic than desktop traffic these days. Can you elaborate on the "lacks [--] built-in configurability" part, though? According to the info page there are a bunch of interface messages end-users (well, more like end-sysadmins) can edit to configure various skin features; and looking into the codebase I see a rather familiar parseItem method in the SplashTemplate class... ;-)

• Wordpress conversions: Bouquet, DeskMessMirrored, Dusk, DuskToDawn - simple things, but might be useful for folks who want blog-like setups to have something like these? Dunno.

And let's not forget Gamepress, which is responsive and supports multiple themes!
There's also the mobile-first/mobile-"only" skin called WPtouch, but I'm guessing most people would pick Minerva over that skin.

Of the various skins I've worked with, here are some of my suggestions:

• Liberty (live example) -- Bootstrap-based skin not maintained on gerrit which lacks a MediaWiki.org info page (!), but is nowadays i18n-compatible, configurable and ad-ready. Probably not yet fully suited for wider deployment but more eyes on the codebase certainly wouldn't hurt.
• Nimbus -- a skin originally designed for Halopedia, it's designed to work seamlessly with social tools but it works well without them. A notable feature of this skin is the nested sidebar menu, similar to that found on the Monaco skin. There's some ShoutWiki branding in the skin, though, and removing that will probably take a bit of effort. Not responsive either, since this skin, too, wasn't written yesterday.
• Truglass -- literally probably a decade old but still maintained and used. Modern/MonoBook-esque, but sadly not responsive either.

The Social Tools Development Wiki has most of these skins and more available for testing.

However, in addition to skins, I'd like to note about the existence of the Theme extension as well as the task to merge it into core (T122924). The PHP part of the Theme extension is relatively simple, and the extension allows sysadmins to easily customize the visual look of a wiki with a configuration setting ($wgDefaultTheme) instead of requiring (on-wiki) admins to copy-paste lots and lots of CSS. You could even say that the Theme extension allows turning one skin (e.g. MonoBook or Vector) into multiple "skins", as Dark MonoBook looks quite different from the default MonoBook theme, but then again so does Pink MonoBook. Furthermore themes themselves are CSS + images (if applicable), which would eventually reduce the need for security reviews, which is a must for skins as skins have PHP parts, sometimes even significant portions of a skin are written in PHP (such as a sidebar menu parser, for example). Of course this would indeed mean that Theme needs a security review, but that'll hopefully be needed only once as the PHP portion of the Theme extension is quite stable and I don't see it changing drastically in the future.

So, this is all a great discussion to have, but I'd like to punt the decisions to made to 1.32. We're already adding a lot of new stuff in this release, and I don't want to hold up a release over potential blockers.

Sounds good - and now we should have both a better basis for the currently included new ones (that the necessary work is already done, and they're the only two that goes for), as well as a better idea where to begin with this for 1.32.

I created T194266 to continue the discussion and analysis of skins to consider bundling with MW 1.32.

Change 424974 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove lines that are now part of AbuseFilter defaults

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

All direct subtasks are closed. Should this task also be resolved? If not, which specific tasks / criteria are left to sort out?

In T178349#6403798, @Aklapper wrote:

All direct subtasks are closed. Should this task also be resolved? If not, which specific tasks / criteria are left to sort out?

Perhaps T246381: Expand the set of bundled extensions and skins in MediaWiki 1.36 and then eventually the tasks for 1.37, 1.38, etc. based on previous practice?

Heh, good point, thanks! However I'd like not to have neverending tasks without criteria when they are done, which never get resolved. :)
If this task has been superseded by "Expand the bundled stuff in MW 1.xx" tasks, then this task could and should be closed.

Tracking tasks are by definition neverending, I don't see anything wrong with that. That said, all the "bundle for 1.XX" tasks have largely the same subtasks; some extensions, which are generally agreed to be part of the "default experience" (such as MobileFrontend or Popups or Echo) are difficult enough to bundle that they are pushed back release after release. Maybe it would make more sense for this task to be the direct parent of the extension-specific tasks?

Tasks have a status field. For neverending "tracking tasks" it will always remain "open". Hence they are not valid tasks but should be projects instead.
Also see https://www.mediawiki.org/wiki/Phabricator/Project_management/Tracking_tasks (as "tracking tasks" were mentioned). This very task is not marked as a "tracking task", and it's unclear to me what's supposed to be "tracked" in this task which isn't already better tracked by more specific tasks.

TBH I don't think the whole tracking task => project conversion ever went beyond lip service (just look at https://phabricator.wikimedia.org/search/query/KCc.QVf74ojB/#R ) nor that it would be feasible to take it seriously. Some ex-buzilla-tracking-tasks were better suited to be projects and were converted; most weren't and thus weren't.

Anyway, as this task has open subtasks (thanks for calling to attention that they got lost), it has well defined necessary conditions for closing, so debating whether those conditions are also sufficient (and thus whether it should be called a tracking task or an epic) seems fairly academic to me. I can mark it as a tracking task if someone has that preference.

Yeah, we really should kill this non-task.

Maybe this thread is too old, but as I was redirected here: I think bundling chameleon skin in MW 1.37 (or a later version) would be a good idea since many third party wikis make use of it. https://www.mediawiki.org/wiki/Skin:Chameleon

It is actively developed, it does not need any specialized configuration (it works with MediaWiki:Sidebar). I don't know about other requirements, but MW installations using it have been security-checked, so this should not be a show-stopper.

@Krabina 1.37 is branched tomorrow so you better hurry up if you want to get something into it :)

T279842: Expand the set of bundled extensions and skins in MediaWiki 1.37 is the master task; https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated/Checklist is the closest we have to a tutorial.

(But I'd encourage us closing this as Invalid as it's a project not a task, and probably not worth modelling as both.)