[21:00:02] https://phabricator.wikimedia.org/E187 coming up.... [21:00:44] #startmeeting E187 ArchCom-RFC triage meeting [21:00:44] Meeting started Wed May 25 21:00:44 2016 UTC and is due to finish in 60 minutes. The chair is robla. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:44] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:44] The meeting name has been set to 'e187_archcom_rfc_triage_meeting' [21:01:33] #topic E187 ArchCom-RFC meeting - Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:02:04] hi folks! [21:02:44] Hi [21:03:07] :) [21:04:45] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_triage_2016-05-25 [21:05:16] is the idea to assign priorities? [21:05:38] TimStarling: yeah, I think there's a couple of things I'd like to accomplish: [21:05:55] 1. Assign priorities for the "Backlog" items that say "need triage" [21:06:07] 2. Pick a good candidate for next week's IRC meeting [21:06:22] so....let's start with the top of the list I just linked to: [21:06:35] T128602 [21:06:35] T128602: Create and deploy an extension that implements an authenticated key-value store. - https://phabricator.wikimedia.org/T128602 [21:07:45] TimStarling: gwicke : Krinkle : is T128602 one that we just discussed in our meeting in the last hour today? [21:07:45] T128602: Create and deploy an extension that implements an authenticated key-value store. - https://phabricator.wikimedia.org/T128602 [21:08:00] don't think so [21:08:33] * gwicke does not think so either [21:08:56] all the discussion was in march apparently [21:09:34] is brion here? [21:09:52] or tgr, Krenair, dbrant [21:11:01] perhaps we can set it to "normal" or "low" priority, and wait for objection? [21:11:02] I think this RFC would not be controversial if it were discussed [21:11:14] yeah, low priority [21:11:46] it needs a committed client, once it has one of those, the priority can be higher [21:11:54] k....next on the list: T120380 [21:11:54] T120380: RFC: Allow JSON values to be included in the API results - https://phabricator.wikimedia.org/T120380 [21:12:55] I'll summon yurik [21:13:17] ...and he's not online :P [21:13:42] ok....normal? low? high? [21:14:18] I think normal? there is conflict, which probably makes it more our responsibility than the implementor's [21:14:42] anomie seems to be dead against it [21:14:44] normal it is [21:15:17] ok, next up: T119050 [21:15:17] T119050: Parametric JSON builder - https://phabricator.wikimedia.org/T119050 [21:15:21] same story with that one? [21:16:11] * robla prepares to say "yes" and move on [21:16:47] ok.... normal for 119050. Next up: T117550 [21:16:48] T117550: [RFC] Content bundler - https://phabricator.wikimedia.org/T117550 [21:17:06] that one is hexmode 's. Is he around? [21:18:44] can you remind me what the criteria are for choosing the priority? [21:19:34] TimStarling: good point. I'm thinking priority should have a bit of a temporal element to it for our purposes [21:19:58] something which needs to be discussed soon? [21:20:37] I think this is low priority [21:21:02] yeah, so basically we should say this: "High" means "let's dedicate a meeting in the next 1-3 months (if not next week) [21:21:14] on the basis that it may be superseded by shadow namespaces, and nobody is really pushing for it [21:21:29] "Medium" means "we really should resolve this by the end of the calendar year" [21:21:41] we can discuss whether the requirements were met after shadow namespaces is done [21:22:36] ok...so, 117550 we can say is "low" priority, pending shadow namespaces [21:22:57] Next up: T114640 [21:22:58] T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis - https://phabricator.wikimedia.org/T114640 [21:22:58] there is also a connection to OCG's bundler stuff [21:23:57] high? seeing as daniel keeps talking about it, and cscott is promising to prototype it (as of a month ago) [21:24:28] * cscott delurks [21:24:53] * robla waves at cscott [21:25:28] high priority for 114640 then? Sounds good to me [21:25:34] next up.... [21:25:38] oh, right, the {{#lang}} thing. Yeah, I could totally whip up a prototype for that.... [21:25:43] cscott: we are choosing priorities for RFCs, where priority has some kind of relationship to meeting scheduling [21:26:05] one way or another it would be good to straighten out this whole "user interface language" thing. [21:26:23] I'm starting to think that we generally need to come up with a high-level strategy for how multi-lingual content should interact with caching & parsing [21:26:24] so high = a relatively high chance of being scheduled in the next few months [21:26:36] sure, just give me, say, 2 weeks notice before we schedule 114640 for discussion and i ought to be able to whip up a prototype to discuss. [21:26:39] these RFCs that focus on a part of the problem seem to be too narrow [21:27:04] we have had that come up repeatedly in the last weeks [21:27:13] cscott: do you have any RFCs you would like to see discussed soon, e.g. next week? [21:27:14] gwicke: sure, the point of the prototype is mostly to learn-by-doing and understand the problem better. in my case at least. [21:27:18] next week's slot is empty [21:27:40] TimStarling: i won't be able to attend the meeting next week, alas. [21:27:45] i will be in bermuda [21:27:54] poor you [21:27:55] on a big boat [21:28:08] ;.( [21:28:41] next week's meeting: https://phabricator.wikimedia.org/E198 [21:29:14] (it's boilerplate right now....let's figure out a candidate for next week) [21:29:51] gwicke: without going too off-topic for your scheduling meeting, i agree that there are large issues related to how commons and wikidata handle multilingual content... and how they mix UX (via templates) and "content". [21:30:11] anyway, it looks like 114640 (or any of cscott's) are bad choices. We'll set T114640 to high, and maybe move on [21:30:11] T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis - https://phabricator.wikimedia.org/T114640 [21:30:14] cscott: the elephant in the room is caching & fragmentation [21:30:47] currently, none of the proposals seem to address that seriously [21:30:49] yeah, it may be worth trying to build new tools that let commons/wikidata/etc construct UX in a caching-friendly way. [21:31:37] cscott: next up: T114454 [21:31:38] T114454: [RFC] Visual Templates: Authoring templates with Visual Editor - https://phabricator.wikimedia.org/T114454 [21:31:38] some sort of template system that lives between the existing handlebars templates and the existing wikitext templates, perhaps. [21:31:45] oh, speak of the devil! ;) [21:32:19] cscott: we're using this as the list, and you're name is on there a lot :-) https://www.mediawiki.org/wiki/Architecture_meetings/RFC_triage_2016-05-25 [21:32:42] here maybe i'll take gwicke's point and say it would be good from an RFC perspective to have a higher-level discussion about templates and components and caching. [21:32:57] pretty obvious who the author is when it talks about templates being "hygenic by default" [21:33:29] oh, i thought i'd scrubbed the word "hygenic" from all my proposals [21:33:38] :-) [21:34:03] I think this is low? pretty old and not recently discussed in the parsing team [21:34:29] priority of T114454 , "low", plus a comment "please file a bigger picture RFC so that we can block this RFC with that RFC? [21:34:30] T114454: [RFC] Visual Templates: Authoring templates with Visual Editor - https://phabricator.wikimedia.org/T114454 [21:34:34] one of those things I think i want to take an afternoon to implement before discussing it further [21:34:46] robla: i'm pretty sure gwicke already has a bigger picture rfc for that [21:35:01] cscott: which one? [21:35:10] "page components"/templates [21:35:30] that's more focused on content, and not so much on UI [21:35:54] the client-side front-end one is the UI complement [21:36:03] cscott: Phab task? [21:36:12] i had an unconference session at the all-hands on the visual templates stuff and it went terribly, turns out everyone who signed up assumed i was going to teach them to use mediawiki's existing template system, not propose some new doesn't-exist-yet hotness [21:36:24] https://phabricator.wikimedia.org/T111588 [21:36:31] so in the unconference spirit the session got redirected to match what people actually wanted [21:36:54] (gwicke: can you please share some URLs that currently focus "multi-lingual content should interact with caching & parsing"?) [21:36:56] it's not specifically targeted at i18n currently [21:37:09] Scott_WUaS: that's daniel's RFCs [21:37:28] Scott_WUaS: T114662 and T114640 [21:37:28] T114662: RFC: Per-language URLs for multilingual wiki pages - https://phabricator.wikimedia.org/T114662 [21:37:28] T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis - https://phabricator.wikimedia.org/T114640 [21:37:42] gwicke has commented on both of those, i believe, bringing up the caching issue [21:37:48] Thnx:) [21:37:58] T114432 is next on the list, I thought it was a nice idea, but reception at the dev summit was mixed IIRC, and then there was no further discussion after that, so I guess it is low [21:37:58] T114432: [RFC] Heredoc arguments for templates (aka "hygenic" or "long" arguments) - https://phabricator.wikimedia.org/T114432 [21:38:12] https://phabricator.wikimedia.org/T99088 has some high-level thoughts on the general problem area [21:39:35] I think T114432 actually had a meh reaction more than a negative one. i don't think people were opposed, but there is a very vocal contingent who reacts negatively whenever anything is said "to make things easier for visual editor" [21:39:36] T114432: [RFC] Heredoc arguments for templates (aka "hygenic" or "long" arguments) - https://phabricator.wikimedia.org/T114432 [21:40:15] cscott: right, but are you disagreeing with TimStarling's proposed "low" priority? [21:40:18] it looks like pretty arcane addition to already quite arcane syntax [21:40:36] it might be useful to think through & write down how an API-driven frontend could help i18n specifically [21:41:12] robla: "low" seems right to me, i'm not blocked on further rfc discussion [21:41:36] thanks cscott - ok, next up: [21:41:50] T114421 [21:41:50] T114421: [RFC] Optional Travis integration for Jenkins - https://phabricator.wikimedia.org/T114421 [21:42:00] also cscott :-) [21:42:35] i still use my npm-travis tool, but ops seems violently opposed. [21:42:54] containerized test jobs is always right around the corner, and will eliminate any need for travis, i'm told. [21:43:14] cscott: is that going to be in perpetual "agree to disagree" state, or do you see a way forward? [21:43:56] well, i don't have the appetite to fight that particular battle myself. it seems that teams are just going around ops and using travis if they need it. [21:44:22] that seems dysfunctional, but it's a dysfunction i'm not in a good place to address. it's not entirely clear that the RFC process is a good way to address it either. [21:44:22] cscott: is *ops* really opposed? I only see releng on the task [21:44:27] so i'd say status "stalled" [21:45:02] priority is "low" for ArchCom, I think....it may even be one that we take ourselves off of [21:45:26] hehe [21:45:27] yeah. [21:45:45] ok, next up [21:45:56] T114394 [21:45:56] T114394: RFC: PageLookup service and PageRecord object - https://phabricator.wikimedia.org/T114394 [21:46:04] with 15 minutes left, should we soon talk about scheduling for next week? [21:46:05] at the time in the flush of early excitement about the rfc process i may have abused it to try to settle impasses ;) [21:46:19] i think my rfcs are done, right? [21:46:38] cscott: yup [21:46:38] cscott: yes [21:47:17] recapping from my perspective only, i think prototyping {{#lang}} (or whatever) was the only thing that rose to 'high' priority? [21:47:24] TimStarling: good point. So....we didn't hit paydirt on anything we talked about yet as a candidate for next week [21:47:56] anyone have a nomination for next week? [21:48:05] T91137? [21:48:05] T91137: RFC: Support a branching content history model - https://phabricator.wikimedia.org/T91137 [21:48:12] although i'd like to be there for that one as well, i guess. [21:48:37] T351 is mine too, i think, don't know why Qgil's name is associated. [21:48:37] T351: RfC: Square bounding boxes - https://phabricator.wikimedia.org/T351 [21:48:56] what about T96384? that seems like it should be straightforward perhaps? [21:48:56] T96384: Integrate file revisions with description page history - https://phabricator.wikimedia.org/T96384 [21:49:03] the low-numbered RFCs were copied from the wiki by qgil [21:49:06] that's a @daniel rfc [21:49:08] T382 looks like an interesting choice [21:49:09] T382: RfC: Server-side Javascript error logging - https://phabricator.wikimedia.org/T382 [21:49:31] cscott: we probably shouldn't choose one of yours if you're out next week [21:50:43] robla: yeah, that's why i nominated a T96384, a @daniel RFC. dunno his availability. [21:50:43] T96384: Integrate file revisions with description page history - https://phabricator.wikimedia.org/T96384 [21:51:48] hm, there's a @csteipp RFC as well, maybe that's worth getting to before he transitions out of the WMF headspace? T75953 [21:51:48] T75953: RFC: MediaWiki HTTPS policy - https://phabricator.wikimedia.org/T75953 [21:52:11] it will probably be harder to get his participation if that if deferred for a few months [21:53:41] ok....maybe in general I can take it as an action to figure out a security related RFC for next week. We also have T135963 as a recent one that has big implications worth discussing [21:53:41] T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963 [21:54:05] sounds good [21:54:25] Krinkle basically advised that we hold off a little bit on that one, though. He's going to be shepherding it. Still I'll be happy to own figuring this out [21:54:41] maybe csteipp will have an idea for a task which is not even tagged as an RFC yet [21:54:51] robla, why did Krinkle advise holding off? [21:55:26] he has 53 tasks assigned to him [21:55:28] dapatrick - I think just because he had only just volunteered to shepherd, and I had just put him on the spot with "how about next week?" [21:55:35] dapatrick: I'm not advising to hold off on the project in general. Merely holding off on scheduling the IRC meeting as I familiarise myself with the task. [21:55:40] 1 week :) [21:55:48] authored 100 [21:56:07] csteipp authored 100 open tasks [21:56:21] robla, Krinkle I see. [21:56:24] +1 to robla's plan to triage csteipp [21:56:55] and maybe T135963 for the week after that, it can be a security fest ;) [21:56:55] T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki - https://phabricator.wikimedia.org/T135963 [21:57:11] ok....so....I think we're done with the realtime portion of the meeting. However, we also have Z425 as a place to continue this conversation in a less synchronous fashion [21:57:33] #link https://phabricator.wikimedia.org/Z425 [21:57:53] #info triage discussion can continue on Z425 [21:58:13] (Great process emerging here re Phabricator - thanks, all!) [21:58:28] any last minute comments/questions/concerns before I officially end this meeting? [21:59:21] * robla might actually end it *dozens of seconds* early [21:59:38] #endmeeting [21:59:40] Meeting ended Wed May 25 21:59:38 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [21:59:40] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-05-25-21.00.html [21:59:40] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-05-25-21.00.txt [21:59:40] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-05-25-21.00.wiki [21:59:40] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-05-25-21.00.log.html