tags for MediaWiki sections - https://phabricator.wikimedia.org/T114072 [22:31:39] I currently have that on my list [22:31:49] (T114072) [22:31:49] T114072:

tags for MediaWiki sections - https://phabricator.wikimedia.org/T114072 [22:31:52] and yes, i haven't fully fleshed out the ideas since I started writing this up in 2015 .. but I can spend some more time on it .. but yes, it is a bit researchy still. [22:32:02] should I just be the shepherd for all the parsing team ones except the ones that authored or am implementing? [22:32:09] +1 [22:32:19] metashepherd [22:32:25] sounds good to me [22:32:41] next up: T120414 [22:32:41] T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414 [22:34:31] James_F: we're triaging, and now your ears should be officially burning. (ArchCom so declares) [22:34:34] it blocks https://phabricator.wikimedia.org/T28918 which blocks a few others like CodeEditor , edit toolbar [22:35:00] robla: Yeah yeah. :-) [22:35:38] yay, refactor EditPage! [22:35:40] (I don't have a real plan for that RfC; it's mostly an "ideas please" call.) [22:35:49] James_F: we're mainly trying to figure out which ArchCom member should be responsible for shepherding this, and we're seeing who blinks first [22:35:56] DanielK_WMDE: Yay, **kill** EditPage, I think you mean. [22:35:58] James_F: multi content revisions should factor into the design [22:36:08] I don't know what the process is here (sorry, just joining now), but as for sheperd for the Gerrit->Differential RFC, I can take that. [22:36:17] robla: DanielK_WMDE was the first person to speak up, and yeah, multi-content-revisions will have major impacts. [22:36:23] (I may have jumped the gun) [22:37:02] greg-g: we do have a question about whether or not a shepherd should be someone outside of ArchCom. I've been sheepish about taking on responsibilities myself [22:37:10] (see what I did there....HAHAHAHAHA) [22:37:17] * greg-g groans [22:37:19] :) [22:37:26] could also be a member of a working group. but we don't have those yet, so... [22:37:28] #dadjokes [22:37:31] T120414 is of great interest to me but my schedule's filling up so i can't take it [22:37:31] T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414 [22:37:33] haha [22:37:36] do blocked RFCs need a shepherd? [22:37:47] hmmm [22:37:56] TimStarling: I suppose we could declare this blocked/stalled. Should we do that? [22:38:02] well if it's mostly 'wait for James_F to write more notes' then we can live :D [22:38:08] just don't want it to drop totally on the floor [22:38:19] so keep it in needs shepherd for now? [22:38:30] Surely stalled RfCs need someone championing them more than ones being pushed themselves? [22:38:49] James_F, robla: i can shepherd the plugable editor thing, i think [22:39:05] DanielK_WMDE: Awesome. [22:39:08] actually, that would be really helpful for structured data on common, too [22:39:16] yeah main thing is make sure it doesn't get forgotten [22:39:23] that can either be a shepherd poking, or a calendar reminder :) [22:39:39] James_F: which means: poke me about it ;) [22:39:58] * James_F grins. [22:39:58] Will do. [22:40:00] \o. [22:40:05] .o/ [22:40:11] wooooooo [22:40:22] ^oo^ [22:40:24] * brion wonders if meetbot understands ascii art [22:40:32] patches welcome! [22:40:45] next up: T120380 [22:40:45] T120380: RFC: Allow JSON values to be included in the API results - https://phabricator.wikimedia.org/T120380 [22:40:46] i was going to type 'lol' but rob knows that's a lie [22:40:56] next up: T120380 [22:40:56] T120380: RFC: Allow JSON values to be included in the API results - https://phabricator.wikimedia.org/T120380 [22:41:18] * robla laughs on brion's behalf [22:41:23] eh, I think that one is blocked on me reviewing that patch [22:41:42] this one seems to be mostly a discussion between Brad & Yuri / Max at this point [22:41:51] about the implementation [22:42:14] it was also discussed in person during the dev summit a bit (informally) [22:43:01] are we planning to kill xml output in api still? or is that a 'someday wish' [22:43:21] the json-in-xml feels odd to me though i think it makes sense to enduser maybe [22:43:31] though i'd rather just not have to ever encounter it and use json directly [22:43:36] brion: yea, i just thought that [22:43:42] we dropped a few esoteric formats based on usage analysis [22:43:45] gwicke: should we say it's under discussion? (and declare a shepherd) or should we say it's "stalled" and put it in the backlog? [22:43:57] iirc xml has not been considered for dropping because it had a fair % of usage [22:43:59] there are no plans to kill xml right now [22:44:00] we have a generic json-to-xml mapping mechanism right there. we could just apply it. [22:44:07] I think the problems with keeping XML were worked around so it stopped being so urgent to get rid of it [22:44:12] ^ [22:44:16] robla: it's an instance of a recurring theme [22:44:30] then folks will start requesting msgpack .. [22:44:48] DanielK_WMDE: as a practical matter as a user, i probably wouldn't want to deal with an xml representation of a potentially large/scary/domain-specific json blob [22:45:11] * robla will declare this as "stalled" at 22:46 UTC unless a shepherd volunteers [22:45:14] given how long this discussion has been going on, it seems unlikely that there is going to be consensus very soon; so, I guess "blocked" is accurate [22:45:15] but then as the same user why would i want to deal with xml at all :D [22:45:20] *nod* [22:45:36] brion: but is a json representation of that scary blob really better? [22:46:01] DanielK_WMDE: conceptually it's a message passthrough. we can continue this on the bug if you want [22:46:05] need ot keep the meeting moving :) [22:46:09] next up: T114454 [22:46:11] T114454: [RFC] Visual Templates: Authoring templates with Visual Editor - https://phabricator.wikimedia.org/T114454 [22:46:28] brion: yea, i'm torn on the issue myself [22:46:38] both options seem nasty :D [22:46:55] robla: very researchy / pie-in-the-sky [22:47:01] this one had a dev summit discussion, correct? [22:47:40] seems like another one to declare blocked/stalled [22:47:54] unless a shepherd wants to volunteer [22:47:59] it is in the (Missing active discussion) column of wikidev summit workboard [22:48:06] so maybe no discussion happened [22:48:17] robla: seems fair [22:48:44] * robla sets off to do that. feel free to discuss next one [22:48:52] seems like the proposal would require a big change in how the preprocessor works [22:49:11] lots of fun. html/dom based transclusion. would be nice. [22:49:34] next up: T119908 [22:49:34] T119908: [RfC]: Migrate code review / management to Phabricator from Gerrit - https://phabricator.wikimedia.org/T119908 [22:49:42] (since robla busy) [22:49:53] This is the one greg-g wanted to run. [22:49:56] the migration got presented at the dev summit [22:49:57] it got consensus / was uneventful (i.e. no drama) [22:50:08] releng is already implementing steps to move from Gerrit to PHabricator [22:50:10] whee [22:50:18] is code review better in Phab? [22:50:21] greg-g confirmed me is ok being a sheperd for it [22:50:21] I mean, if it needs me to, officially (not sure exactly what "shepherd" means in this context) [22:50:35] now is this mostly a publicize/confirm support for further work? [22:50:39] or are there questions/actions? [22:50:41] with #releng team for implementation. So I would move that RFC to Approved [22:50:43] SMalyshev: pretty fair to say "yes", I think :) [22:50:54] cool [22:51:08] brion: there might be some further questions re some process details [22:51:21] but they're mostly minor at this point [22:51:28] SMalyshev: it has the same issue as other systems: you still need folks to review :-} Overall it is fully integrated within Phabricator and will tremendously help to sync with tasks [22:51:35] greg-g: are you looking for ArchCom to bless this, or is this a RelEng internal thing? [22:51:56] I think an blessing would be much appreciated and helpful [22:52:11] * greg-g offers hashar's head to dip in the water [22:52:12] yeah bless us with your magic wand please [22:52:15] hashar: well, I guess we just need to add a module that would track down people and make them review things :) then it'd be perfect [22:52:27] I think having an ArchCom shepherd step up would be good then. I think I can volunteer to shepherd [22:52:32] awesome [22:52:45] sweet [22:52:46] SMalyshev: there might be a karma based system to prevent you from proposing code until you get enough review done ;-} (dont quote me ! ) [22:53:00] \O/ [22:53:15] SMalyshev: drones. [22:53:19] hashar: hmmm... 3 reviews for each commit... sounds interesting ;) [22:53:25] what codes around, comes around [22:53:26] next up: T114251 [22:53:26] T114251: [RFC] Magic Infobox implementation - https://phabricator.wikimedia.org/T114251 [22:53:47] looks like DanielK_WMDE's area [22:54:22] DanielK_WMDE: is this one you could shepherd? [22:54:36] well yes. but my plate is pretty full. i don't have a good idea of how much work shepherding actually is. so i'm reluctant, though i'm really interested. [22:55:08] Isn't it stalled? No comment since our chats in October… [22:55:09] inactive RFCs are easy to shepherd ;) [22:55:13] do we have to bump it a bit down the road? [22:55:23] check back in 30/60/90 days? [22:55:25] should we declare it stalled? [22:55:38] stalled/backlog [22:55:44] * robla sets about doing that [22:55:47] James_F: it was discussed at the summit... [22:56:21] DanielK_WMDE: I thought we talked about a related but slightly different task? But yeah, point. [22:56:41] i can poke hoo about it. [22:56:49] which i guess means i'm shepherding it. [22:57:00] ok....I'm going to call an end to this meeting in a couple of minutes [22:57:31] we almost made it through the whole column [22:57:37] thanks everyone! [22:58:10] awesome :) [22:58:12] I'm going to be working with dstrine and TPG on further streamlining, but this feels pretty good [22:58:30] thanks for chairing, rob! [22:58:45] thank you! [22:58:48] no problem! [22:58:53] very happy to see this ArchComm rolling [22:59:13] I am super happy we have such a committee around [22:59:17] ending meeting in 45 seconds.... [22:59:24] Thanks, All, for this organizational shepherding focus! [22:59:44] my inclination would be to de-prioritize T114457 [22:59:44] T114457: [RFC] Use `npm install mediawiki-express` as basis for all-in-one install of MediaWiki+services - https://phabricator.wikimedia.org/T114457 [22:59:47] 15 seconds.... [22:59:59] #endmeeting [23:00:00] Meeting ended Wed Mar 2 22:59:59 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:00:00] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-02-22.01.html [23:00:00] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-02-22.01.txt [23:00:00] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-02-22.01.wiki [23:00:00] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-02-22.01.log.html [23:00:16] meetbot is off by 1 second ...