Talk:Separating skins from core MediaWiki

Jon's comments
I am agnostic to whether all skins should be moved out of core (and to whether MediaWiki should ship with a default skin), but I think the fact that skins live in core leads to bad practices. Going through the process of moving CologneBlue and Modern out of core I am shocked about how much rebasing I have had to do. The fact that we are making changes to CologneBlue and Modern in 2014 seems broken - our skins should be much more resilient to change and it should be possible to leave a skin untouched without it breaking.

You claim that you will not be "rewriting the Skin and SkinTemplate classes." although I really think you should be more ambitious and should revisit this idea. I think you have a good chance here at making our skin infrastructure less a mess. Ideally a skin should just be given a bunch of data e.g. the history url, the talk page url, the sections, the section edit link urls, the text of the page, the page title that it can create HTML markup for and apply a skin to e.g. take a lot of logic out of the skin itself. If we can get to a goal where skin designers only have to think in terms of HTML and CSS I think this is a wonderful place to be.

Also I wonder if somehow your work here could fold nicely into this other proposal - User:Jack_Phoenix/A_modern,_scalable_and_attractive_skin_for_MediaWiki_(GSoC_2014_proposal) - maybe Jack's new skin could be built and aid the decisions of the new skin infrastructure built out by you?

I'd be interested in mentoring this, if what I am saying above is of interest and inline with where you think we should take the skin system. Also note, by the start of this project there will be only 2 skins in core - Monobook and Vector. I'd suggest you limit yourself to refactoring these, whilst maintaining backwards compatibility for the older skins. Jdlrobson (talk) 18:47, 21 March 2014 (UTC)
 * Yeah, CologneBlue is a little… special. :( Changes like the one you linked should not be necessary for better-done skins.
 * Having a simpler, cleaned up skin system is a tempting prospect, but a) it limits skin developers a bit (which might be often a good thing, but if our current system was like that, it'd make projects like Jack's skin proposal all but impossible), so we might want to do it in addition to the current one and b) would be a rather large undertaking by itself, assuming you'd want to do it properly and consult everyone interested (an RFC would probably be in order). Given that changes like these usually either move at glacial pace or end up annoying a lot of people, I'd rather limit the scope of this project. (But I am nevertheless interested in working on that some day, or even if parallel if I have the time – it looks like plugging external template engines into SkinTemplate is doable even now.)
 * Jack and I have already chatted about this briefly, and we could probably work together to settle on the way to do skins (it looks like we agree on the important points already), have Jack's skin done in that particular way, and possibly get it bundled in the tarball in the end (if the tarballing-related part of my proposal works out).
 * I'd appreciate if you could mentor this project, especially since we seem to agree on a lot of things here :) I commented on your CologneBlue and Modern changes, I'm prepared for both possibilities (their staying in core for now or getting moved out) and I'll probably want to bring them both up to par in both cases. Matma Rex (talk) 12:35, 24 March 2014 (UTC)

Mentors
Looking this proposal in Google Melange, I still see no mentors assigned. One mentor is required to consider any proposal (, please "Wish to mentor" if you wish to mentor). Two mentors are expected for a project like this that requires changes in MediaWiki Core. At least and  are going to have strong opinions about this plan and its patches. One of them (or someone they designate) should be officially in, regardless of the informal support that other +2 contributors might provide. PS: also, I would feel better about this proposal if there would be an explicit acknowledge from the related maintainers. MatmaRex is one of the maintainers, but still. I'd rather don't rely on assumptions now, only to see how patches get stuck in Gerrit discussions when it comes the time to push them to Core.--Qgil (talk) 17:23, 26 March 2014 (UTC)