[00:10:59] bmansurov: rmoen|afk can you merge https://gerrit.wikimedia.org/r/#/c/229276/ am trying to make it possible for us to merge code again.. [00:11:16] jdlrobson: aye [00:12:33] hey joakino / phuedx|afk When is the search experiment ending? [00:13:50] niedzielski: i'm not sure I'm into that idea. The "last-updated" information is relevant to a sliver of a percent of our users; it's inherently an editing/administrative feature. And having a prominent option to view the page in a browser just sounds... defeatist. [00:15:19] dbrant: ok, that's cool. i asked because i'd never think to look at the bottom of a page for it unless i knew it was there [00:29:48] I don't really understand that feature either, actually. [00:29:57] What use case is it supporting to view the page in the browser? [00:30:07] And for what user group? [00:30:25] Regarding the "last edited", that you need to be *really* careful with. A link to the page history is legal requirement. [00:36:12] Deskana: hm, i'm not sure either. i guess ideally we support at least everything web does but right now we don't [00:36:36] Deskana: so maybe for users that want to use the app for reading but mobweb visual editor for writing? [00:37:40] niedzielski: Good example. But, there are better ways of supporting that use case (e.g. telling people that edit that they can use VE on mobile web), so I'm uncertain of the value of including a link in the footer. [00:38:00] Deskana: oh, well it's fewer clicks if we direct link [00:39:28] True, but that's not necessarily the best way to evaluate whether the feature works for its target audience. [00:40:11] Might be worth you having a more in-depth discussion with Dmitry about it. :-) [00:42:59] Deskana: i'll ask, thanks [00:47:37] kaity: thanks - not everything is in it that we wanted, but hopefully there is enough new to help you get some more ideas. [14:49:13] mdholloway: morning! looks like you'll need to manually rebase your outstanding patches, after yesterday's reshuffling. Gerrit doesn't seem to want to do it automatically. [14:49:22] dbrant: yep [14:49:39] oh - and good morning :) [14:50:08] dbrant: just got an idea for fixing history entry deletion The Easy Way but will rebase shortly! [16:02:14] kristenlans: is there a video call for the strategy thing? [16:02:24] yep in calendar invite [16:02:28] check description phuedx [16:02:33] mibad [16:04:23] joakino jdlrobson ^^ [16:04:34] kristenlans: i'm in the youtube stream [16:04:37] jdlrobson: I saw that you have a conflict w/GSoC; session will be recorded [16:04:38] should i be in the hangout instead? [16:04:40] oh ok cool [16:04:44] jdlrobson: nah [16:04:46] kristenlans: i'm in youtube streams [16:04:47] yes? [16:04:47] just checkin' [16:04:51] kristenlans: i moved the GsoC conflict a bit later [16:04:53] phuedx: same thing happened to me [16:05:12] kristenlans: not seeing anything on youtubes though [16:05:13] dbrant: about "select all" and "web search," it sounds like bearND objects to disabling more than anyone is in favor of it -- mind if we hide the buttons but leave them enabled? [16:05:37] jerkin just making sure you know where to find link, referring to the convo w/phuedx [16:05:38] mdholloway: oh sure, fine with me [16:05:42] hah jerkin! [16:05:58] jdlrobson: just started recording the hangout, should start soon [16:06:02] dbrant: cool, will go back to that when i rebase then [16:06:03] where are we discussing? [16:06:17] oh #wikimedia-office [16:10:56] had to refresh hangout to get it to play [17:03:17] joakino your irc nick gets autocorrected to "jerkin" all the time and it makes me lol [17:03:32] dbrant: not sure if i should rebase this or just abandon it (i'd lean toward the latter): https://gerrit.wikimedia.org/r/#/c/214768/ [17:04:14] ^ niedzielski: i think you wrote up this phab task originally, do you feel strongly abou tit? [17:04:43] https://phabricator.wikimedia.org/T100381 [17:06:20] kristenlans: standup! [17:06:39] kristenlans: lol so true [17:06:43] oh hahah thanks jdlrobson [17:06:51] i'm actually jerkins uncle [17:07:15] mdholloway: i think the latter. if/when we have further discussions with Design about it, we'll still be able to revive this patch, even after it's abandoned. [17:13:59] dbrant: done. [17:20:56] coreyfloyd: standup? [17:36:49] kaity: let me know when you get in [18:01:58] bb folks, have a nice day! [18:17:49] jdlrobson, bmansurov I'm confused about the comments. Should we use .jscsrc and .jshintrc from MF and them upstream to BoilerPlate ? [18:26:03] rmoen: i'm confused after jon's comments too [18:27:07] jdlrobson, bmansurov also maybe it would be nice to have qunit tests running in the gruntfile? [18:27:23] see ya joakino [18:27:25] yes, that would be great [18:27:30] rmoen: ^ [18:27:36] rmoen: it would be nice but i don't think it's necessary at this stage [18:27:39] since we don't have js [18:27:42] yeah [18:28:27] i don't think it's a blocker for merging the patch at least (maybe the task but the task doesn't mention it). [18:55:43] heading off for the evening [18:55:51] i was in a meeting, hence |afk [18:55:55] g'night y'all [18:55:56] <3 [18:58:05] * MaxSem scratches head. anybody remebers when we pulled our BlackBerry app? brion? [18:59:15] somewhere when it either stopped working or BB pulled support for their little tablet :) [19:09:53] woah caffeine, gotta eat some lunch. brb [19:10:22] jdlrobson, bmansurov QuickSurveys updated [19:10:36] cool [19:23:39] nick mdholloway|brb [19:24:31] * mdholloway|brb mashes hands into keyboard repeatedly [20:08:37] bd808 you joinin [20:09:24] sorry, yeah [20:12:19] vibha: kaity http://cl.ly/image/0a32103M2e0b [20:12:23] little teaser ;-) [20:51:01] bgerstle: cool its working!! [20:51:20] getting there ;-) [20:57:36] niedzielski: do you have a minute to hangout in the batcave to show me how you do the https push? [20:58:26] bearND: sure. heads up that it's been a little while since i configured it and i'm running linux [21:05:36] dr0ptp4kt: we have a meeting ? [21:05:45] yep, be on shortly [21:05:48] rmoen: ^ [21:05:58] ok [21:16:52] mhurd: I keep getting some phantom hangout calls from you. If you really want me to join ping me here [21:42:29] does anyone have anything to say on getting the citations/references for a page? [21:42:59] would it be sheer insanity to do it by parsing the HTML via XPath? [21:48:22] bd808: gwicke ^ is the reference list DOM at all stable on MW? [21:48:26] or consistent? [21:49:19] it's in the DOM spec and relied upon by VE [21:49:26] so yes, it's quite stable [21:49:44] gwicke: that true for the non-Parsoid DOM? [21:49:47] https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Ref_and_References [21:49:56] that's not true for PHP parser output [21:50:05] those attributes might not be used [21:50:24] the HTML output isn't at all stable? [21:50:42] there has been some work on bringing the structure closer to what Parsoid emits, but most of the semantic information is missing in the PHP output [21:51:19] the PHP parser output has no spec, it's defined by its implementation [21:51:35] and the structure does change, like recently for citations (to make them more CSS-driven) [21:51:46] hm [21:51:59] well, we're already relying on certain CSS attributes/ids [21:52:33] but even then, these are DOM attributes for a transclusion [21:52:59] i.e. the JSON "schema" of its parameters aren't really defined [21:53:01] or versioned [21:53:12] if you are transforming HTML, you should really be using Parsoid HTML as your starting point [21:53:19] gwicke: not transforming at this point [21:53:20] just extracting [21:53:25] or that, yes [21:53:30] it's the same problem, really [21:53:30] :-( [21:53:35] yeah [21:54:24] gwicke: but what about my point regarding transclusions? [21:54:26] there are also discussions to overhaul the image output to use

