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:16 ...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:35 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:37 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:29 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:02 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:26 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