Architecture meetings/RFC review 2014-07-10

22:30 UTC on 10 July 2014, at.

Requests for Comment to review

 * 1) Requests for comment/Redo skin framework, and its relationship to UX standardization. Followup to the June 25th chat (logs).

Meeting summary

 * LINK: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-10 (sumanah, 22:30:26)
 * Redo skins proposal (sumanah, 22:30:35)
 * Today we're talking about revamping MediaWiki's skins systems, and specifically about Trevor Parscal's RfC. (sumanah, 22:30:43)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework (sumanah, 22:30:51)
 * LINK: http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/077284.html - summary of the chat we had on this topic 2 weeks ago. (sumanah, 22:30:59)
 * LINK: https://tools.wmflabs.org/paste/view/76ace71a is a log of what was said during the netsplit (sumanah, 22:36:50)
 * ACTION: TrevorParscal and gwicke should meet to discuss the possibility of a single integrated direction on the frontend possibly including KnockoutJS (TimStarling, 22:55:31)
 * discussion of whether this project, which is mostly focusing on paying off technical debt and additionally delivering one very new skin, ought to have more user-facing deliverables (sumanah, 22:58:17)
 * "and mobile will be adding either jgonera or kaldari for a period of time to help" (sumanah, 22:59:42)
 * lots of agreement that the skin system needs fixing (sumanah, 23:21:48)
 * if we're going to do a new skin; let's do simple -- something that a developer can use to prototype all new features and that a skin designer can use to change to their liking (sumanah, 23:25:48)
 *  mwalker: I think having a boilerplate skin would be nice, I think that is what you are talking about, it would take very little effort (sumanah, 23:25:52)
 * when Roan returns from India (in a few weeks) Trevor will send out "how you can help" info to wikitech-l (sumanah, 23:27:02)
 * "Winter" is a design and a thought process. Minerva is a skin.  (sumanah, 23:32:00)
 * Eloquence got the right of it. Winter is the toolset to design the next skin.  (sumanah, 23:32:04)
 *  jgonera, I see the goal for Winter to be a prototyping framework that UX designers can use to try ideas (called "snowflakes" in Winter) which are then implemented into proper production level code if they pass user testing (sumanah, 23:32:09)
 *  I just want to repeat something, the "other" skin that is being proposed is not meant to be the "next" skin (sumanah, 23:32:35)
 * LINK: https://www.mediawiki.org/wiki/Winter (jzimmerman, 23:33:48)
 * ACTION: tfinc setting up schedule for frontend devs to meet. (noting this more for posterity's sake than because I think tfinc needs pushing to do it) (sumanah, 23:35:38)

Meeting ended at 23:40:33 UTC.

Action items

 * TrevorParscal and gwicke should meet to discuss the possibility of a single integrated direction on the frontend possibly including KnockoutJS
 * tfinc setting up schedule for frontend devs to meet. (noting this more for posterity's sake than because I think tfinc needs pushing to do it)

Action items, by person

 * gwicke
 * TrevorParscal and gwicke should meet to discuss the possibility of a single integrated direction on the frontend possibly including KnockoutJS
 * tfinc
 * tfinc setting up schedule for frontend devs to meet. (noting this more for posterity's sake than because I think tfinc needs pushing to do it)
 * TrevorParscal
 * TrevorParscal and gwicke should meet to discuss the possibility of a single integrated direction on the frontend possibly including KnockoutJS

People present (lines said)

 * TrevorParscal (102)
 * superm401 (53)
 * sumanah (47)
 * jorm (33)
 * TimStarling (31)
 * jgonera (29)
 * gwicke (24)
 * tfinc (20)
 * shahyar (19)
 * MatmaRex (19)
 * awjr (15)
 * jzimmerman (14)
 * brion (12)
 * StevenW (9)
 * Eloquence (9)
 * James_F (8)
 * jdlrobson (6)
 * wm-labs-meetbot (5)
 * mwalker (5)
 * Scott_WUaS (5)
 * Carmela (4)
 * marktraceur (3)
 * violetto (2)
 * Reedy (1)
 * subbu (1)

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Full log
22:30:15 #startmeeting Redo MediaWiki skins | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours 22:30:15  Meeting started Thu Jul 10 22:30:15 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:30:15  Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:30:15  The meeting name has been set to 'redo_mediawiki_skins___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' 22:30:21 #chair sumanah brion TimStarling 22:30:21  Current chairs: TimStarling brion sumanah 22:30:26 #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-10 22:30:28 \o/ 22:30:32 * tfinc grabs a seat 22:30:35 #topic Redo skins proposal 22:30:35 noobs, geez, leaving the meeting running overnight 22:30:43 #info Today we're talking about revamping MediaWiki's skins systems, and specifically about Trevor Parscal's RfC. 22:30:51 #link https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework 22:30:59 #link http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/077284.html - summary of the chat we had on this topic 2 weeks ago. 22:31:08 Trevor, perhaps you would like to start by giving an overview of how the RFC has evolved in the last 2 weeks? 22:31:13  sure 22:31:39  There was some editing on the RFC done by Timo and others 22:31:45  some of which was correct, most was not 22:31:46 And then after you've done that, we'll open it up to questions. (But first I'd like for people to let him finish his thought here.) :) 22:31:53  I recently (yesterday) rewrote it 22:32:12  it is now correct, and includes more detailed information about what is being proposed 22:32:30  is this something you have resources for? is it on your quarterly plan? 22:32:30  the problem statement hasn't really changed, but there seems to be some suggestion that it should 22:32:42  it looks pretty big 22:32:53 hey Tim, maybe let him finish first?    TimStarling: I have been approved to spend 2 months @ 80% on this starting later this month    see what you did    <TrevorParscal> net split :( trevor you are causing netslips God, TimStarling, bringing the wrath of freenode down on us   slips, lol. <YuviPanda> gah, netsplit * TrevorParscal waits <TrevorParscal> sumanah: let me know when you think I should proceed Will do TrevorParscal <legoktm_> some of us are still netsplit :/ <TimStarling> wait for the log bot to rejoin if possible wm-bot is back. yup <TrevorParscal> ok, anyway...   <TimStarling> not wm-labs-meetbot though? Good point. TrevorParscal: hold on 1 more min.   <TrevorParscal> The RFC does not go into details about the implementation on purpose - it would be unwise to choose a detailed implementation at this point <TrevorParscal> ok...   <TimStarling> maybe it needs a restart? who is responsible for it? <TimStarling> goodie ok TrevorParscal go ahead 22:36:50 <TimStarling> goodie 22:36:50 ok TrevorParscal go ahead 22:36:50 https://tools.wmflabs.org/paste/view/76ace71a is a log of what was said during the netsplit 22:36:53 I will find some way to interpolate it into meetbot's record for the wiki page. 22:37:01 <TimStarling> <TrevorParscal> TimStarling: I have been approved to spend 2 months @ 80% on this starting later this month 22:37:11 <TrevorParscal> ok, we good? 22:37:19 Go ahead TrevorParscal 22:37:33 <TrevorParscal> As I was saying, The RFC does not go into details about the implementation on purpose - it would be unwise to choose a detailed implementation at this point 22:37:49 TimStarling: and mobile will be adding either jgonera or kaldari for a period of time to help 22:38:03 #chair sumanah TimStarling brion 22:38:03 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah 22:38:11 (good, it knows we're in a meeting still) 22:38:33 <TrevorParscal> Also, there was some question about "what value does this provide for end users", and the answer is basically "none, at least not immediately" because this is not proposing to change the user experience, but could help make changing the user experience easier in the future 22:38:51 <TrevorParscal> It's technical debt, not a feature 22:39:02 <StevenW> I think the framing awjr provided on the Talk page makes a lot of sense. 22:39:17 <StevenW> We are in fact cleaning up the technical debt in order to solve a problem that matters to users. 22:39:22 <StevenW> If in a roundabout way. 22:39:55 (Trevor, if you've said your piece for now, I'll open it up to questions and stop saying you have the floor?) 22:40:00 <TrevorParscal> yup 22:40:02 ok! 22:40:40 now taking questions for TrevorParscal to answer on https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework 22:40:59 think of it empowering front end developers to more easily, quickly, and consistently iterate on front end features 22:41:15 i think cleaning up technical debt purely for the sake of cleaning up technical debt can be frought with peril - that is, how can you be sure that you're repaying the technical debt in the correct way unless the work is being driven by something that will ultimately provide value to users? 22:41:38 <TrevorParscal> i disagree 22:41:57 <MatmaRex> (i think enough people who know what they want are involved in this to alleviate that sort of issues) 22:42:10 <TimStarling> it would be easy enough to throw in a feature or two to ground it 22:42:40 <TrevorParscal> I don't think feature creep is going to help this project be successful 22:42:41 <TimStarling> I like to do that when I redesign things, as a test of the interface 22:42:52 i thought there is one such feature ... building a new skin to prove its flexibility. 22:42:53 <TimStarling> basically acting as a consumer to test out how it feels 22:42:56 <TrevorParscal> OK, well indeed - did you read the RFC? 22:43:18 <TimStarling> me? 22:43:27 <TrevorParscal> I intend on exercising the flexibility of the system by "Introduce a radically different skin (doesn't need to be the "next" skin) as a test to prove flexibility" 22:43:50 <MatmaRex> updating Vector with the new features would be exercising enough… 22:43:52 TrevorParscal it is already articulated in the rfc that this will introduce a 'radically different skin'. my suggestion is to make that be the driving force in the technical changes - and rather than throwing an arbitrarily radically different skin, let the new skin be something of actual value to users 22:43:54 <TrevorParscal> What is frought with peril is introducing new features to our users 22:43:57 Wouldn’t building out Winter be the right way to go about this? 22:44:41 i think that framing the project in that way does a few things 1) it actually prevents feature creep - or the wrong features getting developed and 2) sets this project up to actually be more silo-busting by making the work cross-functional from the beginning 22:44:44 <TrevorParscal> there's no reason the radically different skin can't be one based on existing designs 22:44:46 I don't necessarily think we need to build the real "next" skin at the same time we do these arch changes. 22:44:56 Among other things, that may just be too much change at once. 22:45:06 The proposal to build a radically different skin should be test enough. 22:45:18 Also, in the process of porting the four existing skins, that will give us indication if this is a reasonable approach. 22:45:20 <StevenW> I think the situation with Winter is more like that various components (toolbar, fixed header) have been bolted on to Vector as Beta Features. But that doesn't solve the core problem with the skinning system. 22:45:30 "The first step in the process will be to audit existing skins and extensions to discover patterns and anti-patterns related to rendering, extending and modifying skins." 22:45:33 <MatmaRex> +1 to superm401 22:45:45 <TimStarling> for me, it is good to hear that you want there to be no user-visible changes initially 22:45:46 And porting those 4 is also part of the RFC already. 22:46:02 I would question the value of porting all existing skins to the new framework would be a valueable use of time 22:46:04 <TrevorParscal> seriously, the point of the RFC is not to introduce new features to the user, and I stand by that as an important point - suggestions that we throw in "a feature or two" aren't really going to help this project succeed 22:46:08 I really think it's okay for us to put the particular "how radical is the radical new skin going to be" question off till after that process. 22:46:21 to throw some more fuel on this fire - i also question the value of porting existing skins to the new framework 22:46:26 <TimStarling> because when I was reading the RFC 45 minutes ago, some bits in it suggested a more heavyweight client side 22:46:26 I would not say that Winter is the way to fix this; the skinning problem is independant of that. Winter would likely benefit from a widgetized skin system. 22:46:38 If it's a good architecture, that won't be an excessive amount of effort. 22:46:47 And dropping all the other skins again makes this a change management nightmare. 22:46:54 We're already going to have change management issues most likely. 22:46:59 Isn't the point here that the architecture should follow the feature and not the other way around? 22:47:02 E.g. breaking APIs that rely on dumping HTML ontot the page. 22:47:06 <TimStarling> presumably that would have the usual drawbacks -- flicker, higher bandwidth requirements 22:47:08 That sounds like what TimStarling is saying. 22:47:25 <Eloquence> TrevorParscal, My understanding is that there's nothing in this proposed new skin framework that contradicts the notion of introducing a standardized templating system (like Knockoff/out, or Handlebars, or whatever) into mediawiki/core, is that correct? 22:47:32 <MatmaRex> superm401: i think it should be easy to implement this as a separate system, leaving SkinTemplate and its APIs alone 22:47:38 <TimStarling> e.g. "The model objects are serialized and embedded into the page for the client to use. On the client, if the client is capable, the model is unserialized and view objects are generated and bound to the DOM which the browser has built from the HTML the server generated." 22:47:48 <TrevorParscal> we already have the features (skins), and they are implemented in a very messy way that makes extending them very difficult, so we are following that 22:47:54 While I understand the goal of this RFC, what I’m suggesting is that by building out something like Winter in this process, you get to actually showcase how to develop more complex, modern features that currently aren’t present in older skins. 22:47:55 MatmaRex, I more meant extensions, but even if SkinTemplate is maintained temporarily, presumably it's going to be deprecated. 22:48:01 <MatmaRex> superm401: so no breaking changes, really, until maybe some time in the ffar future we decide to kill off the old system 22:48:38 I think it's fine to say "radically different skin" might be our next skin. 22:48:41 <TrevorParscal> Eloquence: i specifically call out in the RFC that templating is not excluded as a rendering mechanism, but also that it in of itself is not a complete solution to the problem and will only play a complimentary role 22:48:48 I don't think it's reasonable to make us commit to that as part of this RFC. 22:49:12 <James_F> * complementary 22:49:15 <TrevorParscal> indeed 22:49:39 imo reworking the skin framework is a truly significant (and needed) change in mediawiki, but i think that porting existing skins should be auxiliary to the RFC. in some ways, i could see a new skin framework as part of a mw 2.0 22:49:41 If that new skin is going well, there could be another RFC to propose a switch to the default skin. 22:49:53 <TimStarling> do you imagine model transmission to the client would be optional? 22:49:59 <TrevorParscal> TimStarling: there will not be a shift of features from the server to the client, but existing client features will be ported 22:50:00 awjr, if we don't port existing skins, that means people need to learn two systems to maintain skins. 22:50:01 So, my biggest question is this: If we're honest with ourselves - truly honest - we know that we (as the Foundation, as Wikipedia, etc.) - are not going to be writing a lot of skins in the future. Like, maybe one. 22:50:06 TrevorParscal: supporting other teams as part of this development is one of the reason i get excited about this. how has your work with mobile help to evolve/iterate/etc seeing us a client of this? 22:50:06 Even just for core/bundled skins. 22:50:08 <TrevorParscal> there will be no change in user experience 22:50:14 <TimStarling> right, thanks 22:50:14 FWIW i would say Minerva is a radically different skin.. it doesn't really follow existing patterns at all especially in terms of HTML markup and concept. 22:50:16 So this is maybe a feature for 3rd party developers, and not us? 22:50:21 TrevorParscal: I think it would be nice to work out the differences between something like KnockoutJS components and what you are planning to do in the RFC 22:50:22 superm401 not if it's part of a 2.0 22:50:33 so, I can see questions for Trevor are piling up, maybe y'all could slow down so he can answer 22:50:41 <Carmela> jorm: I don't think that's honest, exactly... the lack of skin options is kind of tied to the shitty skins system. 22:50:49 <StevenW> Yes. 22:50:50 * tfinc gets in line for the mic 22:50:51 <Carmela> Like, we really ought to have more variety. 22:50:52 No, I think we should dogpile. 22:51:06 I don't disagree, MZ. I'm talking like a resource manager. 22:51:11 <Carmela> Ah, okay. :-) 22:51:13 "is this worth foundation dollars" 22:51:14 how about building a new skin and a new framework together and when that's done, use the framework to port Vector (Monobook?)? 22:51:19 <TrevorParscal> tfinc: so far, my interactions with mobile have simply confirmed that this needs to happen, because as jdlrobson says, minerva is pretty different and lots of things don't work on it because of that 22:51:34 I don't think we should punt porting the existing skins down the road. 22:51:44 If this RFC develops a good skin system, port all of the existing ones. 22:51:48 One way to maintain them. 22:51:54 And if you want to call it 2.0 when it's done, fine. 22:51:56 That's not the point. 22:52:04 <MatmaRex> jorm: the current skin system really does constrain developments 22:52:10 <MatmaRex> jorm: you surely experienced that with Winter :) 22:52:45 <TrevorParscal> jgonera: I'm not doing this alone, I expect help from a lot of people, but unless you can also get a big chuck of time to help, I will still end up writing most of it 22:52:53 I'm not saying it doesn't. And I *have* experienced that. I agree pretty much with everything we're talking about; I just think we need to dot the is and cross the ts so we can say "we're spending donor dollars on this because X" 22:52:56 <TrevorParscal> jgonera: please ask your manager if you can get a bug chunk of time to help :) 22:53:03 <StevenW> So TrevorParscal, what do you think you and either jgonera or kaldari going to tackle first? 22:53:06 superm401 for sure - but if we let porting existing skins drive the development of this project then you will almost certainly wind up with feature creep and wind up spending a lot of time on something that doesn't immediately deliver value to users 22:53:26 awjr, if it doesn't allow more than one skin, it's not a skin framework. 22:53:28 I think making a MVP of Winter from scratch might be a good test of this, and could deliver a lot of value in that it would lead to a beta feature. 22:53:29 "and mobile will be adding either jgonera or kaldari for a period of time to help" 22:53:46 I don't think it's feature creep to allow more than one skin. 22:53:47 TrevorParscal, I'm absolutely willing to help with this, I'm just saying that if we use it to build something new it will a) be well architectured to support that new skin b) we will feel better by shipping something that is actually user-facing 22:53:50 <MatmaRex> awjr: how so? existing skins hardly have any features that could creep up here 22:53:51 superm401 i agree :) 22:54:10 <Scott_WUaS> (Trevor and all: I'm not sure whether this question is within the scope of this office hour or RFC, but in what ways might there be implications for non-English Wikipedias in your development of skins: e.g. right to left languages, or with vocal language Wikipedias if there are any, especially on mobile phones/computers etc. ... in anticipating all the languages Wikipedia/MediaWiki will eventually be in? Is 22:54:10 <Scott_WUaS> anticipating other Wikipedia languages germane to this Skin development RFC conversation?) 22:54:12 <TrevorParscal> StevenW: my first step is to understand what people are already doing, especially finding the good and trying to reuse that 22:54:24 TrevorParscal, yeah, tfinc already knows it will take a chunk of our bandwidth 22:54:32 <StevenW> Could you use help in a review of skinning frameworks? 22:54:32 I am in agreement with jgonera. Not to mention, spending so much time on something like this, you should ideally have something to show for it if possible. 22:54:44 Scott_WUaS: I think we can safely assume that any new skin will be as good as existing skins when it comes to localisation and language issues. 22:54:55 <Scott_WUaS> thanks 22:54:59 superm401 MatmaRex i think shahyar  more succinctly stated my point 22:55:20 <TrevorParscal> Scott_WUaS: the problem you are talking about, supporting complex situations, is made better by increasing abstraction 22:55:22 im not in principle against porting existing skins, but im not convinced that ought to be the driving force of this project 22:55:31 <TimStarling> #action TrevorParscal and gwicke should meet to discuss the possibility of a single integrated direction on the frontend possibly including KnockoutJS 22:55:35 awjr, if that were the driving force, there would *be* no project. 22:55:42 We already have those skins, so that's not the root of the issue. 22:55:46 <Scott_WUaS> abstraction? 22:55:46 The root is maintainability. 22:56:02 <TrevorParscal> When I made vector, I actually improved the RTL support over monobook - this stuff is really important 22:56:17 <TrevorParscal> TimStarling: there's not much to talk about 22:56:39 <TrevorParscal> any template system can be encapsulated by a view/controller object (widget) 22:56:58 <TrevorParscal> I expect there will be a few until people decide what they want to standardize on 22:57:03 TimStarling: I don't actually care that much about Knockout or whatever- I mainly care about clearly documenting our goals & requirements, and then selecting a solution based on those 22:57:17 <TrevorParscal> but at the current moment, there is absolutely no agreement on that, and I am not waiting around for that, nor do I need to 22:57:20 while clearly documenting why this or that option didn't satisfy the criteria 22:57:24 <TimStarling> I was just trying to make a note of what gwicke said: "TrevorParscal: I think it would be nice to work out the differences between something like KnockoutJS components and what you are planning to do in the RFC" 22:57:58 <TrevorParscal> the differences between the systems is that they solve different problems, and one can use the other 22:58:17 I said the same on the talk page 22:58:17 #info discussion of whether this project, which is mostly focusing on paying off technical debt and additionally delivering one very new skin, ought to have more user-facing deliverables 22:58:32 <TrevorParscal> gwicke has his own ambitions to use this templating language in place of an object oriented system, and I believe it should work together instead 22:59:22 <TrevorParscal> again, as said in the RFC clearly, a widget is just an abstraction around a rendering that provides an API for modification 22:59:36 <TrevorParscal> if the guts of that widget are a knockout template, awesome 22:59:42 #info "and mobile will be adding either jgonera or kaldari for a period of time to help" 22:59:42 <TrevorParscal> handlebars, cool beans 22:59:57 <TrevorParscal> there's absolutely no reason to decide on one or the other 23:00:00 TrevorParscal, so just to be sure: you're saying that widgets could potentially use templates to render parts of their HTML, or possibly, the other way round, there could be a page template that uses widgets to fill in "the gaps" (dynamic parts of the skin)? 23:00:36 <TrevorParscal> not the other way around, pages are collections of widgets, widgets can use templates if that is what the author of the widget thinks is a good idea 23:00:38 tfinc: if you have an additional question I think you can ask it now 23:00:48 TrevorParscal: to me it just sounds like there's some potential overlap with a lot of the things happening in the web components & templating space 23:00:58 <TrevorParscal> i disagree completely 23:01:19 hrm. i guess we don't have to answer my question. 23:01:33 <TrevorParscal> which was? 23:01:36 <TrevorParscal> sorry there were many 23:01:54 So, my biggest question is this:  If we're honest with ourselves - truly honest - we know that we (as the Foundation, as Wikipedia, etc.) - are not going to be writing a lot of skins in the future. Like, maybe one. So this is maybe a feature for 3rd party developers, and not us? 23:02:05 I was saying that I pretty much agree with everything you want to do, and see the value. 23:02:07 <TrevorParscal> writing many skins, maybe not 23:02:10 superm401 i agree that a critical facet of this project is maintainability, but i am not convinced that we should be focussing our efforts on maintaining all of the existing skins. we should be focussing on delivering something valuable to our users - that is unless the point of this project is to better support third party users of our software. i think the project itself, the wmf, and our end users would benefit more from the approach i am 23:02:10 describing 23:02:18 <TrevorParscal> evolving and extending the few we have, yes 23:02:21 But I want to know how we can sell spending donor dollars on it. 23:02:22 we’ll also do “things that fit into skins” 23:02:28 which’ll be relevant (widgets etc) 23:02:32 TrevorParscal, not the other way round? but we surely don't want a widget that renders HTML doctype, so I assume there would be like a master template for a skin with all the HTML boilerplate 23:02:38 <TrevorParscal> if you want to move more quickly, we need to pay off this debt that 23:02:43 rework the language list? -> widget 23:02:51 rework the sidebar’s toolbox? -> widget 23:02:57 rework the person links? -> widget 23:02:57 sorry I missed your question jorm and didn't follow up 23:02:59 <TimStarling> TrevorParscal: I think you should reserve your "complete disagreement" until you have a very accurate idea of what gwicke wants 23:03:16 Yeah. See, I'd love that. That's actually what i've done with Winter's framework. It's all widgets now (called "snowflakes") 23:03:16 awjr, if you want to drop the other existing skins, I think that should be a separate RFC. 23:03:26 <TrevorParscal> jgonera: to the contrary, the general output of an HTML document is a perfect thing to abstract 23:03:46 I am satisfied and happy with the answer. 23:03:51 <TrevorParscal> brion seems to get it 23:03:57 :) 23:03:59 <TrevorParscal> i'm glad jorm 23:04:04 yeah, I get it, too. 23:04:08 i’m pretty happy with the proposal, don’t have a lot to add 23:04:21 me neither; i just am a miser. 23:04:23 TrevorParscal, sure, but I don't think we need a widget for each HTML tag we output on the page, as some of it is just boilerplate 23:04:33 jgonera, TrevorParscal, can there just be a root widget? 23:04:38 I agree with what you TrevorParscal suggest and understand brion 23:04:40 The root widget includes the HTML doctype, skeleton stuff. 23:04:44 And then other meaningful widgets as children. 23:04:45 <TrevorParscal> TimStarling: we have talked at length several times already, he is unhappy with my position and insists I don't understand him, that is different than not hearing him out 23:04:48 i don't think he's saying "every html tag" 23:04:51 jdlrobson: shahyar: given the benefits of the proposal what would be actionable for you to pickup and re-use and/or get involved with ? 23:04:51 but what about part's that are completely not data driven? 23:05:08 jgonera, template? 23:05:08 <TimStarling> I see 23:05:09 i think we're talking about things like <LANGUAGE_LIST type="vertical" /> 23:05:10 <TrevorParscal> jgonera: a widget is not meant to be a 1:1 relationship to an HTML tag, indeed 23:05:10 <StevenW> So this is a big project. Agreed? 23:05:11 shit like that. 23:05:42 am i wrong? 23:05:43 jorm: that sounds like.. web components ;) 23:05:53 yeah. in java they're called "Tiles" 23:05:54 superm401, sure, we can call it a root widget, but what does that widget use to output that boilerplate? just string concatenation? why not templates? 23:06:02 <TrevorParscal> jgonera: if there are parts of a skin that are just blobs of HTML, then perhaps a template could be used within a widget to render that part 23:06:04 <TimStarling> StevenW: agreed. Exactly how big depends on how many things get refactored into it 23:06:05 jgonera, I just said a template. 23:06:11 tfinc: I’d definitely like to get involved with the base templating system. 23:06:18 <StevenW> So considering that, what's the first milestone to shoot for, other than doing a review of current best practices to steal? 23:06:21 and i love tiles, btw.  struts+tiles == awesomesauce. 23:06:28 ok, TrevorParscal and superm401, I just wanted to be sure that we're on the same page ;) 23:06:57 <TrevorParscal> the point I am getting at is, there is no argument against using templates for what they are good at, only against using templates for what they are not good at 23:07:13 <TrevorParscal> and we can play to their strengths 23:07:14 I also have problems with typing and reading at the same type so sorry if my question doesn't include something from a few lines before ;) 23:07:29 <TrevorParscal> but not subject ourselves to their weaknesses 23:07:41 ok, that sounds good 23:07:48 TrevorParscal: I'm still curious why you dismiss components implemented by a controller object + templates completely 23:08:15 So, with regards to how this renders… Flow currently does something similar to what you propose: the discussion board is essentially a giant widget which renders with numerous subtemplates (handlebars). On page load, JS basically loads up and makes the widget components “interactive” using data-* attributes, and any subsequent dynamic rendering (eg. API calls) load up the same templates on the client-side and render them the same way, except 23:08:16 JS. — My question for TrevorParscal: would your proposed system do something like this, or do you have a different idea in mind? 23:08:51 <TrevorParscal> gwicke: in some cases, a widget may indeed be just that, but there's many cases where that is not a good design and I believe the system doesn't have to make a hard line decision about the internal workings of a widget 23:08:56 jgonera, no problem. 23:08:58 <TrevorParscal> it's called abstraction, and it works very well 23:09:17 sure, but a controller is arbitrary code 23:09:32 <TimStarling> if gwicke has an unresolved objection, then we don't have consensus 23:09:48 <TrevorParscal> shahyar: based on your description, that's about what we are going to do, but I don't know if the details are similar or not 23:09:49 I think TrevorParscal is saying gwicke's system is a possible implementation of his system. 23:09:54 If I understand the proposals right. 23:09:56 <TrevorParscal> it is a subset 23:10:32 <MatmaRex> TimStarling: (consensus doesn't mean unanimous) 23:10:35 <TimStarling> if there's no consensus, I would be happy to support creation of a prototype, but less happy to support a specific direction 23:10:35 I actually don't have any hand in the Knockout stuff ;) 23:10:50 I'm just pointing out that there are solutions out there that sound like they are doing almost the same thing 23:11:00 and am trying to understand what disqualifies them 23:11:01 <TimStarling> MatmaRex: we have a small, competent, heavily involved working group 23:11:07 <TrevorParscal> TimStarling: the problem we have is that I have not taken a specific direction yet, and gwicke is asking me to lay out details I don't have yet 23:11:20 <MatmaRex> gwicke: it just sounds like controller+template is a subset of what trevor's proposing 23:11:22 knockout (what knockoff is based on) provides a page level controller and hooks if we so choose to use them; we chose that framework so that we could provide reactive pages -- although you dont have to use it, it's a useful thing to have and I'd rather not have two competing page models 23:11:24 <TimStarling> yeah, which is why I am happy for you to build a prototype 23:11:27 <TrevorParscal> gwicke: knockoff is not a Skin system 23:11:34 <MatmaRex> gwicke: as in, it can be implemented on top of the widgets system 23:11:50 I don't think anyone is disagreeing with Trevor building a prototype 23:11:57 MatmaRex: I'm just asking for a documentation of what's added 23:12:11 <TimStarling> the textbook solution to conflict resolution is to prototype all the solutions 23:12:15 <James_F> gwicke: No doubt documentation will be written when the code it documents is written. :-) 23:12:17 <MatmaRex> gwicke: i don't think such documentation exists 23:12:20 <TimStarling> so that you can compare them more concretely 23:12:26 <MatmaRex> (yet) 23:12:38 <TimStarling> the theory being that prototyping tends to be cheaper than decision-making pre-prototype 23:12:59 I think we should familiarize ourselves better with knckout, gwicke and mwalker, where should we start reading, looking at code examples? 23:13:11 we should at least have an idea of why we are going to build our own 23:13:18 <TrevorParscal> TimStarling: I don't have a grand plan I'm trying to sell, I'm leaning on expertise at the foundation and planning on starting out with research 23:13:18 rather than using something off the shelf 23:13:38 <TrevorParscal> we aren't at a point where we are deciding whether I should do research or not, it's already been decided that I will 23:13:49 at least I think that it'd be nice to have such an idea 23:13:51 <MatmaRex> gwicke: is there anything that would provide an integrated PHP+JS solution that we want? 23:14:08 Handlebars has light'n'candy. 23:14:17 That's what Flow uses to use the same templates on client and server. 23:14:17 <TrevorParscal> These are all rendering systems 23:14:19 knockout has knockoff / tassembly 23:14:36 <TimStarling> you're saying my opinion on this is irrelevant? 23:14:42 gwicke, Knockoff is Wikimedia-developed, right? 23:14:50 Whereas Knockout is off-the-shelf. 23:15:00 <TrevorParscal> ok, so I'm going to move on from the "please give me more details" point because I've exhausted the point 23:15:01 superm401: yes, it provides the server-side equivalent for Knockout 23:15:12 PHP + JS 23:15:20 gwicke, where can we find some document or code examples which could illustrate better whether knockout/knockoff could be a base for widgets or a replacement for them? 23:15:41 it's fairly easy to support other syntax like Angular too, if that's what we prefer 23:15:44 <TrevorParscal> gwicke: i'm not buying what you are selling, please work with me to include your work instead of trying to prevent me from doing mine 23:16:09 <Scott_WUaS> Please keep this fruitful clarifying conversation going a little longer ... new developing ideas are emerging in this idea sharing ... 23:16:12 <TrevorParscal> we will be including template systems that people are using 23:16:18 <TrevorParscal> and we can add ones that people want to start using 23:16:23 jgonera, Knockout 3.2 will have components: http://www.knockmeout.net/2014/06/knockout-3-2-preview-components.html 23:16:29 Don't know how well they map to our needs. 23:16:35 milimetric could talk a little about them, if he wants. 23:17:01 <TrevorParscal> but a template rendering system is not what I am proposing, they are different in purpose, and the thing I am proposing is informed by building interactive user interfaces not generating static content 23:17:02 TrevorParscal: I'm not trying to prevent you from doing anything 23:17:14 <TrevorParscal> gwicke: i'm glad to hear that 23:17:15 Let's try to be constructive. 23:17:24 TrevorParscal, do you actually know what knockout is? 23:17:33 <James_F> gwicke: You have successfully got TimStarling to declare that there's not consensus. I would very strongly disagree with saying that you're not preventing forward movement. :-) 23:18:13 <TrevorParscal> mwalker: yes, and gwicke has talked to me about it many times 23:18:20 Not sure that's his motivation just because Tim said that. 23:18:26 <TrevorParscal> again, I'm not going to repeat that conversation over and over just because he doesn't like my opinion 23:18:33 TrevorParscal: Is there anyway we could we start with something simple like a prototype which models the watchlist star across all skins? A piece of code paints a 1000 words etc 23:18:38 <TrevorParscal> are there other questions? 23:18:53 I am pretty happy to use Knockoff when it’s ready. Knockout would be great on the front-end for real-time updating of components. While Handlebars (and lightncandy server-side) have been working out pretty well for us on Flow, it’s probably not the easiest-to-use way of going about building an object-oriented, data- and event-driven templating system. 23:18:55 we have about 10 min left in this chat today 23:19:04 i think it's clear that there is general agreement that the skin system needs to be fixed. we are deep deep deep in the weeds of an implementation conversation - i think that TimStarling's earlier suggestion of prototyping various approaches to solving this problem is a really good one 23:19:08 <TrevorParscal> jdlrobson: I'm not sure about those specific examples, but there will be a prototype built, yes 23:19:20 TrevorParscal: we've talked about a front end development group composed of multiple leads being formed at the foundation. would you see this as one of their first projects ? 23:19:27 it will help us get past arguing about implementation details that no one really understands yet 23:19:34 TrevorParscal: i feel like that would be a good idea, as yeh like awjr i worry we have done the usual thing of go into implementation weeds :) 23:19:38 <TrevorParscal> tfinc: yes 23:19:45 I think as far as the core development of this goes, most of us are on the same page. Trevor seems to have a good plan in mind. 23:20:01 <TrevorParscal> I just want to say this: 23:20:20 jdlrobson, this is a technical meeting, so it's not bad to discuss implementation. However, prototypes may indeed be the way to go now. 23:20:23 <TrevorParscal> I'm not doing this alone, and I have done similar projects in the past that have been successful 23:20:42 <TrevorParscal> the reason they have been successful is because I have included many people and considered their individual needs 23:21:11 <TrevorParscal> if you are working on an actual project, and you have actual needs, and you are worried that your needs are being ignored - please talk to me 23:21:13 TrevorParscal: i'm eager to bring engineers to help in this effort. i told Eloquence i would support this. what would you say is the next step for those that want to join you on this projects ? 23:21:24 project* 23:21:47 <TrevorParscal> I'm going to be starting in nearly full time when Roan returns from India 23:21:48 #info lots of agreement that the skin system needs fixing 23:22:03 <TrevorParscal> at that point, I will be sending out information on the mailing list and we can go from there 23:22:04 were all on the same team and i know were all trying to progress things forward 23:22:04 <TimStarling> well, I think engagement with the RFC process implies a sincere desire for the opinions of other people, and, hopefully, a respect for those opinions 23:22:17 <TimStarling> if you don't want any contrary opinions, you shouldn't have an RFC 23:22:36 <TimStarling> you should just do your own thing 23:22:40 <TrevorParscal> You are off base tim 23:22:46 if we go small (watchlist star) no preference, but if we go big with the prototype, I think its a smart call for the team to focus on trying to build winter 23:23:06 <TrevorParscal> Part of solving a problem like this is understanding it, and working with people who are affected by it 23:23:19 jzimmerman, maybe not winter straight away ;) let's say a very basic skin for reading only, maybe 23:23:25 <TrevorParscal> that is what I am talking about 23:23:25 <James_F> jzimmerman: I think taking on a sixth, new skin on top of an existing set of five skins might break the camel's back. 23:23:40 <James_F> jzimmerman: But possibly thereafter, yeah, as jgonera says. 23:23:46 James_F, however, that's part of the RFC already. 23:23:49 James_F you’re fired ;) 23:23:50 "radically different skin" 23:23:58 <TrevorParscal> I think it would be good to work with the design team on what the "other" skin could be 23:24:04 <TrevorParscal> if that is Winter or whatever, I'm open to it 23:24:05 MORE SKINZZZZ 23:24:12 <TrevorParscal> we will see what we can get done 23:24:24 <James_F> superm401: Sure, the RfC is already well-formed and has "do prototypes" and "look at existing needs" written into it, I agree. 23:24:30 <Eloquence> TrevorParscal, it should be a responsive mobile first skin 23:24:32 TrevorParscal: yes, Winter is a natural growth from Vector 23:24:36 if we're going to do a new skin; let's do simple -- something that a developer can use to prototype all new features and that a skin designer can use to change to their liking 23:24:37 =NewSkin 23:24:39 <MatmaRex> jgonera: (reading only? why would that help?) 23:24:40 so TrevorParscal has already expressed that more research needs to be done and i think that that much is very clear based on where this conversation has gone. can i propose that the folks who will be actively working on this spend research time to ultimately inform the implementation details of this rfc? 23:24:42 <TrevorParscal> I don't have a particular plan for the other skin, other than it should work differently enough that it exercises the flexibility of the system 23:24:50 <TrevorParscal> Eloquence: I would agree with that 23:24:50 <Eloquence> and the joint efforts on Winter/Minervea seem to be a lot of groundwork for getting there 23:24:56 oh please no “reader skin” 23:25:23 <TrevorParscal> mwalker: I think having a boilerplate skin would be nice, I think that is what you are talking about, it would take very little effort 23:25:27 MatmaRex, I mean, we don't want to get into all the styling details of special pages, editors and who knows what else just to prove a prototype 23:25:48 #info if we're going to do a new skin; let's do simple -- something that a developer can use to prototype all new features and that a skin designer can use to change to their liking 23:25:52 #info <TrevorParscal> mwalker: I think having a boilerplate skin would be nice, I think that is what you are talking about, it would take very little effort 23:25:54 I don't support releasing a reader skin to production. But if people want to use it as a prototype, that's a different matter. 23:25:55 <MatmaRex> jgonera: implementing the editor means simply allowing a form to be placed on the page instead of paragraphs of text :) 23:26:09 <MatmaRex> (same with special pages) 23:26:21 Quim isn’t here but I know that a highly customizable (color, logo, font) skin with an actual UI for customization is a request he’s gotten a lot from community members 23:26:30 <Carmela> There are open bugs about that. 23:26:35 TrevorParscal, we may not have time for this; but do you have any thoughts on how HtmlForm will play into this? 23:26:40 MatmaRex, superm401 maybe I worded my suggestion in a wrong way, I just want the prototype to stay simple as long as it's a prototype and obviously don't want it in production 23:26:43 <James_F> jzimmerman: Like Wikia's theme-designer? Yeah. 23:26:47 <MatmaRex> right 23:26:48 TrevorParscal: i'm eager to bring engineers to help in this effort. i told Eloquence i would support this. what would you say is the next step for those that want to join you on this projects ? 23:26:50 jgonera, just making sure. 23:26:52 e.g. will we just replace all existing htmlforms with new widgets 23:27:02 #info when Roan returns from India (in a few weeks) Trevor will send out "how you can help" info to wikitech-l 23:27:07 Are we in agreement for mobile-first, or is anyone in favor of desktop-first which responsively scales down? 23:27:11 Eloquence: Minerva is a responsive mobile first skin... so yes it would be a good place to start and iterate from. 23:27:13 James_F: I was thinking even simpler, like tumblrs theme config panels 23:27:35 <TrevorParscal> mwalker: I think HTMLForm can be either left alone or treated as a widget for now, and as UI standardization comes along we can revisit it 23:27:35 <James_F> jzimmerman: Or iYahoo! for those of us with older analogies. ;-) 23:27:44 shahyar: responsive one design, multiple formats 23:27:54 <TimStarling> gwicke: do you need resources for prototyping your own ideas? 23:27:55 <MatmaRex> shahyar: mobile-first could encourage oversimplification, i think we want the system to be flexible? 23:28:02 shahyar: we don’t need to say mobile or desktop first, just a unified theme 23:28:04 shahyar, jdlrobson I'm not sure if we need to discuss that for a simple prototype, it doesn't change anything when it comes to framework implementation 23:28:13 TimStarling: not really- it's just a download at this point 23:28:15 unless you're talking about the next production skin 23:28:28 jgonera: no, you make a very good point 23:28:38 so, we're about to wrap up here 23:28:44 <Eloquence> TrevorParscal, I understand you're open to working closely with jdlrobson jgonera and others from the mobile web team on minerva/winter as a possible skin target? 23:28:48 gwicke, what about resources to expand/complement Knockoff into a skin framewwork? 23:29:19 <TrevorParscal> Eloquence: well we are going to port Minerva, and it would be ideal to work with them on the "other" skin since they have a lot of experience with mobile 23:29:30 superm401: tassembly is just a runtime for one-shot template processing, and knockoff a compiler for knockoutjs templates 23:29:36 Eloquence, I'd assume this would be the case later, just not as the first step 23:29:39 +2 on working together 23:29:52 <Eloquence> I'm not sure why there would need to be an "other" skin? isn't minerva the "other" skin? 23:29:53 gwicke, right, but I'm talking about how it could apply to the skin system overall. 23:29:59 E.g. writing a prototype skin using it. 23:30:07 jgonera: please work with TrevorParscal to scope the goals and lenght of how we would embed you (or kaldari) in this 23:30:09 Eloquence, how Minerva and Winter blend together then? 23:30:18 I guess a blend of those two could be "the new skin" 23:30:28 superm401: a 'skin framework' is higher level, more along components or widgets 23:30:32 "Winter" is a design and a thought process. Minerva is a skin. 23:30:35 tfinc, will do 23:30:42 <TrevorParscal> Eloquence: perhaps we will feel that minerva is different enough that there's no need to make another, but the proposal included this idea because we wanted to have a way to test whether the system was flexible enough to do something radically different 23:30:46 TrevorParscal: would you be open to using the new instance of Phabricator (fab.wmflabs.org) to manage this project? 23:30:52 I expect Minerva will take Winter's design. 23:31:01 does anyone need to leave right now or can we run 10 min over? 23:31:05 <Eloquence> jgonera, I see the goal for Winter to be a prototyping framework that UX designers can use to try ideas (called "snowflakes" in Winter) which are then implemented into proper production level code if they pass user testing 23:31:06 jorm, are you saying there's no overlap in what Minerva and Winter solve? 23:31:22 I think Phabricator would be a great way for us to break apart work to different people who have vastly different schedules in their own products. 23:31:22 I'm not saying that at all. 23:31:36 I'm saying "Minerva is the implementation of Winter". Or maybe it should be. 23:31:36 +1 shahyar! 23:31:39 Eloquence, I don't see why that wouldn't be a part of "the new skin" _ beta features 23:31:42 _ = + 23:31:46 superm401: and there are existing players in that space, like knockout or angular 23:31:55 Eloquence got the right of it. Winter is the toolset to design the next skin. 23:32:00 #info "Winter" is a design and a thought process. Minerva is a skin. 23:32:04 #info Eloquence got the right of it. Winter is the toolset to design the next skin. 23:32:09 #info <Eloquence> jgonera, I see the goal for Winter to be a prototyping framework that UX designers can use to try ideas (called "snowflakes" in Winter) which are then implemented into proper production level code if they pass user testing 23:32:18 +1 23:32:28 well put 23:32:28 <TrevorParscal> I just want to repeat something, the "other" skin that is being proposed is not meant to be the "next" skin 23:32:29 ex-fuckin'-zactly. 23:32:35 #info <TrevorParscal> I just want to repeat something, the "other" skin that is being proposed is not meant to be the "next" skin 23:32:44 <TrevorParscal> and if it gets to be complicated, it won't be, but there's no harm in trying for that 23:33:01 (btw: The winter framework is gonna land in gerrit like, tomorrow or monday.) 23:33:04 <TrevorParscal> So, I want to work with people on that, but I don't want it to slow things down 23:33:21 so anyone can make snowflakes. simple jquery modules + a css file. 23:33:33 jorm, I guess I don't know what Winter is then, any link I where I can read more about it? what is it written in? 23:33:44 javascript and css. 23:33:48 https://www.mediawiki.org/wiki/Winter 23:33:48 so jorm what you are saying is that WINTER IS COMING? 23:33:49 TrevorParscal: would you like me to setup the schedule for the front end devs to meet next ? 23:33:56 you want to find me tomorrow and i can show it to you? 23:34:20 jgonera: unicorn.wmflabs.org/winter-working/index.html?page=Main_Page 23:34:22 tfinc: count me in if you do that 23:34:23 <TrevorParscal> tfinc: I'm not sure about timing yet, but we can talk about it soon 23:34:48 TrevorParscal: just getting it on the calendar gives us a kick to move these discussions as a team 23:34:49 jorm, ok 23:34:54 it can change if we need it to later 23:35:12 eeesh, not so much with the -working url. 23:35:36 TrevorParscal: could be beneficial to meet up and get more technical implementation ideas together before development starts. what do you think? 23:35:38 #action tfinc setting up schedule for frontend devs to meet. (noting this more for posterity's sake than because I think tfinc needs pushing to do it) 23:35:46 <TrevorParscal> tfinc: then set it for after Roan is back... um the 22nd or later 23:36:03 sounds good. 23:36:24 <TrevorParscal> Yeah, well a big meeting is probably not a great idea, probably better to have a few smaller meetings 23:36:27 And you'll keep wikitech updated, right? 23:36:33 guys, something magical just happened. 23:36:41 TrevorParscal: i keep my meetings small and brief 23:36:42 :) 23:36:43 <TrevorParscal> yes, that's going to be the main way I communicate what's going on 23:36:43 we just had a talk about something front-end without it ending horribly 23:36:47 small/short 23:36:56 there was very little yelling 23:37:02 hey, shahyar: FUCK YOU. 23:37:07 and i ruthlessly try to get rid of them as soon as they repeat 23:37:09 lol 23:37:11 :( 23:37:24 thanks all 23:37:27 <TrevorParscal> tfinc: i trust your judgement 23:37:29 <Eloquence> jesus jorm :) 23:37:45 <Eloquence> one bitcoin for the swear jar 23:37:49 <TrevorParscal> ok, end of meeting then 23:37:55 * sumanah believes her tritest-ever Game of Thrones reference saved everything! 23:37:56 <Reedy> Eloquence: I guess WMF don't get the proceeds then? ;) 23:38:10 :) 23:38:29 man. if i had to put money in a wmf swear jar, we'd not need to fundraise. 23:38:48 sumanah, timing is everything. :) 23:38:50 I'm gonna ask for last #info items for a min before ending 23:38:51 <Eloquence> thanks sumanah for facilitating :) 23:39:04 any last things you want in the summary? 23:39:42 thanks everyone. I once again have faith that we can actually collaborate on rectifying this long-overdue issue. 23:39:53 ;) 23:40:30 ok 23:40:33 #endmeeting