[22:01:39] * DanielK_WMDE__ wibbles [22:02:01] anyone here for the rfc triaging session? [22:02:19] * DanielK_WMDE needs a minute to figure out meetbot [22:02:40] assuming meetbot is working this week [22:03:22] good point. i don't see it in the roster [22:03:23] meh [22:04:21] ok, so i'll just pretend and grep later. [22:04:41] but it kind of looks like it'll just be us anyway... [22:04:51] #startmeeting [22:04:59] no such luck [22:05:19] heh [22:05:47] #topic rfc boods triage https://phabricator.wikimedia.org/tag/archcom-rfc/ [22:08:10] TimStarling: if nobody shows up, shall we just try and do some triaging now? Or should we just do that async? [22:08:28] we can at least pick one for next week [22:08:37] rather, the week after I guess [22:08:40] indeed [22:09:00] at least pencil something in, in case we don't have an archcom quorum next week either [22:09:18] did you want to look at the ones you're shepherding? [22:09:50] * subbu wanders in [22:10:11] o/ [22:10:22] we can look at the parsing team RFCs as well since we have subbu [22:10:44] TimStarling: we could talk again about per-language urls. it kind of builds down to how important that is. [22:11:06] is that for lang variant output? [22:11:10] actually, we could turn that around into "allow anons to select display language on wikidata" [22:11:30] subbu: not just variants. on wikidata, you see content in your ui language. but only if you log in [22:11:48] would be nice if anons could do that, too. but that breaks the web cache, unless we change the url schema. [22:12:00] I seem to remember there was a lot of bikeshedding about the exact form of the URL [22:12:12] yes. which isn't really the issue. [22:12:27] i want to know how to allow anons to view pages in their language. url or no url [22:12:31] i was thinking of https://phabricator.wikimedia.org/T122942 ... i think you are thinking of https://phabricator.wikimedia.org/T114662 ? [22:12:54] subbu: indeed [22:13:22] on surface reading, they look closely related, or are they not? [22:14:01] probably. currently, user language and content variant are treated completely suparately in core. [22:14:10] but for this use case, they are essentially the same [22:14:35] i would actually like to unify these concepts in core. but it's comploicated... [22:14:54] #startmeeting [22:14:54] bd808: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [22:14:59] subbu: do you have any rfcs that you personally want to push? [22:14:59] #chair DanielK_WMDE [22:15:18] #topic rfc boods triage https://phabricator.wikimedia.org/tag/archcom-rfc/ [22:15:24] oh hey meetbot! [22:15:27] thanks bd808 [22:15:33] #unchair bd808 [22:15:46] ugh, typo [22:15:57] #topic rfc board triage https://phabricator.wikimedia.org/tag/archcom-rfc/ [22:15:59] :) [22:16:07] cscott has promised that we'll have https://gerrit.wikimedia.org/r/#/c/140235/ ready for deploy in the next 3-4 weeks .. so, the natural followup of that is to actually be able to render them .. so, T122942/T114662 would be good to resolve [22:16:08] T122942: RFC: Support language variants in the REST API - https://phabricator.wikimedia.org/T122942 [22:16:14] #startmeeting Archcom triage [22:16:14] Meeting started Wed Nov 16 22:16:14 2016 UTC and is due to finish in 60 minutes. The chair is bd808. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:16:14] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:16:14] The meeting name has been set to 'archcom_triage' [22:16:18] #chair DanielK_WMDE [22:16:18] Current chairs: DanielK_WMDE bd808 [22:16:39] #topic rfc board triage https://phabricator.wikimedia.org/tag/archcom-rfc/ [22:16:43] #unchair bd808 [22:16:43] Current chairs: DanielK_WMDE bd808 [22:17:13] #info briefly touched upon language codes in urls, https://phabricator.wikimedia.org/T122942 and https://phabricator.wikimedia.org/T114662 [22:17:25] subbu: ah, yeah. i mean, i'll implement it w/o an API pro tem, but it would be nice to have an API so it's actually useful to other folks (cough cough google) [22:17:37] other than that, https://phabricator.wikimedia.org/T118517 would be good to pick up in the coming months. but, that might require some work. [22:17:43] cscott, right, that is what i implied. [22:17:59] and MCS [22:18:02] not just google [22:18:39] also the glossary stuff, if we're serious about actually solving problems with language converter eventually. but let's wait until i'm ready to actually implement something there first [22:18:55] ya, glossary stuff comes further along in terms of priority. [22:19:01] glossaries already had one discussion, i think the next discussion would be more fruitful with a proposed patch attached. [22:19:41] subbu: how big is the need for the

