[22:15:14] About 15 min till discussion here of https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework [22:16:27] ah cool [22:16:28] ok [22:19:24] awjr: you may speak [22:19:57] ohai [22:20:01] cool [22:20:06] :) [22:20:45] * awjr high-fives sumanah for her irc level-up [22:20:57] :D thank you awjr [22:21:20] -o sumanah [22:21:26] TrevorParscal: hey there. Ready for you in 10 min. I assume you'll want to start with a sort of speech? [22:22:38] howdy [22:22:45] lol, a speech [22:23:09] hi marktraceur why did you do that? [22:23:19] sumanah: We don't stay opped in here, generally [22:23:28] marktraceur: I'm going to be opped for the duration of the meeting, please [22:23:47] Generally the policy is to op, do what you need to do, then deop. [22:24:04] May I ask for a bending for the next 20 min of this policy? [22:24:25] Do you foresee the need for op action? :? [22:24:27] yes. [22:24:48] Ugh. Go nuts, just be careful [22:24:50] Carry a big stick [22:24:52] maybe sumanah is thinking about using +v? [22:25:10] I think that would help [22:25:11] TimStarling: She's +v'd awjr, so I think she knows the difference. [22:25:31] Oh, I see what you mean [22:25:50] Yes, I just want the option, in my back pocket, for the first 15 min of the meeting, to moderate/voice stuff. I think it won't be necessary after that [22:25:56] thank you [22:26:19] and it may not be necessary at all. I hope it won't. :) [22:26:59] But just in case, preemptive +o. [22:27:14] TrevorParscal: more seriously, do you have some chunk of information to convey at the start of the chat? [22:28:01] I'm not sure I do [22:28:43] TrevorParscal perhaps you can provide an overview of how the rfc has evolved since last time? [22:28:44] I suppose we are just making sure people have an opportunity to discuss their comments/concerns/etc. [22:28:50] awjr: sure [22:29:15] btw, the snake game turned out to be a good test for a number of interesting things :) [22:29:54] just to add my two cents to the discussion that hasn't apparently started [22:29:58] * TimStarling made a snake game once [22:30:00] it's strting now.... [22:30:05] #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:05] sumanah: Error: Can't start another meeting, one is in progress. Use #endmeeting first. [22:30:09] #endmeeting [22:30:09] Meeting ended Thu Jul 10 22:30:09 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:30:09] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-07-09-18.01.html [22:30:09] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-07-09-18.01.txt [22:30:09] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-07-09-18.01.wiki [22:30:10] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-07-09-18.01.log.html [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? [22:34:10] sumanah: let me know when you think I should proceed [22:34:20] Will do TrevorParscal [22:34:24] some of us are still netsplit :/ [22:34:36] wait for the log bot to rejoin if possible [22:34:46] wm-bot is back. [22:34:46] yup [22:35:01] ok, anyway... [22:35:04] not wm-labs-meetbot though? [22:35:10] Good point. [22:35:26] TrevorParscal: hold on 1 more min. [22:35:31] 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:35:34] ok... [22:35:41] maybe it needs a restart? who is responsible for it? [22:36:20] goodie [22:36:21] ok TrevorParscal go ahead [22:36:40] 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: I have been approved to spend 2 months @ 80% on this starting later this month [22:37:11] ok, we good? [22:37:19] Go ahead TrevorParscal [22:37:33] 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] Current chairs: TimStarling brion sumanah [22:38:11] (good, it knows we're in a meeting still) [22:38:33] 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] It's technical debt, not a feature [22:39:03] I think the framing awjr provided on the Talk page makes a lot of sense. [22:39:17] We are in fact cleaning up the technical debt in order to solve a problem that matters to users. [22:39:22] 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] 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] i disagree [22:41:57] (i think enough people who know what they want are involved in this to alleviate that sort of issues) [22:42:10] it would be easy enough to throw in a feature or two to ground it [22:42:40] I don't think feature creep is going to help this project be successful [22:42:41] 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] basically acting as a consumer to test out how it feels [22:42:56] OK, well indeed - did you read the RFC? [22:43:18] me? [22:43:27] 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] 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] 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] 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:19] Also, in the process of porting the four existing skins, that will give us indication if this is a reasonable approach. [22:45:20] 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:34] +1 to superm401 [22:45:45] 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] 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] 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] presumably that would have the usual drawbacks -- flicker, higher bandwidth requirements [22:47:08] That sounds like what TimStarling is saying. [22:47:25] 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] superm401: i think it should be easy to implement this as a separate system, leaving SkinTemplate and its APIs alone [22:47:38] 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] 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] 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] 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] * complementary [22:49:15] 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] do you imagine model transmission to the client would be optional? [22:49:59] 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] there will be no change in user experience [22:50:14] 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] 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] Yes. [22:50:50] * tfinc gets in line for the mic [22:50:51] 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] 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] 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] jorm: the current skin system really does constrain developments [22:52:10] jorm: you surely experienced that with Winter :) [22:52:45] 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] jgonera: please ask your manager if you can get a bug chunk of time to help :) [22:53:03] 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] awjr: how so? existing skins hardly have any features that could creep up here [22:53:51] superm401 i agree :) [22:54:10] (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] anticipating other Wikipedia languages germane to this Skin development RFC conversation?) [22:54:12] 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] 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:54] thanks [22:54:59] superm401 MatmaRex i think shahyar more succinctly stated my point [22:55:20] Scott_WUaS: the problem you are talking about, supporting complex situations, is made better by increasing abstraction [22:55:23] 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] #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] abstraction? [22:55:46] The root is maintainability. [22:56:02] When I made vector, I actually improved the RTL support over monobook - this stuff is really important [22:56:19] TimStarling: there's not much to talk about [22:56:39] any template system can be encapsulated by a view/controller object (widget) [22:56:58] 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] 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] 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:59] 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] 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] 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] 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] handlebars, cool beans [22:59:57] 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] 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] i disagree completely [23:01:19] hrm. i guess we don't have to answer my question. [23:01:33] which was? [23:01:36] 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] 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] 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] 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] 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] 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] brion seems to get it [23:03:57] :) [23:03:59] 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] 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] I see [23:05:09] i think we're talking about things like [23:05:10] jgonera: a widget is not meant to be a 1:1 relationship to an HTML tag, indeed [23:05:10] 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] 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] 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:12] tfinc: I’d definitely like to get involved with the base templating system. [23:06:18] 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] 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:15] and we can play to their strengths [23:07:15] 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] 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] 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] it's called abstraction, and it works very well [23:09:17] sure, but a controller is arbitrary code [23:09:32] if gwicke has an unresolved objection, then we don't have consensus [23:09:48] 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] it is a subset [23:10:32] TimStarling: (consensus doesn't mean unanimous) [23:10:35] 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] MatmaRex: we have a small, competent, heavily involved working group [23:11:07] 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] 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:25] yeah, which is why I am happy for you to build a prototype [23:11:27] gwicke: knockoff is not a Skin system [23:11:34] 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] the textbook solution to conflict resolution is to prototype all the solutions [23:12:15] gwicke: No doubt documentation will be written when the code it documents is written. :-) [23:12:17] gwicke: i don't think such documentation exists [23:12:20] so that you can compare them more concretely [23:12:26] (yet) [23:12:38] 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] 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:19] rather than using something off the shelf [23:13:38] 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] 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] These are all rendering systems [23:14:19] knockout has knockoff / tassembly [23:14:36] 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] 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] 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] Please keep this fruitful clarifying conversation going a little longer ... new developing ideas are emerging in this idea sharing ... [23:16:12] we will be including template systems that people are using [23:16:18] 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] 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] 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] 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:15] 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] 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] 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] 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] 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] 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] I'm not doing this alone, and I have done similar projects in the past that have been successful [23:20:42] the reason they have been successful is because I have included many people and considered their individual needs [23:21:11] 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] 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] 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] 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] if you don't want any contrary opinions, you shouldn't have an RFC [23:22:36] you should just do your own thing [23:22:40] 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] 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] that is what I am talking about [23:23:25] 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] jzimmerman: But possibly thereafter, yeah, as jgonera says. [23:23:46] James_F, however, that's part of the RFC already. [23:23:49]