< Architecture meetings

22:30 UTC on 10 July 2014, at #wikimedia-office connect.

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).

Summary and 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)
    • <tfinc> "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)
    • <mwalker> 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)
    • <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 (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)
    • <jorm> "Winter" is a design and a thought process. Minerva is a skin. (sumanah, 23:32:00)
    • <jorm> Eloquence got the right of it. Winter is the toolset to design the next skin. (sumanah, 23:32:04)
    • <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 (sumanah, 23:32:09)
    • <TrevorParscal> 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

Meeting logs
22:30:15 <sumanah> #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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:30:15 <wm-labs-meetbot> 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 <sumanah> #chair sumanah brion TimStarling
22:30:21 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
22:30:26 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-10
22:30:28 <brion> \o/
22:30:32 * tfinc grabs a seat
22:30:35 <sumanah> #topic Redo skins proposal
22:30:35 <marktraceur> noobs, geez, leaving the meeting running overnight
22:30:43 <sumanah> #info Today we're talking about revamping MediaWiki's skins systems, and specifically about Trevor Parscal's RfC.
22:30:51 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework
22:30:59 <sumanah> #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 <sumanah> 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 <TrevorParscal> sure
22:31:39 <TrevorParscal> There was some editing on the RFC done by Timo and others
22:31:45 <TrevorParscal> some of which was correct, most was not
22:31:46 <sumanah> 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 <TrevorParscal> I recently (yesterday) rewrote it
22:32:12 <TrevorParscal> it is now correct, and includes more detailed information about what is being proposed
22:32:30 <TimStarling> is this something you have resources for? is it on your quarterly plan?
22:32:30 <TrevorParscal> the problem statement hasn't really changed, but there seems to be some suggestion that it should
22:32:42 <TimStarling> it looks pretty big
22:32:53 <sumanah> hey Tim, maybe let him finish first?
<TrevorParscal> TimStarling: I have been approved to spend 2 months @ 80% on this starting later this month
<shahyar> see what you did
<TrevorParscal> net split :(
<shahyar> trevor you are causing netslips
<marktraceur> God, TimStarling, bringing the wrath of freenode down on us
<shahyar> slips, lol.
<YuviPanda> gah, netsplit
  • TrevorParscal waits
<TrevorParscal> sumanah: let me know when you think I should proceed
<sumanah> Will do TrevorParscal
<legoktm_> some of us are still netsplit :/
<TimStarling> wait for the log bot to rejoin if possible
<marktraceur> wm-bot is back.
<sumanah> yup
<TrevorParscal> ok, anyway...
<TimStarling> not wm-labs-meetbot though?
<marktraceur> Good point.
<sumanah> 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?
22:36:50 <TimStarling> goodie
22:36:50 <sumanah> ok TrevorParscal go ahead
22:36:50 <sumanah> https://tools.wmflabs.org/paste/view/76ace71a is a log of what was said during the netsplit
22:36:53 <sumanah> 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 <sumanah> 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 <tfinc> TimStarling: and mobile will be adding either jgonera or kaldari for a period of time to help
22:38:03 <sumanah> #chair sumanah TimStarling brion
22:38:03 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
22:38:11 <sumanah> (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 <sumanah> (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 <sumanah> ok!
22:40:40 <sumanah> now taking questions for TrevorParscal to answer on https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework
22:40:59 <tfinc> think of it empowering front end developers to more easily, quickly, and consistently iterate on front end features
22:41:15 <awjr> 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 <subbu> 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 <awjr> 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 <shahyar> Wouldn’t building out Winter be the right way to go about this?
22:44:41 <awjr> 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 <superm401> 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 <superm401> Among other things, that may just be too much change at once.
22:45:06 <superm401> The proposal to build a radically different skin should be test enough.
22:45:18 <superm401> 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 <sumanah> "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 <superm401> And porting those 4 is also part of the RFC already.
22:46:02 <jzimmerman> 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 <sumanah> 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 <awjr> 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 <jorm> 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 <superm401> If it's a good architecture, that won't be an excessive amount of effort.
22:46:47 <superm401> And dropping all the other skins again makes this a change management nightmare.
22:46:54 <superm401> We're already going to have change management issues most likely.
22:46:59 <marktraceur> Isn't the point here that the architecture should follow the feature and not the other way around?
22:47:02 <superm401> 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 <marktraceur> 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 <shahyar> 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 <superm401> 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 <superm401> 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 <superm401> 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 <awjr> 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 <superm401> 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 <superm401> awjr, if we don't port existing skins, that means people need to learn two systems to maintain skins.
22:50:01 <jorm> 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 <tfinc> 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 <superm401> 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 <jdlrobson> 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 <jorm> So this is maybe a feature for 3rd party developers, and not us?
22:50:21 <gwicke> 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 <awjr> superm401 not if it's part of a 2.0
22:50:33 <sumanah> 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 <jorm> No, I think we should dogpile.
22:51:06 <jorm> I don't disagree, MZ. I'm talking like a resource manager.
22:51:11 <Carmela> Ah, okay. :-)
22:51:13 <jorm> "is this worth foundation dollars"
22:51:14 <jgonera> 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 <superm401> I don't think we should punt porting the existing skins down the road.
22:51:44 <superm401> If this RFC develops a good skin system, port all of the existing ones.
22:51:48 <superm401> One way to maintain them.
22:51:54 <superm401> And if you want to call it 2.0 when it's done, fine.
22:51:56 <superm401> 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 <jorm> 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 <awjr> 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 <superm401> awjr, if it doesn't allow more than one skin, it's not a skin framework.
22:53:28 <jdlrobson> 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 <tfinc> "and mobile will be adding either jgonera or kaldari for a period of time to help"
22:53:46 <superm401> I don't think it's feature creep to allow more than one skin.
22:53:47 <jgonera> 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 <awjr> 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 <jgonera> 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 <shahyar> 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 <sumanah> 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 <awjr> 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 <awjr> 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 <superm401> awjr, if that were the driving force, there would *be* no project.
22:55:42 <superm401> We already have those skins, so that's not the root of the issue.
22:55:46 <Scott_WUaS> abstraction?
22:55:46 <superm401> 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 <gwicke> 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 <gwicke> 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 <gwicke> I said the same on the talk page
22:58:17 <sumanah> #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 <sumanah> #info <tfinc> "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 <jgonera> 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 <sumanah> tfinc: if you have an additional question I think you can ask it now
23:00:48 <gwicke> 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 <jorm> 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 <sumanah> <jorm> 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 <jorm> 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 <awjr> 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 <awjr> describing
23:02:18 <TrevorParscal> evolving and extending the few we have, yes
23:02:21 <jorm> But I want to know how we can sell spending donor dollars on it.
23:02:22 <brion> we’ll also do “things that fit into skins”
23:02:28 <brion> which’ll be relevant (widgets etc)
23:02:32 <jgonera> 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 <brion> rework the language list? -> widget
23:02:51 <brion> rework the sidebar’s toolbox? -> widget
23:02:57 <brion> rework the person links? -> widget
23:02:57 <sumanah> 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 <jorm> 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 <superm401> 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 <jorm> I am satisfied and happy with the answer.
23:03:51 <TrevorParscal> brion seems to get it
23:03:57 <brion> :)
23:03:59 <TrevorParscal> i'm glad jorm
23:04:04 <jorm> yeah, I get it, too.
23:04:08 <brion> i’m pretty happy with the proposal, don’t have a lot to add
23:04:21 <jorm> me neither; i just am a miser.
23:04:23 <jgonera> 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 <superm401> jgonera, TrevorParscal, can there just be a root widget?
23:04:38 <jgonera> I agree with what you TrevorParscal suggest and understand brion
23:04:40 <superm401> The root widget includes the HTML doctype, skeleton stuff.
23:04:44 <superm401> 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 <jorm> i don't think he's saying "every html tag"
23:04:51 <tfinc> 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 <jgonera> but what about part's that are completely not data driven?
23:05:08 <superm401> jgonera, template?
23:05:08 <TimStarling> I see
23:05:09 <jorm> 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 <jorm> shit like that.
23:05:42 <jorm> am i wrong?
23:05:43 <gwicke> jorm: that sounds like.. web components ;)
23:05:53 <jorm> yeah. in java they're called "Tiles"
23:05:54 <jgonera> 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 <superm401> jgonera, I just said a template.
23:06:11 <shahyar> 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 <jorm> and i love tiles, btw. struts+tiles == awesomesauce.
23:06:28 <jgonera> 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 <jgonera> 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 <jgonera> ok, that sounds good
23:07:48 <gwicke> TrevorParscal: I'm still curious why you dismiss components implemented by a controller object + templates completely
23:08:15 <shahyar> 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 <shahyar> 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 <superm401> jgonera, no problem.
23:08:58 <TrevorParscal> it's called abstraction, and it works very well
23:09:17 <gwicke> 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 <superm401> I think TrevorParscal is saying gwicke's system is a possible implementation of his system.
23:09:54 <superm401> 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 <gwicke> I actually don't have any hand in the Knockout stuff ;)
23:10:50 <gwicke> I'm just pointing out that there are solutions out there that sound like they are doing almost the same thing
23:11:00 <gwicke> 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 <mwalker> 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 <sumanah> I don't think anyone is disagreeing with Trevor building a prototype
23:11:57 <gwicke> 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 <jgonera> I think we should familiarize ourselves better with knckout, gwicke and mwalker, where should we start reading, looking at code examples?
23:13:11 <gwicke> 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 <gwicke> 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 <gwicke> 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 <superm401> Handlebars has light'n'candy.
23:14:17 <superm401> 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 <gwicke> knockout has knockoff / tassembly
23:14:36 <TimStarling> you're saying my opinion on this is irrelevant?
23:14:42 <superm401> gwicke, Knockoff is Wikimedia-developed, right?
23:14:50 <superm401> 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 <gwicke> superm401: yes, it provides the server-side equivalent for Knockout
23:15:12 <gwicke> PHP + JS
23:15:20 <jgonera> 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 <gwicke> 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 <superm401> jgonera, Knockout 3.2 will have components: http://www.knockmeout.net/2014/06/knockout-3-2-preview-components.html
23:16:29 <superm401> Don't know how well they map to our needs.
23:16:35 <superm401> 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 <gwicke> 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 <superm401> Let's try to be constructive.
23:17:24 <mwalker> 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 <superm401> 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 <jdlrobson> 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 <shahyar> 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 <sumanah> we have about 10 min left in this chat today
23:19:04 <awjr> 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 <tfinc> 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 <awjr> it will help us get past arguing about implementation details that no one really understands yet
23:19:34 <jdlrobson> 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 <shahyar> 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 <superm401> 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 <tfinc> 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 <tfinc> project*
23:21:47 <TrevorParscal> I'm going to be starting in nearly full time when Roan returns from India
23:21:48 <sumanah> #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 <tfinc> 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 <jzimmerman> 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 <jgonera> 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 <superm401> James_F, however, that's part of the RFC already.
23:23:49 <jzimmerman> James_F you’re fired ;)
23:23:50 <superm401> "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 <jdlrobson> 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 <jzimmerman> TrevorParscal: yes, Winter is a natural growth from Vector
23:24:36 <mwalker> 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 <jzimmerman> =NewSkin
23:24:39 <MatmaRex> jgonera: (reading only? why would that help?)
23:24:40 <awjr> 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 <jzimmerman> 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 <jgonera> 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 <sumanah> #info <mwalker> 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 <sumanah> #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 <superm401> 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 <jzimmerman> 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 <mwalker> TrevorParscal, we may not have time for this; but do you have any thoughts on how HtmlForm will play into this?
23:26:40 <jgonera> 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 <tfinc> 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 <superm401> jgonera, just making sure.
23:26:52 <mwalker> e.g. will we just replace all existing htmlforms with new widgets
23:27:02 <sumanah> #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 <shahyar> Are we in agreement for mobile-first, or is anyone in favor of desktop-first which responsively scales down?
23:27:11 <jdlrobson> Eloquence: Minerva is a responsive mobile first skin... so yes it would be a good place to start and iterate from.
23:27:13 <jzimmerman> 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 <jzimmerman> 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 <jzimmerman> shahyar: we don’t need to say mobile or desktop first, just a unified theme
23:28:04 <jgonera> 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 <gwicke> TimStarling: not really- it's just a download at this point
23:28:15 <jgonera> unless you're talking about the next production skin
23:28:28 <shahyar> jgonera: no, you make a very good point
23:28:38 <sumanah> 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 <superm401> 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 <gwicke> superm401: tassembly is just a runtime for one-shot template processing, and knockoff a compiler for knockoutjs templates
23:29:36 <jgonera> Eloquence, I'd assume this would be the case later, just not as the first step
23:29:39 <brion> +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 <superm401> gwicke, right, but I'm talking about how it could apply to the skin system overall.
23:29:59 <superm401> E.g. writing a prototype skin using it.
23:30:07 <tfinc> jgonera: please work with TrevorParscal to scope the goals and lenght of how we would embed you (or kaldari) in this
23:30:09 <jgonera> Eloquence, how Minerva and Winter blend together then?
23:30:18 <jgonera> I guess a blend of those two could be "the new skin"
23:30:28 <gwicke> superm401: a 'skin framework' is higher level, more along components or widgets
23:30:32 <jorm> "Winter" is a design and a thought process. Minerva is a skin.
23:30:35 <jgonera> 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 <shahyar> TrevorParscal: would you be open to using the new instance of Phabricator (fab.wmflabs.org) to manage this project?
23:30:52 <jorm> I expect Minerva will take Winter's design.
23:31:01 <sumanah> 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 <jgonera> jorm, are you saying there's no overlap in what Minerva and Winter solve?
23:31:22 <shahyar> 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 <jorm> I'm not saying that at all.
23:31:36 <jorm> I'm saying "Minerva is the implementation of Winter". Or maybe it should be.
23:31:36 <violetto> +1 shahyar!
23:31:39 <jgonera> Eloquence, I don't see why that wouldn't be a part of "the new skin" _ beta features
23:31:42 <jgonera> _ = +
23:31:46 <gwicke> superm401: and there are existing players in that space, like knockout or angular
23:31:55 <jorm> Eloquence got the right of it. Winter is the toolset to design the next skin.
23:32:00 <sumanah> #info <jorm> "Winter" is a design and a thought process. Minerva is a skin.
23:32:04 <sumanah> #info <jorm> Eloquence got the right of it. Winter is the toolset to design the next skin.
23:32:09 <sumanah> #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 <jzimmerman> +1
23:32:28 <brion> 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 <jorm> ex-fuckin'-zactly.
23:32:35 <sumanah> #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 <jorm> (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 <jorm> so anyone can make snowflakes. simple jquery modules + a css file.
23:33:33 <jgonera> 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 <jorm> javascript and css.
23:33:48 <jzimmerman> https://www.mediawiki.org/wiki/Winter
23:33:48 <sumanah> so jorm what you are saying is that WINTER IS COMING?
23:33:49 <tfinc> TrevorParscal: would you like me to setup the schedule for the front end devs to meet next ?
23:33:56 <jorm> you want to find me tomorrow and i can show it to you?
23:34:20 <violetto> jgonera: unicorn.wmflabs.org/winter-working/index.html?page=Main_Page
23:34:22 <shahyar> 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 <tfinc> TrevorParscal: just getting it on the calendar gives us a kick to move these discussions as a team
23:34:49 <jgonera> jorm, ok
23:34:54 <tfinc> it can change if we need it to later
23:35:12 <jorm> eeesh, not so much with the -working url.
23:35:36 <shahyar> TrevorParscal: could be beneficial to meet up and get more technical implementation ideas together before development starts. what do you think?
23:35:38 <sumanah> #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 <shahyar> 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 <superm401> And you'll keep wikitech updated, right?
23:36:33 <shahyar> guys, something magical just happened.
23:36:41 <tfinc> TrevorParscal: i keep my meetings small and brief
23:36:42 <tfinc> :)
23:36:43 <TrevorParscal> yes, that's going to be the main way I communicate what's going on
23:36:43 <shahyar> we just had a talk about something front-end without it ending horribly
23:36:47 <tfinc> small/short
23:36:56 <jzimmerman> there was very little yelling
23:37:02 <jorm> hey, shahyar: FUCK YOU.
23:37:07 <tfinc> and i ruthlessly try to get rid of them as soon as they repeat
23:37:09 <brion> lol
23:37:11 <shahyar> :(
23:37:24 <jzimmerman> 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 <brion> :)
23:38:29 <jorm> man. if i had to put money in a wmf swear jar, we'd not need to fundraise.
23:38:48 <superm401> sumanah, timing is everything. :)
23:38:50 <sumanah> I'm gonna ask for last #info items for a min before ending
23:38:51 <Eloquence> thanks sumanah for facilitating :)
23:39:04 <sumanah> any last things you want in the summary?
23:39:42 <shahyar> thanks everyone. I once again have faith that we can actually collaborate on rectifying this long-overdue issue.
23:39:53 <jgonera> ;)
23:40:30 <sumanah> ok
23:40:33 <sumanah> #endmeeting
This article is issued from Mediawiki. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.