and

, like Parsoid already does [21:54:47] the "reflist" div starting tag is HUGE [21:55:02] gwicke: as in, not img tags? [21:55:09] that would *seriously* break the iOS client [21:55:11] is there a ticket for that? [21:55:26] there are img tags, but the divs would be replaced with figure and figcaption [21:55:31] oh ok [21:55:33] that's not so bad [21:55:47] should still work [21:56:30] https://phabricator.wikimedia.org/T51097 [21:58:06] gwicke: hm. . . [21:58:16] so there is a plan to make MW use the parsoid DOM [21:58:22] that's quite interesting.. [21:58:35] i have to ask: will parsoid outlive the convergence? [21:58:36] well, that's not completely nailed down yet [21:58:40] hm [21:58:46] but we have been moving in that direction for a while [21:58:59] seems like it [21:59:38] the long term idea is to eventually switch to HTML as the primary content representation [21:59:49] and use Parsoid as the wikitext editor front-end [22:00:06] using Parsoid HTML for views can already be hacked up now [22:00:17] hm [22:00:57] https://phabricator.wikimedia.org/T106099 is my current favorite idea for that [22:01:26] very interesting [22:01:27] maybe next weekend.. [22:02:46] haha [22:03:40] i forgot what i learned about service workers from jake's demo [22:03:52] but as long as there's something on the server, apps could benefit from it [22:04:11] it's code that can intercept requests to a domain or path prefix [22:04:18] and return cached data? [22:04:28] and do stuff "in the background" right? [22:04:32] yes, and manage the cache / return cached data / assemble stuff on the fly [22:04:44] plus some push notification stuff [22:04:47] right [22:04:58] I'm mostly interested in caching and assembly [22:05:12] the cool part to me is that it's completely transparent to the DOM code [22:05:30] as far as the DOM is concerned, it's separate page views [22:05:52] which can make it simpler in many ways [22:06:13] i'll take your word for it [22:06:28] but there's no way, e.g., for an app to get a list of all the references on a page? [22:06:31] or data for a specific reference [22:06:32] heh [22:06:39] e.g. i download the first section, which contains a citation [22:06:40] user taps it [22:06:42] now what? [22:07:10] there is no API for it right now [22:07:17] but VE will need that data soon [22:07:25] if they decide to go ahead with section editing [22:07:44] they alread extract that info internally, of course [22:07:47] *already [22:08:24] right, so how do they extract it [22:08:25] do you know? [22:08:33] that's what i'm thinking about doing (hence the XPath question) [22:08:47] and unfortunately i don't think it's feasible for us to switch to parsoid atm [22:09:07] i'm thinking about parsing the XPath and if that fails, falling back to the web [22:09:09] the answer might be less useful to you then [22:09:12] and letting the links do their thing [22:09:17] as it does rely on the parsoid metadata [22:09:24] which part of it? [22:09:33] the JSON? [22:09:53] the typeof / rel info, the data-mw attributes, the template metadata [22:10:01] hm [22:10:23] ok, i'm going to mull this over a bit [22:10:38] but i'm thinking that we might need to have a strategy chat soon [22:10:40] about content [22:10:48] did you see cscott's talk at wikimania? [22:10:51] and how we can try to help each other w/ developing on top of parsoid dom [22:10:55] i wasn't at wikimania [22:10:58] he was talking about extraction of things like references [22:11:08] oh, okay [22:11:23] me neither, but I just assume that almost everybody else went ;) [22:11:31] :-P [22:11:43] bgerstle: fyi - https://gerrit.wikimedia.org/r/#/c/228813/ [22:11:48] yeah, i would've hoped we'd go to more of a structured data, then HTML route (at least in some cases) [22:11:54] https://docs.google.com/presentation/d/1lixttQ64-vRcxP5tO3hFuIXzg0lbC__w3g-yLN3K0yU/edit [22:12:03] in a nutshell, hopefully this could be used in future as a way to store coordinates for lead images and with parsoid be able to edit them [22:12:04] and https://docs.google.com/presentation/d/1LHThhO2LFfUb1OnYTtRhvRR7EoKRvMhtTj6TfyOqP5E/edit [22:12:20] jdlrobson: whoa all i saw was "banner" [22:12:33] those are two presentations by cscott & myself with pointers on how to extract stuff from parsoid html [22:12:50] jdlrobson: where would they be stored? [22:12:57] right now i'm suggesting the center is stored as a vector from the center. e.g. 1,1 would be bottom right corner and -1, -1 top left corner [22:13:02] in wikitext bgerstle [22:13:10] gwicke: yeah, don't have access to parsoid DOM atm :-/ [22:13:18] since that seems to be the preferred storage model given that meeting we had ages ago [22:13:20] but we might need to sooner rather than later [22:13:44] but in theory with parsoid we'd be able to create an api end point just to inject those coordinates [22:13:51] and i'm wondering if we should switch to "plain" RESTbase before the content service [22:14:00] anyway just wanted to get you in the loop [22:14:21] jdlrobson: hm... yeah let's keep in touch on this [22:15:17] bgerstle: the content service primarily depends on the service code being ready & ops providing the hardware [22:15:49] I do hope that we can get it deployed this month, but definitely before the end of the quarter [22:16:13] gwicke: yeah, but restbase is already deployed [22:16:23] so if we just hit the HTML route, and extracted data from parsoid DOM [22:16:30] it would still be a step in the right direction [22:16:41] yeah, you could do that [22:16:42] and we could ship our client to production from there [22:16:57] just not the cheapest way to do that from the client if all you want is the citations [22:17:10] gwicke: having a stable DOM will be nice [22:17:16] we're also parsing images, etc. [22:17:25] kaity: i added some comments to https://phabricator.wikimedia.org/T108042 [22:17:38] bgerstle: building VE without some stable spec would have been impossible [22:17:54] gwicke: we've gotten by alright w/o it so far! ;-) [22:18:26] gwicke: TL;DR; what you're saying is: parsoid is what you want, otherwise you're on your own in the wild west [22:18:36] * bgerstle grabs his lasso [22:18:41] time to wrangle me some citations [22:18:51] in any case, don't hesitate to ping me or the parsoid folks like cscott if you have questions about dom structures & plans [22:19:13] gwicke: will do soon [22:19:20] things are in flux in iOS land [22:19:28] parsing folks are in charge of the php part too [22:19:34] once the dust settles and we come up for air i should have a better idea what we're dealing w/ [22:19:45] gwicke: is there a wiki page for these teams? [22:19:53] (link for the lazy? ;-) ) [22:20:46] I think the staff & contractors page is still the most up to date [22:20:56] i meant for the teams [22:20:58] i.e. parsoid team [22:21:00] parsing team [22:21:05] i'll check office/wikitech [22:21:06] https://www.mediawiki.org/wiki/Parsoid [22:21:18] ah ah [22:21:25] I don't think there is a separate one for the more general 'parsing' yet [22:21:35] most efforts are on parsoid [22:21:42] i see [22:21:53] #mediawiki-parsoid [22:22:12] cool [23:10:16] dr0ptp4kt: are we still doing the meeting?