thing? what problem does it solve? [22:19:58] we want to move towards making parsoid html be served for reads as well. [22:20:01] cscott, subbu: will you be online this time next week, the day before thanksgiving? [22:20:02] that requires output parit. [22:20:07] *parity [22:20:40] TimStarling: i think not. i'm pretty sure we're planning to flex veteran's day to drive down to NJ on wednesday early [22:20:58] DanielK_WMDE, so, that is a multi-phase process .. and image output parity is one concrete step there. [22:21:01] it's possible we'll actually drive down tuesday night, or arrive early enough wed that i could be online by RFC meeting time. [22:21:18] subbu: ok, i see [22:21:20] TimStarling, i can be around .. i'll be in EST time then. [22:21:50] well, we were thinking of cancelling that meeting unless someone really wanted to have an RFC in that slot [22:22:22] ya, cancelling is fine with me since it is likely going to be sparsely attended. [22:22:45] DanielK_WMDE, https://www.mediawiki.org/wiki/Parsoid/Known_Differences_With_PHP_Parser_Output [22:23:52] subbu, cscott: do you think we can promote the

rfc to "ready for meeting" state? [22:24:06] by when? [22:24:08] then we'll talk about it some time in the next couple of weeks [22:24:14] cscott: now? [22:24:26] ready means we'll schedule it in two weeks' time at the earliest [22:24:31] DanielK_WMDE: i think the consensus at the last meeting was that we could go ahead an unify the PHP and Parsoid output for block-styled figures... [22:24:35] yea [22:24:47] DanielK_WMDE: ...but that we needed to RFC-meet again before we undertook inline-styled figures [22:25:14] so I was content waiting for an RFC meeting until we actually had at least a patch in hand to do the block-figure stuff. [22:25:16] T114662 should also be ready for meeting? (implied to include T122942)? [22:25:16] T114662: RFC: Per-language URLs for multilingual wiki pages - https://phabricator.wikimedia.org/T114662 [22:25:16] T122942: RFC: Support language variants in the REST API - https://phabricator.wikimedia.org/T122942 [22:25:31] cscott: so this is really "in progress" rather than "under discussion"? [22:26:03] DanielK_WMDE: i'm a little oversubscribed, but my priority is the language converter stuff right now, so i'd rather see those get RFC'ed before we switch stacks and look at

again. [22:26:06] cscott, DanielK_WMDE yes, i think that image rfc needs some work ... and i requested cscott to focus on finishing up lang variant work. [22:26:14] TimStarling: nothing changed since we last discussed per-language urls. i would kind of like to turn the rfc on its head for the next round of discussion. [22:26:22] DanielK_WMDE: it's a split status. first part in progress, follow-up work under discussion. [22:26:34] DanielK_WMDE: and we're too lazy to split the phab task ;) [22:26:51] ok. so

