Architecture meetings/RFC review 2014-06-20

'''18:00 UTC, Friday, 20 June, at.

Topics
Today's topic: revamping MediaWiki's skin systems
 * Trevor Parscal's "Redo skin framework"
 * Bartosz Dziewoński's "Separating skins from core MediaWiki" work, including several patchsets that need review:
 * : SkinTemplate: Move $stylename to Skin and soft-deprecate
 * : Support for enabling skins in the installer
 * : Separate Vector skin from core
 * : Separate MonoBook skin from core
 * : Stop using a suboptimal structure for Vector's variants menu
 * : Stop using a suboptimal structure for Vector's variants menu (cont.)
 * : SpecialVersion: Show 'Skins' and 'Extensions' in separate sections

Summary and logs

 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20 (sumanah, 18:00:18)
 * Today we're talking about revamping MediaWiki's skins systems. I scheduled this before Erik sent out the note http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/077227.html about next week's front-end standardization chat. (sumanah, 18:00:28)
 * FYI, next week we'll have that frontend architecture discussion here in #wikimedia-office 5:30 PM UTC on 25 June. (sumanah, 18:00:53)
 * next week's regular RfC chat on IRC will be about https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes - which has multimedia implications (sumanah, 18:01:27)
 * Bartosz Dziewoński's "Separating skins from core MediaWiki" work, including several patchsets that need review: (sumanah, 18:01:42)
 * LINK: https://bugzilla.wikimedia.org/show_bug.cgi?id=65748 (sumanah, 18:01:56)
 * LINK: https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki (sumanah, 18:02:14)
 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20#Topics - that's where I listed the links to some changesets that need review: (sumanah, 18:02:27)
 * IDEA:  It sounds to me like it is possible for the release managers to release tarballs that include Vector and/or other skins and provide a smooth upgrade experience (sumanah, 18:15:07)
 *  My main comment is that the area you mention in step #1, about client side Skin API, I would like to work together on that, because it's an essential part of what my skin proposal does (sumanah, 18:17:16)
 *  MatmaRex: also, in removing skinStyles, your proposed inversion is interesting, but we need to make sure there's a way for a skin to provide a style for a feature, which prevents the feature from loading it's default style, or we will end up with really ugly CSS overriding hell (sumanah, 18:17:26)
 * discussion of skinStyles - future of promise or future of peril? (sumanah, 18:29:53)


 * Trevor's "Redo skin framework" proposal (sumanah, 18:31:08)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework (sumanah, 18:31:16)
 * https://gerrit.wikimedia.org/r/#/c/138368/ as an example:  sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc. (sumanah, 18:32:22)
 * I really like the idea of taking generic info and flowing it into customizable/subclassable widgets (brion, 18:39:24)
 * (controller, controller/view, whatever) APIs though. (sumanah, 18:57:41)
 * TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though. (sumanah, 18:57:48)
 * ACTION: MatmaRex’s patches need review (brion, 18:58:06)
 * ACTION: MatmaRex to send to wikitech-l list of skin patches that additionally need review (sumanah, 18:58:35)
 * AGREED:  I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off; that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback (sumanah, 18:59:09)
 * ACTION: mobile web team should have a hand in this since it’s the main alt skin WMF uses internally (brion, 19:03:03)
 * goal of at least 2 WMF teams using this as a measure of success. MatmaRex: would be great to see community use as a barometer for success (sumanah, 19:03:04)
 * ACTION: mobile apps also interested in possible overlap with extensions and meta things (links etc) (brion, 19:03:16)
 * watch for more fleshing out of the RfC in the next week! (sumanah, 19:03:19)

Meeting ended at 19:03:52 UTC.

Action items

 * MatmaRex’s patches need review
 * MatmaRex to send to wikitech-l list of skin patches that additionally need review
 * mobile web team should have a hand in this since it’s the main alt skin WMF uses internally
 * mobile apps also interested in possible overlap with extensions and meta things (links etc)

Action items, by person

 * MatmaRex
 * MatmaRex’s patches need review
 * MatmaRex to send to wikitech-l list of skin patches that additionally need review
 * **UNASSIGNED**
 * mobile web team should have a hand in this since it’s the main alt skin WMF uses internally
 * mobile apps also interested in possible overlap with extensions and meta things (links etc)

Full log
18:00:10 #startmeeting Skins revamp | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 18:00:10  Meeting started Fri Jun 20 18:00:10 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:10  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:10  The meeting name has been set to 'skins_revamp___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 18:00:18 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20 18:00:28 #info Today we're talking about revamping MediaWiki's skins systems. I scheduled this before Erik sent out the note http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/077227.html about next week's front-end standardization chat. 18:00:44 First we'll be talking about MatmaRex's work, then Trevor's 18:00:53 #info FYI, next week we'll have that frontend architecture discussion here in #wikimedia-office 5:30 PM UTC on 25 June. 18:01:10 and 1 more thing 18:01:27 #info next week's regular RfC chat on IRC will be about https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes - which has multimedia implications 18:01:30  I have questions! But I will be back in 5 minutes. :) 18:01:35 but first, MatmaRex 18:01:42 #topic Bartosz Dziewoński's "Separating skins from core MediaWiki" work, including several patchsets that need review: 18:01:56 #link https://bugzilla.wikimedia.org/show_bug.cgi?id=65748 18:02:14 #link https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki 18:02:27 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20#Topics - that's where I listed the links to some changesets that need review: 18:02:38 (prepare for paste spam) 18:02:45 https://gerrit.wikimedia.org/r/136531 SkinTemplate: Move $stylename to Skin and soft-deprecate 18:02:45 https://gerrit.wikimedia.org/r/138652 Support for enabling skins in the installer 18:02:45 https://gerrit.wikimedia.org/r/135413 Separate Vector skin from core 18:02:45 https://gerrit.wikimedia.org/r/138795 Separate MonoBook skin from core 18:02:45 https://gerrit.wikimedia.org/r/138368 Stop using a suboptimal structure for Vector's variants menu 18:02:47 https://gerrit.wikimedia.org/r/138369 Stop using a suboptimal structure for Vector's variants menu (cont.) 18:02:50 https://gerrit.wikimedia.org/r/136615 SpecialVersion: Show 'Skins' and 'Extensions' in separate sections 18:03:46 Who here has read or commented on any of those - MatmaRex's proposal or one of the changesets? 18:04:00  I've read MatmaRex's proposal and I love it. 18:04:17  I read it and went "Wait, we HAVEN'T already done that?" 18:05:29  Are you mostly just waiting for code review? 18:05:29  haha :D 18:05:32 ashley, RoanKattouw, bawolff, I presume you've looked at a bit? 18:05:32 * bawolff wants us to continue shipping all existing skins (or at least a selection) with the tarball 18:05:39 otherwise, sounds great 18:05:54 hexmode: ^ do you have thoughts on bawolff's point there? 18:06:00  Deskana: mostly yes, but i still have a lot of stuff to do left 18:06:03 aye, I've also read the proposal and as said, it's awesome :) 18:06:18  bawolff: I see no reason why we wouldn't do that, personally. 18:06:32  bawolff: so do i! but not entangled with core, and instead just like we ship extensions 18:06:42 yep, that sounds good to me 18:06:48 <Deskana> bawolff: The fact that the skins are now modular and separated from core is purely a technical code quality thing. It has nothing to do with our decisions on what skins we ship as default. 18:06:50 skins are somewhat of an obscure area with a high bus factor and as such, it can -- and will -- make upgrading painful for third-party users using a custom skin (or, god forbid, a third-party instance that has *multiple* custom skins); nice to see it finally getting some attention from an experienced dev :) 18:07:15 <Deskana> MatmaRex: Okay, well, I'm not an engineer so I can't do that review myself, but I'll try prodding a few different channels for some review. 18:07:35 MatmaRex: To clarify (I skimmed very quickly) is vector going to move out of core too? 18:07:37 <MatmaRex> i'm not sure how the tarballs were built so far, but it can't possibly be hard to extend the tools to also bundle skins and not just extensions 18:07:40 <MatmaRex> bawolff: yes 18:07:53 Jon Robson and Ori Livneh are MatmaRex's GSoC mentors and are prime candidates for prodding for code review, Deskana ;-) 18:07:57 because I'm not sure how I feel about that, as then MediaWiki becomes unusable if 0 skins are installed 18:07:58 <MatmaRex> or most of all, even. it's the most problematic right now 18:08:17 and vector is the current fallback if an invalid skin name is specified 18:08:22 <MatmaRex> bawolff: i'm planning a minimal fallback skin instead of vector 18:08:29 hi jdlrobson2 - http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt is the logs so far, including us talking about prodding you for code reivew ;-) 18:08:38 <MatmaRex> so that MW doesn't fall over, and instead displays a friendly message that you should probably install some skins 18:08:42 Awesome :) 18:08:48 <RoanKattouw> sumanah: I like the principles behind MatmaRex's proposal, but I don't know enough about the skin system to judge the details 18:08:53 yup it's on my review to do list 18:08:53 could "nostalgia" be the fallback when 0 skins are installed? 18:09:07 <MatmaRex> mutante: heh 18:09:07 <^d> nostalgia doesn't exist in core either. 18:09:08 <TrevorParscal> My main comment is that the area you mention in step #1, about client side Skin API, I would like to work together on that, because it's an essential part of what my skin proposal does 18:09:27 Long live "standard" 18:09:28 <MatmaRex> the fallback skin will probably look pretty close to nostalgia (as in, having alost no CSS) 18:09:33 <MatmaRex> almost* 18:09:37 bawolff: +1 ;) 18:09:46 <MatmaRex> mutante: nostalgia actually requires a surprising amount of code to run right now 18:10:02 MatmaRex: i just saw "In MediaWiki 1.24 it will come back - no longer as an extension, but as a real skin - with several improvements. See git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Nostalgia" 18:10:16 <MatmaRex> it has an entire layer on top of regular skin stuff that provides backwards-compatibility with, like, MW 1.5 18:10:17 and that link is Not Found 18:10:22 MatmaRex: how long have you been waiting for code review? are there patches that need attention & you are blocked waiting for review? 18:10:24 <MatmaRex> mut 18:10:32 What is the rational for not including just a single default skin in the download and having a mechninism to download other skins on demand? 18:10:33 <MatmaRex> mutante: oh, that's interesting, but i didn't do that :P 18:10:57 I think the first time user experience is important to have a usable skin without configuration 18:10:57 MatmaRex: gotcha 18:10:58 <TrevorParscal> MatmaRex: also, in removing skinStyles, your proposed inversion is interesting, but we need to make sure there's a way for a skin to provide a style for a feature, which prevents the feature from loading it's default style, or we will end up with really ugly CSS overriding hell 18:11:10 <MatmaRex> sumanah: the ones you linked. i'm not really blocked per se, but not having them merged does make further progress a bit more difficult 18:11:31 MatmaRex, sumanah: Is there anywhere I could get a tl;dr version of MatmaRex's work so far and what he has in mind? Is it part of what Trevor is proposing or separate? 18:11:39 separate 18:11:44 <MatmaRex> jzimmerman: what's the rationale for doing that? also, no one has implemented such a system yet 18:11:51 jzimmerman: you mean download on demand from the web interface? because there's technical reasons why that's scary (requiring write access to php files from the webserver) 18:11:57 <MatmaRex> jzimmerman: i'm not touching these areas right now anyway :) 18:12:25 <TrevorParscal> kaldari: there's only a small amount of overlap, and I'm asking he work together with me there, or skip it for now 18:12:30 <Deskana> I think jzimmerman's point is that we should have the default skin be something that's pretty usable, like Vector. 18:12:30 @bawolff yes, exactly 18:12:34 <Deskana> As opposed to a stripped down skin. 18:12:35 <MatmaRex> kaldari: the bold parts on https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki ? :) 18:12:35 btw I want to thank jzimmerman and Deskana especially for coming to this chat - important to get more perspectives on this stuff 18:12:45 @Deskana, yes, correct 18:12:57 <Deskana> It's not about the download mechanism at all. 18:12:58 <MatmaRex> Deskana: the default in the tarball will still be vector 18:13:05 <MatmaRex> the default in WMF environment too 18:13:31 <MatmaRex> only installation from git will be affected in any way (unless we decide to use submodules, in which case it won't be affected either) 18:13:42 <Deskana> MatmaRex: So the "default skin" (i.e. it comes in the distro as the default) is Vector, and you'll only be served Nostalgia if you intentionally rip out Vector and don't put anything else in there. 18:13:46 wow, i didn't know we have an entire namespace "Skin_talk:" on mw.org 18:13:46 <Deskana> MatmaRex: Is that right? 18:13:54 so people will be downloading a default skin (vector) when installing for first time? 18:13:58 vector, or whatever, my point being that there is a fully functianly default skin, not something that looks like a webpage where the css didn’t load right 18:14:07 MatmaRex: (my rule of thumb is that when my mentee asks for me to review something, I do it within 2 business days. so I think you should bug your mentors if your patchsets aren't reviewed by Wednesday. ;-) ) 18:14:08 MatmaRex: Will there be backwards compat concerns with tarball users (Users upgrade MW by replacing entire directory, suddenly skins are gone) 18:14:35 <MatmaRex> TrevorParscal: what i had in mind was basically a hook that will let you mangle wgResourceModules in certain limited ways 18:14:52 <RoanKattouw> It sounds to me like it is possible for the release managers to release tarballs that include Vector and/or other skins and provide a smooth upgrade experience 18:14:55 <MatmaRex> Deskana: not Nostalgia, but rather a "nostalgia", but yes. 18:15:01 <RoanKattouw> What the tarball actually ships with is up to the release managers 18:15:04 <TrevorParscal> MatmaRex: It think you are on the right track there 18:15:06 <MatmaRex> moizsyed: no, it will be included in the download 18:15:07 #idea <RoanKattouw> It sounds to me like it is possible for the release managers to release tarballs that include Vector and/or other skins and provide a smooth upgrade experience 18:15:27 <MatmaRex> jzimmerman: as i said, vector will continue to be the default for normal users 18:15:33 <Deskana> jzimmerman: So we're fine from a UX perspective then. A Nostalgia-like skin is only served if someone intentionally fucks with their install by ripping out every single skin and putting nothing in there. 18:15:34 MatmaRex: ok that sounds good 18:15:36 <RoanKattouw> So I think we should not sidetrack this conversation with release matters 18:15:44 <TrevorParscal> agreed 18:15:45 <Deskana> jzimmerman: And if they're at the point of doing that, then they're beyond our ability to help anyway. :P 18:15:57 <TrevorParscal> and, he says clearly is he not changing skins, adding or removing skins, etc. 18:16:02 <MatmaRex> bawolff: with the tarball? nothing quite like that, no 18:16:15 <MatmaRex> bawolff: unless you mean the part where we remove autodiscovery support for custom skins 18:16:32 <Deskana> TrevorParscal, RoanKattouw: Us non-technical folks are asking these questions to make sure we understand. We're not trying to divert the conversation. :) 18:16:32 <MatmaRex> bawolff: in which case there are deprecation warnings in 1.23 and 1.24, but after that the skins disappear unless you fix them, yes 18:16:33 TrevorParscal: can you talk a bit about where you see the separation between skin & data APIs? 18:16:33 does this mean “Nostalgia” will need to be maintained beyond what it is (or isn’t) now? 18:16:53 <MatmaRex> bawolff: i prepared a migration guide, though, a few people used it already, commented and liked it :) 18:17:02 <TrevorParscal> one sec, running upstairs 18:17:08 <MatmaRex> bawolff: https://www.mediawiki.org/wiki/Manual:Skin_autodiscovery 18:17:09 gwicke: I thought we weren't discussing Trevor's proposal yet 18:17:09 MatmaRex: I'm assuming that when the skins are separate, they would get enabled in the installer like extensions (There's a check box for which to enable) 18:17:16 #info <TrevorParscal> My main comment is that the area you mention in step #1, about client side Skin API, I would like to work together on that, because it's an essential part of what my skin proposal does 18:17:22 and yes skin autodiscovery is evil and needs to die 18:17:25 <MatmaRex> RoanKattouw: yes, that's exactly what i want 18:17:26 #info <TrevorParscal> MatmaRex: also, in removing skinStyles, your proposed inversion is interesting, but we need to make sure there's a way for a skin to provide a style for a feature, which prevents the feature from loading it's default style, or we will end up with really ugly CSS overriding hell 18:17:32 kaldari: ah, I thought it was a mix at this point; later then 18:17:52 <Deskana> jzimmerman: My understanding is no. It's not actually Nostalgia, just Nostalgia-like with highly stripped down CSS. We don't "support it" because it's just the fallback for what happens if you're fucking with MediaWiki in ways you shouldn't. 18:18:02 <MatmaRex> bawolff: yes, and i have a pending patch for that :) 18:18:14 <Deskana> jzimmerman: Basically, a fallback to avoid crashes, as opposed to intended usable functionality. 18:18:24 <MatmaRex> bawolff: https://gerrit.wikimedia.org/r/#/c/138652/ 18:18:27 <Deskana> jzimmerman: (If I'm understanding correctly) 18:18:30 Deskana: thanks, i understand now 18:18:33 MatmaRex: So if someone upgraded their wiki by wholesale replacing mediawiki directory (which is common), they never run the installer, they never have an oportunity to "enable" the newly separated out skins, and if they were using a different skin suddenly it wont work 18:18:38 MW should be "usable" without any extensions or skins, it's just not very good as such ;-) 18:18:49 <MatmaRex> Deskana: jzimmerman: exactly, yes 18:18:57 Trevor just arrived at the office 18:19:01 ashley: should it? 18:19:05 ;-) 18:19:14 chances are you'll always want certain extensions (ParserFunctions, CheckUser, Scribunto?, etc.), and likewise, you probably want certain skins, too (MonoBook, maybe Vector, etc.) 18:19:17 <MaxSem> should! 18:19:29 <MatmaRex> bawolff: yes, that's a concern, and i considered what to do 18:19:42 MatmaRex: your proposal does not include any type of web interface for installing non-default skins at this point? 18:19:42 <MatmaRex> bawolff: basically we can do one of the two things to be as user-friendly as possible 18:19:58 I don't think it necessarily should. The idea of a modular Wikipedia is hopefully a goal we are aiming toward. 18:20:03 <MatmaRex> either we keep a very limited form of autodiscovery that will load the four "former core" skins if they are present 18:20:14 <TrevorParscal> I'm back 18:20:18 <MatmaRex> or we just displays warnings if there are skins which are installed but not enabled 18:20:19 <TrevorParscal> sorry for the disconnect 18:20:29 (btw MatmaRex thank you for letting us have this chat on a Friday night your time so San Franciscans can do it during their workday - I appreciate that) 18:20:32 <MatmaRex> (e.g. in update.php, or in the fallback skin if it's used) 18:20:32 * TrevorParscal is at his desk now 18:20:46 TrevorParscal: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt in case you missed anything, although I didn't see any disconnects 18:20:49 <MatmaRex> i'm leaning towards the second way, i think daniel friesen suggested the first 18:20:58 jzimmerman: "web installers" of any kind are considered somewhat evil, as bawolff mention earlier, for various reasons (security/perms, etc.); I mean, I'd *love* if the installer would auto-generate LocalSettings.php *and* place it in the correct location, but instead it prompts you to download the autogenerated LS and put it in the correct dir 18:21:20 thanks MatmaRex and sumanah for setting this up! 18:21:32 <Deskana> jzimmerman: I think that's a totally separate issue. 18:21:36 MatmaRex: Would there be a way for an extension to force enabling of a skin, for example, MobileFrontend is useless without enabling the Minerva skin. 18:21:39 <Deskana> jzimmerman: Outside the scope of MatmaRex's work. 18:21:40 <MatmaRex> jzimmerman: it will only work the way installing extensions works now. it will not download them for you, but it will enable them if they are already downloaded 18:21:47 I ask because MatmaRex mentioned a modern skinning system, and that’s how that work in most modern CMS 18:21:51 <MatmaRex> sumanah: (it's just early evening :) ) 18:21:52 <Deskana> jzimmerman: It just so happens that his work makes it easier to do web installers, but that's tangential. 18:21:54 MatmaRex: I guess we could just put it very big in the Release notes too 18:21:57 kaldari: Dependency management. An entirely different issue 18:22:09 <Deskana> (again, if I'm understanding correctly) 18:22:12 Probably through Composer 18:22:14 <MatmaRex> kaldari: sure, just the way it works now 18:22:18 jzimmerman: Well there's multiple dimensions of "modern" 18:22:38 MediaWiki is not technically a content management system, although it does a better job at that than most CMSes :p 18:22:45 <MatmaRex> kaldari: $wgValidSkinNames (which you must be using now) stays and becomes *the* way to add new skins 18:22:49 I think in this context modern is for the technical back-end, not the user management interface 18:23:08 bawolff: thats too bad ;) 18:23:13 <MatmaRex> bawolff: i will make release notes, yes 18:23:22 <MatmaRex> bawolff: it's on mw.org pages for the releases too 18:23:24 I wish Hershberger or Glaser were here 18:23:30 MatmaRex: Ah cool, then we're already doing it the way you envision on mobile :) 18:23:32 <MatmaRex> (well, on the page for 1.23 now, it will be on 1.24 and 1.25 too) 18:23:35 * sumanah pings hexmode again 18:23:51 ok, in a few minutes I want to switch over to talking to Trevor' 18:23:56 talking about Trevor's proposal 18:24:08 <RoanKattouw> So, I have a question 18:24:11 are there any last action items or facts to highlight? 18:24:11 <MatmaRex> kaldari: yes, i just want to abandon the old way dating back to MW 1.5 (or something) and only leave the "new" way which dates back to 1.12 18:24:12 <RoanKattouw> About the skinStyles thing 18:24:32 <MatmaRex> kaldari: all reasonably up-to-date third-party skins are using it already, too 18:24:32 jzimmerman: Although we also have to keep in mind our average users. Compared to say wordpress where we have single user controlled application, mediawiki installs tends to be maintained by "expert" users for a specific community 18:24:39 <RoanKattouw> I think in general, the notion that a skin should know about modules and style them (the proposed notion) makes more sense than a module knowing about a skin (the current notion) 18:24:43 <RoanKattouw> so that's good 18:24:46 jzimmerman: So in that context skin auto-install sort of makes less sense 18:24:49 <RoanKattouw> But I wonder how we'll do this for extensions 18:24:56 [although that's getting a bit off topic] 18:25:00 <RoanKattouw> For instance, the VisualEditor integration module has skin-specific styles 18:25:17 <MatmaRex> RoanKattouw: there's no reason why we can't keep supporting skinStyles 18:25:32 <MatmaRex> (unless you have an idea for a better system) 18:25:32 <RoanKattouw> We can't really put those styles in the skins, because VE is an extension and not part of core, so in most cases we'd want that to live in the extension 18:25:37 <RoanKattouw> Hmm 18:25:40 bawolff: have we though that *may* be a reason for less uptake than more user friendly CMSes? 18:25:42 <RoanKattouw> Yeah supporting skinStyles sounds fine 18:25:53 <TrevorParscal> Right, I mean we wouldn't want to bloat the skins with styles for every module 18:26:01 <RoanKattouw> It doesn't feel amazingly optimal to me but I have no grand ideas for a better system 18:26:15 <MatmaRex> RoanKattouw: like i mentioned earlier, what i want is basically a hook that will let you modify parts of $wgResourceModules 18:26:19 jzimmerman: Oh probably is. Buts its hard to be all things for all users 18:26:21 MatmaRex: before swe switch topics did you get all of your high priority questions or issues raised/answered? 18:26:29 <RoanKattouw> MatmaRex: Yeah that makes a lot of sense 18:26:40 <TrevorParscal> I'm in favor of allowing a new way, for the skin to provide a style for a module, which essentially adds a skinStyle entry to a module 18:26:43 <MatmaRex> RoanKattouw: in fact, passing $skinname and &$wgResourceModules['module']['skinStyles'] was one of my ideas 18:26:45 <TrevorParscal> but not getting rid of skin styles 18:26:48 <RoanKattouw> There's another use case I have for that too, so I look forward to that happening 18:27:16 <MatmaRex> jzimmerman: hey, i'm the one *answering* the questions here ;) (and i hope i didn't miss any) 18:27:44 <TrevorParscal> MatmaRex: I think you are good so far 18:27:50 TrevorParscal: personally I would prefer getting rid of skin-styles. I like the inversion idea. 18:28:03 <TrevorParscal> I think both have a use case 18:28:33 As a reminder, perhaps the single best thing y'all can do to help Bartosz's work move forward is to give code review comments - https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-20#Topics has a list of some outstanding patchsets 18:28:41 MatmaRex: sometimes we teach by asking questions rather than answering them 18:28:41 <MatmaRex> it generally makes sense to use skinStyles in the extension was written later than the skin, and "the new way" if the skin was written after the extension 18:28:52 I think it is pretty trivial for an extension to use some hook right before render to see what the skin is and add extra modules if necessary. 18:28:59 <MatmaRex> oh yeah, totally do review my patches y'all! :D 18:29:13 TrevorParscal: although having extensions/skins be able to dynamically add skinstyles would probably solve the problem as well 18:29:13 I don't see any specific reason to continue maintaining skinStyles. There are definitely other solutions. 18:29:34 <TrevorParscal> kaldari: yes 18:29:35 MatmaRex: can you pick 2 patches you would love to have merged *today*? 18:29:53 #info discussion of skinStyles - future of promise or future of peril? 18:30:10 brion: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140620.txt 18:31:02 thx 18:31:08 * sumanah switches topics 18:31:08 #topic Trevor's "Redo skin framework" proposal 18:31:16 #link https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework 18:31:21 ok gwicke - you had some thoughts? 18:31:22 <MatmaRex> sumanah: pick any :) 18:31:31 TrevorParscal: The RFC that you posted doesn't really explain exactly what a widget is or how it would be implemented. It just says that widgets are "server and client side objects which render/manage discrete elements on the page." My hope is that widgets are essentially data objects that include all the information about an element (for example the personal toolbar) and are accessible to both the server and client-side via APIs. The skins wo 18:31:31 consist of a controller that defines which widgets are used by that skin, a set of widget HTML templates for rendering the elements using the widget data, and CSS for styling that HTML. Is that close to what you have in mind as the implementation? If not, could you elaborate on the implementation (preferably using examples)? 18:31:31 MatmaRex: no, I'm asking you. 18:31:51 MatmaRex: if you pick 2 and ask people to look at them today, it's a lot easier. trust me 18:31:57 <MatmaRex> sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc. 18:32:03 <MatmaRex> one of mine is https://gerrit.wikimedia.org/r/#/c/138368/ 18:32:21 <MatmaRex> there are several more by other people which i'd also like merged before i move out the skins, but i don't have links handy 18:32:22 #info https://gerrit.wikimedia.org/r/#/c/138368/ as an example: <MatmaRex> sumanah: actually, it might make sense to merge some outstanding patches to the skins themselves, to avoid having to do more work to move them to new repositories etc. 18:32:29 <TrevorParscal> OK, so before we go on, let me define widget, in this context, so we don't go around in circles 18:32:34 MatmaRex: will you reply to wikitech-l with the links after this mtg? 18:32:37 <MatmaRex> can do 18:32:40 thx 18:32:42 * MatmaRex listens to TrevorParscal now 18:32:46 I'm totally redoing the skin system, but please please please also build a detailed migration guide -- I've had to update 10+ skins way too many times over subtle, badly-documented core MW changes that just happened to break stuff 18:32:47 * sumanah also listens 18:33:51 <TrevorParscal> A widget, is an object (in PHP or JavaScript) which represents a user interface control and, throughout the lifetime of the program, provides an API for interacting with and modifying that control 18:34:11 so it's a push model? 18:34:22 rather than a dependency tracking model? 18:34:33 <TrevorParscal> this is distinct from a template, which is is a unidirectional process 18:34:54 I think this RFC needs some sort of sequence diagram illustrating exactly what interactions are happening between the different skin components. 18:35:12 TrevorParscal: so you see KnockoutJS & Angular as unidirectional? 18:35:14 <TrevorParscal> A widget could use a template to render itself, but it would also abstract the the updating of information in the rendering, so you have a consistent API between creation and modification 18:35:37 <TrevorParscal> gwicke: are you here to troll me? 18:35:49 I'm seriously curious 18:36:31 I'm trying to work out what the difference in functionality is between reactive frameworks & widgets 18:36:33 <TrevorParscal> to the extend that KnockoutJS and Angular provide a persistent API for modifying rendered contents, they are effectively widgets and there is no difference 18:36:39 TrevorParscal: Do skins own the widgets? Or are they inserted into the skin by other components? 18:36:43 TrevorParscal: But I assume the skin would define which template the widget uses to render itself, correct? 18:37:40 <TrevorParscal> The skin would take data (navigation items, user information and content) and pass that data into widgets, which the skin can arrange 18:37:57 <TrevorParscal> the skin can also subclass standard widgets, to influence their rendering and behavior 18:38:27 So every widget will have a default rendering separate from the skins? 18:38:36 <TrevorParscal> a standard set of widgets, designed to present navigation, content and user information, would be provided, and each skin would subclass them as needed 18:38:44 let’s take a concrete example — say, “language links” <- would this be its own widget? 18:39:02 <TrevorParscal> yes 18:39:02 yes, an example would help greatly 18:39:07 <Deskana> So to test my understanding, MatmaRex's proposal is making skins modular rather than baked into core, and Trevor's proposal is about making skins themselves be part of a more generic framework? 18:39:11 <TrevorParscal> the input is the list of languages 18:39:17 OK, this proposal makes complete sense. Basically it's a modularization of the skinning engine, allowing separate overriding of rendering for specific components. 18:39:24 #info I really like the idea of taking generic info and flowing it into customizable/subclassable widgets 18:39:33 <Deskana> Okay, I explained that poorly. 18:39:52 <Deskana> Like there's a skin object with certain functions and parameters, and other skins extend that. 18:40:02 <Deskana> Rather than... well, whatever clusterfuck we've got now. 18:40:03 <TrevorParscal> The other side of this, is that on the client, we could also have a generic API for interacting with these standard widgets 18:40:04 TrevorParscal: so is the main difference between reactive templating & widgets subclassing vs. swapping partials? 18:40:26 <Deskana> I heard something about Vector extending Monobook the other day and I nearly cried. 18:40:35 <TrevorParscal> they are different approaches to the same effects, no? 18:40:45 Deskana: Modern extends MonoBook ;-) 18:40:50 +1 for a clean client-side JS API 18:40:50 <TrevorParscal> Vector is a copy/paste/tweak of monobook 18:41:14 <Deskana> Oh dear. 18:41:32 TrevorParscal: will this have the side effect of forcing us to be better at dogfooding our own APIs and not using private methods for actions that don’t go through APIs or no change there? 18:41:48 <TrevorParscal> the client side API would be able to add a navigation item, or a personal tool, or whatever - a skin that changes how a widget works would also provide a handler on the client for modifying it, thus the persistent abstraction to modifying the rendering 18:42:02 <Deskana> I must've missed the lecture about how CopyPasteTweak is a valid alternative to object oriented programming. :P 18:42:17 TrevorParscal: so is the API model-driven, or more imperative? 18:42:27 <James_F> brion: We can give you a quick spin through OOUI development if you're curious at some point. (Offer goes for everyone, and the Wikimania presentation will have a prepared walk-through.) 18:42:40 James_F: i’d love a brown bag session or something sometime 18:42:46 Deskana: it's "thanks" to the atrocity called SkinTemplate and mistakes made many, many years ago regarding MW's skinning system... 18:43:09 * brion takes blame for SkinTemplate but shares some of it with gwicke ;) 18:43:22 * gwicke hides 18:43:24 <TrevorParscal> jzimmerman: I think it will, I understand the problem as "this extension has to modify the skin, so it has 3 special cases for 3 skins and the rest are not supported" and we will be saying "this extension has to modify the skin, so we will use this standard API that all skins implement" 18:43:43 <Deskana> brion: I don't think anyone's out to blame anyone. MediaWiki is a fantastic innovation. It's just not scaled over time as well as we'd hoped. 18:43:47 <Deskana> brion: You're to be commended, not blamed. 18:43:49 :D 18:43:50 <TrevorParscal> ok, so another point that is central to this design 18:43:58 <TrevorParscal> so far, we have used our HTML output as the API 18:44:18 <TrevorParscal> some skins will have slightly different output to achieve cross browser compatibility for their varied designs 18:44:29 <TrevorParscal> aka. the CSS zen garden is a garden of lies 18:44:44 he! 18:44:46 heh 18:44:49 * Deskana adds that to the Bugzilla quips. 18:44:52 lol 18:44:53 <TrevorParscal> the approach I am proposing moves the API to JavaScript instead 18:45:04 a bit ironic given that CSS support is so much better these days 18:45:05 <TrevorParscal> where we can provide enough abstraction 18:45:09 than it used to be around 2004 18:45:31 css is great at many things, but it can’t, say, turn Vector into MobileFrontend or vice versa 18:45:55 <TrevorParscal> gwicke: we can talk later about some of the things that are STILL not fixed across browsers, don't believe the hype 18:45:56 yeah, it mainly can't change the position in the render flow 18:46:00 TrevorParscal: So how would widgets work without Javascript? Or does this solution require JS? 18:46:02 <RoanKattouw> Imagine how much it was a lie back in 2004 then :) 18:46:12 what do you mean by "slightly" different output? various third-party skins are *entirely* different from core skins...modern might be a remodeled MonoBook, and Vector might be sorta based on MonoBook, but that doesn't mean all skins out there are like that... 18:46:29 RoanKattouw: it required a bunch of cursing and elbow grease 18:46:30 <TrevorParscal> kaldari: it would only require javascript to modify the skin dynamically on the client 18:46:42 <TrevorParscal> which requires JavaScript anyway 18:46:56 <TrevorParscal> modifications to be done on the server can be done through a similar (nearly identical) API in PHP 18:47:13 <TrevorParscal> depending on the feature you are trying to write, you may make some modifications on the server, client or both 18:47:41 TrevorParscal: where do you see the main difference vs. the Knockout ideas we've been pushing? 18:47:49 <James_F> (This API is waiting for the new version of PHP to do live on the WMF servers, right?) 18:48:03 <TrevorParscal> That this is based on object oriented programming 18:48:32 I see, so subclassing vs. partial substitution 18:48:44 <TrevorParscal> again, different approaches to the same end 18:48:53 TrevorParscal: so can you eloborate on what sort of functions/data will be included within the widget object? It sounds like it will include some aspects of model, view, and controller, which concerns me a bit. Feel free to use the Languages Links as an example. 18:48:56 * MatmaRex likes what TrevorParscal is saying 18:49:05 <TrevorParscal> I believe that we already use object oriented programming throughout both client and server, and it is comfortable, powerful and convenient 18:49:35 <Deskana> The non-technical Deskana is still trying to fully understand Trevor's proposal. 18:49:45 for feeding data into the widgets, are we thinking model objects, or structured arrays? 18:49:51 <TrevorParscal> kaldari: as with most user interfaces, the design is more like model + (view/controller), where view and controller are merged a bit 18:49:54 <Deskana> So it's about taking our horrible mess of a skin system and making it object oriented instead? 18:50:12 Deskana: at least, we would have smaller messes which could be more easily cleaned up :D 18:50:21 TrevorParscal: so the interface will be the model, as in reactive? 18:50:30 <Deskana> brion: I support minimisation of messes. :P 18:50:31 <TrevorParscal> I'm pretty open to using objects, but there would need to be good reason for it, structured arrays are cool too 18:50:32 Deskana: "object oriented" is kind of a broad term. Some people consider the current system "object oriented" 18:50:36 <MatmaRex> TrevorParscal: so for example, we would have a widget for a "portlet link", and the skin would have to provide a PHP and JS API for the equivalent of the mw.util.addPortletLink function / PersonalUrls and similar hooks? 18:50:56 TrevorParscal: Objects (well, classes) have interfaces that can be enforced. Structured arrays do not. 18:50:59 <TrevorParscal> gwicke: the interface is not the model, it's literally the view 18:51:00 <Deskana> parent5446: From what I've heard, the current skin system is a bastardisation of object orientation. 18:51:10 :P Yeah that fits it perfectly 18:51:27 TrevorParscal: what's the motivation for giving up the model / view separation? 18:51:54 <TrevorParscal> MatmaRex: we can discuss the details of the API, but essentially yes, there would be a standard way of interacting with all parts of the skin 18:51:55 or perhaps more accurately, the 'drive everything from the model' paradigm 18:52:08 <Deskana> Sure, you can call it object orientation because it has the word "extends" in it, but "Vector extends Monobook" makes about as much sense as "Apple extends Orange". 18:52:19 <TrevorParscal> to some degree addPortletLink does this, of course if you read it's contents you will see why we should have skins provide implementations separately 18:52:20 I would also like to see an implementation that has good separation of concerns and a cleaner MVC separation. 18:52:28 <Deskana> I think I understand now. 18:52:31 we have about 8 min left, in case people want to wrap up and leave #info lines with their summary thoughts 18:52:31 <TrevorParscal> gwicke: nobody is talking about doing that 18:52:37 <MatmaRex> Deskana: i think what TrevorParscal is proposing is like the current system, but done well instead ;) 18:52:53 <MatmaRex> (more complicated internally, too, but also more flexible) 18:52:54 TrevorParscal: the addPortlet thing would be a departure IMO 18:53:04 <TrevorParscal> Indeed, MatmaRex sees that I am not revolutionizing, I am refactoring 18:53:34 in a model-driven reactive framework you'd just add a member to some portlet array instead 18:53:39 <TrevorParscal> the approach I wish to take is based on continuing good patterns, and cleaning up bad ones 18:53:50 <TrevorParscal> gwicke: I'm not able to do this with you right now 18:53:53 sumanah: somebody should establish some action items as to what the next steps for this RFC are 18:53:57 TrevorParscal: are there any ‘baby steps’ we can make on prototypnig this? 18:54:11 such as starting up a widget api and sticking it into a current skin as an example? 18:54:28 TrevorParscal: That makes sense I guess. My ideal vision would probably require rewriting MediaWiki from scratch ;) 18:55:03 <TrevorParscal> I think that if we can be preceptive enough to come up with a good API before rebuilding how skins construct themselves, that would be nice - again we will need to come up with an API that will work similarly on the server (ideally) 18:55:09 TrevorParscal: alright, would be nice if you could detail / motivate the differences a bit in the RFC though 18:55:18 <TrevorParscal> kaldari: one step at a time, but mine too 18:55:35 all in good time :D 18:56:07 <TrevorParscal> gwicke: I am happy to get into greater detail on the RFC, but you are asking questions that are more about implementation than API, and I believe this is a better time to talk about how people would interact with the system than how the system works internally 18:56:41 <TrevorParscal> any sufficient level of abstraction should be able to have it's implementation changed out without the API changing 18:56:41 <Deskana> I'd like to thanks MatmaRex, TrevorParscal and everyone else for explaining their projects to me in terms I can understand. :) 18:56:42 TrevorParscal: my question is actually mostly about the API style 18:56:48 not about the implementation 18:57:08 <MatmaRex> :) 18:57:09 <TrevorParscal> I fail to understand how, but we can talk another time perhaps? we have 3 minutes left 18:57:11 TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though. 18:57:28 kaldari: +1 18:57:38 any action items for moving forward? 18:57:41 #info (controller, controller/view, whatever) APIs though. 18:57:44 whoops 18:57:48 #info TrevorParscal: I would really like to have the APIs separated into model-based APIs and other stuff (controller, controller/view, whatever) APIs though. 18:57:51 <MatmaRex> brion: get someone to review my patches. :> 18:58:03 <TrevorParscal> I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off 18:58:06 #action MatmaRex’s patches need review 18:58:32 TrevorParscal: yeah, +1 on that 18:58:34 <TrevorParscal> that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback 18:58:35 #action MatmaRex to send to wikitech-l list of skin patches that additionally need review 18:58:35 nice 18:58:41 TrevorParscal: +1 18:58:58 I'm gonna #agreed that 18:59:09 #agreed <TrevorParscal> I think it would be ideal if the model information was sent to the client as a JSON blob embedded in the page, and if the client has JS it would use that information to bind to the rendered widgets and be able to pick up where the server left off; that way we can maintain the purity of the model, and continue to revolve the entire UI around it, but also have a sensible non-js fallback 18:59:09 <TrevorParscal> again, this is a detail I feel is important to include in the RFC, but I feel like the API on the client and server is probably not affected by it 18:59:36 the model basically becomes the API 18:59:41 reading the backscroll here i can see that we've spent a lot time within finer grained details, implementation, etc. what are the overlaps with working with existing teams to allow them to guide this project along ? 18:59:43 do people have any requests for Trevor that we should mark as action items? or TrevorParscal do you have any requests for the group? for info? 18:59:51 <TrevorParscal> So, the plan is that I will be spending 80% of my time during July and August working on this, and other UI standardization work 19:00:20 I think an action item is just there needs to be a more concrete description of what the API structure is going to look like, and how it is going to behave both server-side and client-side. 19:00:41 brion: do you agree? 19:00:53 * sumanah knows we need to wrap up in a minute 19:00:54 <TrevorParscal> tfinc: yes, thank you for bringing it back to higher level questions - my objective is to deprecate but still support existing methods of modifying skins (addPortletLink) and port all existing skins 19:00:59 TrevorParscal: I think it would also be interesting on the RFC to have information on why you feel that reactive frameworks don't address our needs 19:01:06 <TrevorParscal> teams should be minimally affected by the shift 19:01:08 TrevorParscal: Of course not everything that might be requested by the client can be known in advance by the server though, so it's still important to have model-based APIs available to the client. 19:01:23 ultimately the framework, standardization, etc can be as beautiful as we want it but if only a single team uses it then we haven't hit our goal 19:01:36 <TrevorParscal> but I would like to specifically work with Mobile to see how we can ensure the design makes it possible for MobileFrontend to get converted as well 19:01:44 *nod* 19:01:47 <TrevorParscal> by existing skins, I mean the 4 in production 19:01:50 <MatmaRex> tfinc: don't forget non-WMF usage 19:01:59 thus i put a goal of *2* teams using it as a sign of success 19:02:01 <Deskana> brion: How does this tie into apps? Does it? 19:02:03 <TrevorParscal> and the goal is also to get MobileFrontend as well - which is part of the UI standardization goals anyway 19:02:03 i’m also curious if there’ll be any overlap with apps extra metadata 19:02:06 <MatmaRex> i can see this being used by and loved by third-party skin developers 19:02:08 <James_F> tfinc: Absolutely. 19:02:18 Deskana: potentially extensiony things could have to integrate with the apps and we’d want to plan for that yeah 19:02:21 ashley: looking forward to your continued involvement as a rep of the non-WMF MediaWiki-running community 19:02:37 MatmaRex: would be great to see community use as a barometer for success 19:02:38 brion: there's a lot of overlap there 19:02:44 tfinc: +1 19:03:00 <TrevorParscal> we are 2 minutes over, I am going to be fleshing out the RFC in the next week 19:03:03 #action mobile web team should have a hand in this since it’s the main alt skin WMF uses internally 19:03:04 #info goal of at least 2 WMF teams using this as a measure of success. MatmaRex: would be great to see community use as a barometer for success 19:03:09 thank you TrevorParscal 19:03:16 #action mobile apps also interested in possible overlap with extensions and meta things (links etc) 19:03:19 #info watch for more fleshing out of the RfC in the next week! 19:03:25 <TrevorParscal> I'm happy to meet with people on IRC or in person about this work, and I will be publishing plans for it publicly both on wiki and on list 19:03:34 <Deskana> brion: Cool. So not much for us to worry about just yet. 19:03:40 <TrevorParscal> not yet 19:03:41 <James_F> Deskana: One of the VE team has made a (non-MW) app using OOUI; might be worth discussing if it's useful. 19:03:47 ok, I'm callin' it. Thanks all 19:03:51 TrevorParscal: Thanks Trevor, look forward to seeing more info in the RfC :) 19:03:52 #endmeeting