[00:27:13] dr0ptp4kt: JonKatz mhurd_afk let's go upstairs and miiiix [00:28:05] mbinder I like your style. let's do this. [00:40:20] jhobs: do you know how many labels we can show to the user in the survey? (I'm not talking about the survey that will go out tomorrow, thinking about the future) [00:41:40] lzia: I'm not sure what you mean by "labels", can you explain? [00:42:03] tags, I mean, jhobs. [00:42:19] if we ask a question, and we show some tags to the user and the user can chose one or more of those tags, [00:42:25] like choices? [00:42:44] Yeah ok, um I'm not sure what the limit is, if there even is one [00:43:32] I'm no longer at my computer, but I can check tomorrow and comment on the task lzia [00:43:44] whom should I ask jhobs? [00:45:44] bmansurov might know and he might be back online later. With jdlrobson on vacation there's not really any engineers working around this time right now :/ [00:47:54] lzia: I just happen to check my phone every now and then :) [00:48:04] thanks jhobs. [00:59:50] o/ [09:24:23] o/ [10:07:01] \o [10:07:14] this is pretty awesome https://github.com/martanne/vis/ [10:07:21] nice source read [10:14:29] hello king [10:15:23] hi bman [10:16:42] yeah that is pretty amazing by the looks of it [10:25:38] there is also https://neovim.io [10:25:41] a fork of vim [10:48:54] yeah neovim works great [10:49:06] there's only one think I miss, but otherwise awesome [10:49:28] vis is more a small modern C vi that you can read the source of [12:04:59] quick lunch with the fam [12:40:21] by "quick", i mean "long and messy" [15:06:59] joakino: +1 thanks for sharing vis [15:07:51] phuedx: joakino i have a question about pic of the day. are you familiar with it? [15:08:56] a little bit [15:09:02] bgerstle: insofar as i know what it is :/ [15:09:12] made a demo for a clojurescript workshop [15:09:21] api is shit [15:09:31] eym a xprrrt [15:09:32] joakino: then maybe you're the person to ask [15:09:38] in that there is no api, totally adhoc [15:09:43] joakino: yes [15:09:47] found as much w/ TFA [15:09:56] if there isn't a startup called "xprrrt", i'm creating it [15:10:25] joakino: if i asked you to get a thumbnail for the current POTD, plus the source article title, and ideally the caption... how would you do it? [15:10:38] or, who would you ask to do it? ;-) [15:10:49] in as few round trips as possible [15:12:52] bgerstle: from restbase you can get name, thumbnail (fixed by restbase), caption and little more [15:13:18] then you'd need to query for individual images for more stuff [15:13:28] https://github.com/joakin/photo-of-the-day/blob/master/src/photo_of_the_day/api.cljs [15:14:04] I remember I tried expand template but that gives you the html and can't pass it to a generator or anything [15:14:41] pageimages doesnlt work with the template page iirc [15:14:54] bgerstle: construct an iso 8601 date and hit up https://en.wikipedia.org/wiki/Template:POTD/2015-11-19?action=raw [15:15:07] :P [15:15:08] i don't want raw wikitext [15:15:16] phuedx: is there a way to get just the rendered HTML? [15:15:27] would i need to call the parse API? [15:15:32] https://en.wikipedia.org/wiki/Template:POTD/2015-11-19?action=render [15:15:36] joakino: i can get "images" [15:15:41] use restbase [15:15:42] but that only returns the File: of the pic [15:15:49] phuedx: 👍 [15:16:31] i wonder what restbase does… [15:17:29] joakino: i'm getting errors for "invalid revision" [15:17:33] http://restbase.wikimedia.org/es.wikipedia.org/v1/page/html/Template:Potd/2015-11-19 [15:17:39] oh whoops wrong wiki [15:17:47] still no dice [15:17:58] ah you're doing that on commons [15:19:02] https://commons.wikimedia.org/api/rest_v1/page/html/Template:Potd%2F2015-09-25 [15:19:06] also, i like that we're proxying restbase off of the wikis [15:19:20] encode the slash on the page title [15:19:28] yeah [15:19:42] REST + multi-component resources = no fun [15:20:07] * bgerstle recalls ranting that we should be using pageids for everything at some point [15:20:51] joakino: so, restbase doesn't _quite_ help me in this situation, i don't think [15:21:11] there are so many links, i'm reluctant to try to parse out the underlying page link [15:21:28] although i can get the template params.. [15:21:33] * bgerstle tries getting data-parsoid for that page [15:22:29] nope, not what i want [15:22:35] all i really want are the template params for that page [15:22:40] which tells me everything i need [15:26:15] bgerstle: please share your solution, I'm interested on this kind of stuff [15:26:46] joakino: i was getting desperate last night: https://en.wikipedia.org/w/index.php?title=User:BGerstle_(WMF)/POTD_test&action=render [15:27:11] (ab)using the template to make my OWN DOM w/ specific elements that contain the POTD data i need [15:28:07] magic! [15:28:17] it's templates all the way down haha [15:28:35] joakino: pretty much [15:28:41] joakino: if you can't beat 'em, join 'em [15:33:58] joakino: one thing i found: is that apparently a lot of these {{#time}} based templates use server time [15:34:07] while i was online last night, i was already seeing tomorrow's POTD [15:34:21] (and maybe TFA too, but i don't remember) [15:34:32] might need to file an issue for that [15:34:35] Happy Birthday bearND! 🎂 [15:34:43] ah happy birthday! [15:35:18] bearND: from me as well [15:35:26] bgerstle: good luck with that template task [15:35:46] gwicke: thanks! [15:35:49] bearND: oh yeah, happy birthday! [15:36:02] gwicke: is there a way to retrieve _only_ the template data for a specific template usage on a page? [15:36:12] gwicke: or would i need to get the whole page and parse out the mw-data myself? [15:36:39] re time, it's been a known design issue for a long time, e.g. https://phabricator.wikimedia.org/T21992, https://phabricator.wikimedia.org/T20478 [15:36:46] gwicke: figured as much [15:37:45] bgerstle: right now, there is no efficient way to identify things that are time-dependent [15:38:24] identifying page components is a general need though, so I think we should find a general solution [15:38:32] bearND has similar needs for i18n [15:38:40] gwicke: fwiw, that doesn't really affect me (time-based) [15:38:50] gwicke: POTD already has date-specific pages [15:39:16] there are lots of those, including [[Main_Page]] [15:39:33] gwicke: all the POTD "data" is in those pages, as each one only consists of the POTD template w/ special args for that day's POTD w/ a caption,e tc. [15:39:39] we don't even keep track of how long a fragment should live [15:39:57] gwicke: right, AFAICT all the archives etc. are curated manually [15:40:06] kristenlans: gwicke mdholloway: thank you [15:40:19] e.g. november's POTD page is just a page w/ all that month's POTD pages manually transcluded [15:40:28] and there are cron scripts to re-render some special cases like [[Main Page]] once per 24 hours [15:40:46] in short: it's all duck tape and chewing gum [15:41:01] https://en.wikipedia.org/wiki/Wikipedia:Picture_of_the_day/November_2015?action=raw [15:41:13] gwicke: yeah, so far "In the news" is the most impressive [15:41:16] it's just one page [15:41:27] when you change it, you need to blast the main page cache [15:41:42] so even the archived main pages have the content for _today's_ ITN page [15:41:51] * bgerstle applies palm to face [15:41:53] that's actually good for main page, as it'll also update the podt.. [15:42:28] in a very localized definition of 'good' [15:43:37] lol [15:44:00] bgerstle: I think it might be interesting to mark up time-changing templates & other interesting components using HTML elements [15:44:07] those are very efficient to match [15:44:07] maybe [15:44:32] example: https://phabricator.wikimedia.org/T105845#1650013 [15:44:59] yeah, that ticket def caught my interest [15:45:19] I created a small library to efficiently hook up handlers to those: https://github.com/wikimedia/elematch [15:46:08] gwicke: i just think we need a better way to store structured data and use it in templates [15:46:16] e.g. all teh POTD stuff should be a database [15:46:20] not a series of pages [15:46:26] same w/ TFA, etc. [15:46:48] that's fairly orthogonal to the cache / vary issue, though [15:47:41] even if you format this in a widget & pull the data from a URL or other structured storage, you'll need to figure out which fragment to update to show the current time or apply i18n [15:48:55] most efforts in that area are now using web components / custom elements [15:49:06] gwicke: yeah, but it's crucial for separating the data from presentation [15:49:49] it's almost like XHTML's revenge: hey, you can embed custom elements in your page & have them be treated as first-class citizens [15:50:18] bgerstle: agreed [15:50:27] also, for sane editing [15:50:32] yeah [15:50:38] and a lot more freedom in how you can re-format things [15:50:51] yep [15:55:25] we are spending significant $ on indiscriminate template re-rendering, and are still getting a very static result [15:57:46] joakino: do you have some time to catch up in the next days? [15:58:01] we once had a proof of concept using XML / XSLT in the browser [15:58:02] was neat [15:58:32] the XSLT define the layout and you get the pieces of content via GET of XML files. SO in theory the templates could be an independent GET [15:58:37] and the composition is done in the browser [15:58:42] was fun and fast [15:59:03] after you downloaded that 4mb XSLT file that somebody slaved to write ;) [15:59:15] (purely made-up numbers) [15:59:27] hehe [15:59:55] well we could have it cached in LocalStorage and use some custom protocol to update it with diffs patches [15:59:58] forget me [16:00:01] but yeah, the software industry moves in cycles [16:00:29] I am sure one day we will see something that let you grab only differences when your local caches is outdated [16:00:37] instead of invalidating the whole file and having to fetch it all again [16:00:39] bgerstle: this is the datastructure i was parsing out of the restbase page of the potd http://codepen.io/anon/pen/NGJoKq/ [16:00:50] gwicke: yeah, i've seen a couple of adam's emails, still have to read them! [16:01:25] hashar, speaking of diff transmission: https://phabricator.wikimedia.org/T118028 [16:01:56] 3:40:47 PM in short: it's all duck tape and chewing gum [16:02:12] * phuedx pops over to a t-shirt screen printer before the dev summit [16:02:19] gwicke: tl dr ;-} [16:02:21] tl;dr: for small messages, deflate with a shared dictionary can be interesting [16:02:37] how many folk are going to the dev summit? how many t-shirts will we need printing? [16:02:41] I know you have version x, so I compress against x too [16:02:46] I have read a paper about folks normalizing URLs so they can end up being cached [16:03:30] because ?params=zoo|bar&query=foo and ?query=foo¶ms=bar|zoo might well end up serving the same content [16:03:55] so the cache normalize the URL before doing a cache lookup. I should find the paper [16:05:16] joakino: I have some other meetings this morning, but nothing tomorrow; can do really early if that helps to avoid [16:05:19] Friday night [16:06:31] phuedx: ;) [16:06:47] i'm not available tomorrow gwicke, is it ok if we do it next week? [16:07:30] joakino: sure, can I just schedule something earlyish when there's nothing in your calendar? [16:07:45] gwicke: yes please! [16:07:48] thanks! [16:08:00] kk [16:11:03] sent [16:11:24] also, please add anybody you think should be there [16:13:10] having an early dinner with the fam [16:29:00] hi jhobs [16:29:09] I need some hand-holding here. :-) [16:29:39] Is the issue that FR is running tests and our survey may collide with a FR banner, jhobs? [16:49:56] gwicke: any idea why https://en.wikipedia.org/api/rest_v1/page/html/User:BGerstle_(WMF)%2FPOTD_test/691405745 doesn't render the image, i.e. not recursively parsing the transclusion? [16:50:11] compared to: https://en.wikipedia.org/w/index.php?title=User:BGerstle_(WMF)/POTD_test&oldid=691405745&action=render [16:51:27] joakino: bd808 is there a way to suppress the rendering comments for ?action=render [16:51:41] i.e. "NewPP limit report" [16:53:16] bgerstle: nope. that's a server side setting ($wgEnableParserLimitReporting) [16:54:02] k [16:54:25] only a few extra bytes, i guess [17:00:05] MaxSem if you have a minute, can you answer a question about EN Wiki POTD? mhurd suggested i ask you about it [17:03:30] leila: I would imagine the high priority SWATs only rule is simply due to the thanksgiving holiday, but I don't know for sure. Hopefully Greg will reply on the task with more info [17:10:32] got it, jhobs. [17:13:12] you joakino and gwicke i emailed on the thread started yesterday w/ joakino - but i'm interested to attend whatever meeting you guys setup...if i'm booked, just mark me optional. this stuff is exciting! i'm pumped! [17:14:42] s/you/yo/ :) [17:39:27] dbrant|brb: Just trying out Nearby with the Mapbox upgrade. It's really nice. [17:43:00] mdholloway: thx! [17:45:04] dbrant: OK to merge? [17:46:04] mdholloway: i think so... as long as you verify it with runtime permissions [17:48:04] dbrant|brb: i'll do a bit more testing around the runtime permission [17:48:59] dbrant|brb: i just managed to crash the app by turning off the location permission and returning to the app with the nearby activity open [17:54:35] dbrant|brb: https://rink.hockeyapp.net/manage/apps/226653/app_versions/5/crash_reasons/58982313 [17:54:45] dbrant|brb: otherwise looks good [18:39:47] bgerstle_lunch: that looks like a parsoid bug to me [18:39:53] mind reporting it? [18:40:02] gwicke: sure [18:40:09] thanks! [18:44:06] bgerstle, sorry I wasn't available [18:44:10] what was the question [18:44:12] ? [19:04:44] i'm out for the day [19:05:07] maxsem if you knew of a reliable way to get specific info about POTD [19:05:20] MaxSem: like the template params [19:05:31] MaxSem: caption, image, titletext, etc. [19:05:57] nope, it's just what you have [19:06:31] because it was made to be easily attachable to existing main pages infrastructure [19:06:47] but that also means that lots of stuff is just not know [19:06:50] n [19:32:01] jhobs: can I bug you? ;-) [19:36:46] Hi greg-g. Re T118881, are we saying that we cannot start a test today and finish it on 11/23? [19:43:57] i'm beat [20:37:38] lzia: oh, that's fine, I thought the idea was for the 30th? [20:37:43] * greg-g may have misread/understood [20:49:19] got a bit of phabricator vandalism going on lately, it seems [20:49:30] https://phabricator.wikimedia.org/T119039 [20:49:39] https://phabricator.wikimedia.org/p/Amgad/ [20:52:35] greg-g: that may have been my miscommunication/misunderstanding [20:57:28] mdholloway: for the record, please report that in -devtools [20:58:40] greg-g: ah, thanks, good to know, just joined [20:58:59] mdholloway: I just messaged them via Phabricator [20:59:39] greg-g: cool, thank you [21:00:03] np [21:00:25] atgomez: you in office today? [21:28:45] MaxSem: sorry, just saw your responses. thanks! [21:41:30] heading out to pack and get on a plane. i'll be working later while in the air. peace! [21:52:49] hey there [21:53:06] hi jgirault ! [21:53:14] * dr0ptp4kt waves [21:56:45] Had a question about QuickSurveys, dr0ptp4kt redirected me here, and referred me to jhobs , so here i am, and here is the question: I need to specify a privacy policy link for a quick survey we want to roll out as soon as possible/next couple days. But looking at the code, I don't seem able to set `policyPrivacy` param for "internal" surveys. Is it by [21:56:45] design? Should I amend the code to allow that? How can I change the link at the survey footer? [21:57:29] the privacy link is: https://wikimediafoundation.org/wiki/Quick_Survey_Privacy_Statement [22:07:44] jhobs: yt? :-) [22:26:55] leila: sorry, apparently I had accidentally muted my computer and didn't hear the pings. [22:27:06] :D [22:27:22] np, jhobs. so, I'm hearing that if you can make it happen, we can deploy it at 4pm today? [22:27:30] jgirault: ^. Privacy policies are only viewable on external surveys, yes. You would have to modify the code to include one, or include it in the description [22:27:36] greg-g is cool with taking it down on Monday or Tuesday, jhobs. [22:27:47] leila: yeah that's fine, I'll add to deployment schedule [22:27:48] and we want to take it down on Monday anyway, jhobs. Can you make it happen? [22:28:10] a huge hug jhobs. thank you! :-) [22:28:15] * greg-g looks in and smiles [22:28:49] leila: no problem, sorry I missed your pings for so long! [22:29:29] np. :-) [22:29:38] :D [22:29:50] atgomez: exciting news in this channel. ;-) [22:30:16] yay! [22:30:22] jhobs: I really hope you guys don't hate me. :D These are good stuff. I want to present them to you. I'll present the first version in the lightning talks next week. [22:30:40] jhobs jgirault on the "internal" survey i'm also seeing a privacy policy link. am i misunderstanding the question? [22:30:44] that link should be customizable [22:31:05] https://www.evernote.com/l/ADs8e7GPjc9PjoJlnFoTY7p_GmRYBAzpgPU [22:31:11] leila: hahaha of course not! I would love to run as many surveys as possible. After December it'll be much easier to run stuff too. [22:36:39] atgomez jgirault: that's a default message for internal surveys that is not a customizable link. I'll see if there's a way to customize it though [22:36:52] hmmm.. thanks jhobs. [22:37:04] and yay for surveys! [22:37:46] we probably need that link to be customizable in the future, though we may be able to repurpose the same privacy policy for the couple of surveys we're squeezing in before December [22:47:05] the message used in the footer is: ext-quicksurveys-survey-privacy-policy-default-text [22:47:25] you can customize it for external surveys only [22:48:20] I guess for now it is fine to just change that message to point to our privacy policy [22:49:36] jgirault: You can override the default privacy policy message for internal surveys programmatically [22:50:00] bearND: hey! i had a question for you on maven repositories. was there a restriction on f-droid and which repositories we were allowed to use in our build scripts? i seemed to recall something like that. [22:50:23] jgirault: by overriding the "footer" key in the defaults config [22:51:54] niedzielski: hmm, they don't like custom mvn repos. What do you have in mind? [22:52:29] bearND: well, i was hoping we could use https://jitpack.io/ to get the latest sdk-manager gradle plugin [22:56:43] It's best if you check with mvdan on #fdroid about that. [22:56:55] bearND: ok thanks [22:57:58] jhobs: what do you mean by overriding? by changing this key directly https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/resources/ext.quicksurveys.views/QuickSurvey.js#L28 ? [22:58:06] or the message associated to it? [22:58:31] because only external surveys support overriding gracefully: https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/resources/ext.quicksurveys.views/ExternalSurvey.js#L18 [22:58:49] jgirault: yes, only external surveys support it gracefully. [22:59:12] I meant you could change the key directly in the constructor [22:59:25] or rather after constructing it [22:59:39] so like this.defaults.templateData.footer = "" [22:59:54] except mySurvey instead of this (doh) [23:00:38] well, that would work if I was constructing it myself [23:01:11] but in practice I let this line do: https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/resources/ext.quicksurveys.lib/lib.js#L120 [23:02:04] jgirault: oh ok I misunderstood, I thought you were injecting the survey into the page yourself [23:03:26] is it better practice? I was thinking just appending quicksurvey=X to the article page to show my survey [23:03:34] doing it here: https://gerrit.wikimedia.org/r/#/c/254089/ [23:04:09] it has the problem to break caching :s [23:04:32] jgirault: no the way you're doing it is fine, other than yeah it breaks caching and has the URL param for sharing [23:04:40] jgirault: but you could do it either way [23:04:58] jgirault: i'm looking for a way to override the footer more gracefully right now [23:04:59] I'm cleaning up the url to fix sharing issues [23:05:25] nice [23:07:57] jhobs: I have another question: is it possible to specify the schema? I see in in the document examples, but don't see it in the code [23:10:20] ideally I would need to specify an extra param containing a searchSessionId (random id generated during the search satisfaction tests) because the ID would allow to link the answers collected with all the other data collected [23:13:32] jgirault: i don't think it's possible to specify the schema, unfortunately :/ I'll take another look at the documentation [23:14:03] jgirault: you could, however, update the schema to a new revision with the searchSessionId and update the code accordingly [23:14:27] jgirault: scratch that, not everyone would have a searchSessionId for all surveys *facepalm* [23:14:41] yeah :/ [23:15:15] jgirault: where in the documentation are you seeing that? I'm not seeing it anywhere on mw.org/Extension:QuickSurveys] [23:15:19] but maybe if we call it just "sessionId" it makes it more userful/powerful [23:16:02] in the example given in the readme https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/README.md [23:20:24] jgirault: yeah, custom schema would require a code change. I think the main reason is that any schema that wasn't identical or a subset of the current one would need additional code to log the new params [23:20:32] jhobs: what about an optional "sessionId" to the schema? [23:21:45] jgirault: as long as it's available on every page, I don't see a reason why not. atgomez1 or leila, would having an additional field in the EventLogging results affect you in any negative way? [23:25:04] jhobs i can't imagine a problem with that [23:28:05] jhobs: I have the code to support privacyPolicy param on internal survey, I can make a patch [23:28:28] jgirault: go for it! Sorry, I'm also prepping for deployment [23:29:01] jhobs: np