will just stay where it is [22:26:58] i'm fine with that [22:27:15] i just flagged the image rfc as next in line after the lang. variant work is done. [22:28:00] TimStarling: i can do that over the next two weeks. we can pencil in per-language-urls, with the option change that by adding ...or some other ways for anons to see stuff in their language [22:28:34] ok [22:28:36] subbu: do you want to have an rfc meeting on the lang variant rfc [22:28:38] ? [22:29:22] DanielK_WMDE, no, no .. i meant the T122942 and T114662 duo. [22:30:05] I'll drag them both in to the ready column [22:30:31] subbu: hm... if we use RestBase for non-wikitext content, than this shouldn't be limited to variants. it should rather be "output language". [22:30:59] TimStarling: ok. we can have a joint session on them. i'll have some comments on the restbase on [22:31:01] e [22:31:09] i have swapped out the contents of those rfcs from main memory. :) so, i cannot comment on that right away. [22:31:40] cscott: what's the status of the clean template stuff? [22:31:49] paused [22:31:52] {{#balance}} you mean? [22:32:00] yes [22:32:24] Balancer is in core now, so the groundwork is laid. It can't really be used in production until we get html5-tidy deployed [22:32:37] ...with may or may not use Balancer in production, depending on [22:33:05] but as subbu says, further work on {{#balance}} is paused while we get html5-tidy worked out. once that's live, then {{#balance}} is easy to build on top of it. [22:33:34] ok, so no need for an rfc meeting now [22:33:44] *nod* [22:33:44] there are some slight questions about what the exact semantics for {{#balance}} should be, but i think everyone agrees that it is easier to implement once we have an accurate tag stack, which is what html5-tidy/Balancer gives us. [22:34:11] I think we're going to talk about some of the semantic issues involved at dev summit as well [22:34:32] i think it's reasonable to say that the correct semantics for {{#balance}} might depend to some degree on what semantics we might want for "wikitext 2.0" [22:34:33] while we are on the topic of wikitext - what about the wikitext spec? https://phabricator.wikimedia.org/T142803 [22:34:52] would it be worth talking about soon? [22:34:52] or maybe the other way around -- the correct semantics of wikitext 2.0 match whatever is most reasonable for {{#balance}} ;) [22:35:17] anyway, it's being discussed at dev summit, we'll have a session on "wikitext 2.0" and template semantics, so i don't think we need an RFC meeting before hand necessarily [22:35:26] DanielK_WMDE, we decided we aren't going to attempt spec-ing "existing" wikitext beyond parser tests. for wt 2.0, yes. [22:35:57] subbu: so is that rfc obsolete then? do you want to close it? [22:36:16] i'll take a look and update it. [22:36:31] * DanielK_WMDE remembers discussing wikitext 2.0 at the CCC in Berlin in 2004 [22:36:41] :-) [22:36:46] yeah. i think we'd learned a bunch since then. [22:36:50] *we've [22:37:32] back then it was a lot saner [22:37:43] parsoid showed that we can actually round-trip in a reasonable fashion between different representations, freeing us up a bit; we learned a lot about where the skeletons are buried in the existing wikitext spec by actually implementing a second parser; etc etc [22:37:48] yea, like "fix it NOW, before it gets even worse!" [22:38:19] * subbu wouldn't have had a job if you guys had fixed it back then [22:38:35] speaking of editors. what about https://phabricator.wikimedia.org/T120414? [22:38:36] just kidding :) [22:38:42] eh, after wikitext 2.0 comes wikitext 3.0. that's the way of things. [22:38:55] maybe we'd be working on wikitext 3.11, the first really good version. ;) [22:38:56] cscott: and 2.0.1, the bugfix release [22:39:10] heh [22:39:23] cscott: what's next? wikitext 95? [22:39:42] ME [22:39:52] oh hey gwicke! [22:39:52] * cscott is afraid that making windows 3.11 references shows him to be a greybeard [22:40:14] cscott: i started on an Apple ][ [22:40:23] i guess this discussion means that we are done triaging? ;) [22:40:36] subbu: no, it just shows we are bing silly. [22:40:45] true ... [22:40:46] no takes for "refactor EditPage"? [22:40:57] shame :) [22:40:58] * subbu cannot read irc tones sometimes [22:41:05] discussion on T120414 seems like it ended with "let's revisit this after MCR" [22:41:06] T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414 [22:41:18] DanielK_WMDE: oh, I actually meant Windows ME ;) [22:41:40] gwicke: yes, i got that. still, nice entry ;) [22:42:01] cscott: it's related, but we can have a pluggable interface before MCR, and it would be useful without MCR. [22:42:10] DanielK_WMDE: my first machine was a VIC-20. And i filled up the RAM the first day I got it. (I think there was only 4K RAM left over for BASIC bytecode, and my first program had lots of strings.) [22:42:35] subbu: I think you were right [22:42:42] DanielK_WMDE: i wouldn't be averse to discussing T120414 further, to see if there are some concrete steps to take pre-MCR. but it needs an owner i think. [22:43:04] it needs someone actually willing to do the refactoring. [22:43:10] though people have been working on it lately [22:43:20] let me find the patch... [22:43:52] the related work mentioned in the comments -- make VE and Parsoid accept pluggable extensions -- is done now, I think. We just need to document it and actually get non-WMF folk to write some cool extension support. [22:44:45] cscott: a nice editor for yurik's tabular data would be a start [22:44:51] or rather "cool parser/editor extensions, as part of their mediawiki Extensions" [22:45:05] and code editor should use that mechanism [22:45:16] DanielK_WMDE, \o/ [22:45:20] can we make that a phab task? [22:45:20] :P [22:45:33] go ahead :) [22:45:45] yurik: any favorite rfcs to push? [22:46:23] we need to tweak some bits of parsoid's deploy in order to actually pull in parser extensions from Extension code, but we haven't done it yet because we don't have a user. tabular data could be the egg that prompts the chicken. (or is it the other way around?) [22:46:36] DanielK_WMDE, https://phabricator.wikimedia.org/T134618 ? [22:47:01] there is no RFC per say [22:47:20] cscott: is that the phab ticket you wanted? --^ [22:47:51] ok, 12 minutes and change [22:47:59] TimStarling: do you have any favorites to push? [22:48:24] no [22:48:31] seems like we have enough [22:48:51] ok, so any dis-favorites to kill? [22:50:40] T91162 -- should it be under "in progress"? [22:50:40] T91162: RFC: Shadow namespaces - https://phabricator.wikimedia.org/T91162 [22:51:04] at least, there are bits of it that are uncontroversial that are in progress [22:51:12] is it actively being worked on?... i was under the impression that it was essentially stalled [22:51:42] maybe subbu has a better idea of that [22:52:03] oh, i found a nice one... "Migrate code review / management from Gerrit to Phabricator" https://phabricator.wikimedia.org/T119908 [22:52:21] sigh [22:52:34] T124243 can be off our board or closed now [22:52:35] T124243: Work out a strategy on Google's AMP - https://phabricator.wikimedia.org/T124243 [22:52:37] haven't my assumptions about the world been upended enough in 2016? [22:52:38] what's the deal with T124792? I thought it's already being implemented, but it's in backlog [22:52:39] T124792: RFC: Service Locator for MediaWiki core - https://phabricator.wikimedia.org/T124792 [22:52:46] btw, i hope everyone saw the announcements about tabular DATA: namespace going live on commons soon [22:52:55] legoktm has been working on pieces of it, yes. once prerequisites are done, i think he will come back in for another rfc session is my understanding. [22:53:40] tabular data has been in wikitech-l and commons pump and fb and SoS and many other places :) [22:53:54] let me know if you see any last moment blockers [22:53:59] SMalyshev: that's actually done. no idea why it's in backlog o_O [22:54:04] i'll remove it [22:54:11] DanielK_WMDE: I suspected so :) [22:54:32] ah well, not all the changes that are listed there have been merged. [22:54:37] so there are bits missing [22:54:44] bit i thin kthe rfc can be closed now [22:56:44] TimStarling: what'S the status on AMP? do you want to close the rfc? [22:57:11] Krinkle is shepherding apparently [22:57:30] Aye [22:57:33] I don't think anyone was really keen about moving it forward [22:57:54] I think our strategy is that we'll learn a few tricks from it and improve our performance overall [22:58:02] But not by using the AMP or Google CDN. [22:58:19] so we could close it then? [22:58:22] that sounds better than letting a random github repo p0wn all of our users [22:58:23] yurik: \o/ [22:58:26] Krinkle: so close it, or take it off the archcom board? or is there anything for archcom to do there? [22:58:56] +1 to closing [22:59:08] I was honestly surprised that we entertained it seriously [22:59:29] ori basically filed it as a devil's advocate, he didn't seem keen about it himself [22:59:41] ok, one minute left. any literal last minute suggestionß [22:59:42] ? [22:59:49] RFC says "My personal views on AMP are mostly negative" :) [23:00:02] heh, nice [23:00:35] ok folks, that's it, then! [23:00:52] thanks for the meeting, i'll be posting the log tomorrow. [23:01:09] #endmeeting [23:01:09] Meeting ended Wed Nov 16 23:01:09 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:01:09] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-11-16-22.16.html [23:01:09] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-11-16-22.16.txt [23:01:09] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-11-16-22.16.wiki [23:01:09] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-11-16-22.16.log.html