[21:01:16] hi Architecture Committee, are you meeting today? [21:01:41] yes [21:01:46] #startmeeting RFC meeting [21:01:46] Meeting started Wed Jan 7 21:01:46 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:47] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:47] The meeting name has been set to 'rfc_meeting' [21:02:22] #topic Hierator | 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:29] #link https://www.mediawiki.org/wiki/Requests_for_comment/Hierator [21:03:17] this is a proposal to replace wikihiero with a java service that generates SVG files [21:04:18] not wikihiero itself, but its html-based renderer [21:04:35] so wikihiero will be the client? [21:05:04] yes [21:05:08] <^d> MaxSem: Can we name it Hieroid instead? #important [21:05:17] but it's not javascript! [21:05:24] oid = javascript right? [21:05:26] ^d, nevar! it's not in node [21:05:30] * TimStarling is maybe confused [21:05:45] <^d> I thought -oid meant "new and fancy" :) [21:06:05] on the RFC MaxSem asked about possible sharing of an existing Java web server [21:06:15] ^d: do we have any of those? [21:06:34] <^d> Not a generic tomcat-type thing. Our Java things mostly run embedded servers. [21:06:39] <^d> ie: jetty or somesuch [21:07:13] jetty shoul run servlets, no? [21:07:28] <^d> It can, but we don't run it like that. Emphasis was on "embedeed" [21:07:41] <^d> embedded even [21:07:59] you know in https://phabricator.wikimedia.org/T989 I am pondering the idea of adding a java web service [21:08:24] <^d> Having a shared jetty/tomcat/etc container for things like this isn't a bad idea. [21:08:34] <^d> Gerrit can technically run in a container, even though we don't currently. [21:09:02] does gerrit need anything special locally, like fast disks? [21:09:29] <^d> It needs ssds. [21:09:32] <^d> So yeah [21:09:52] so maybe everything except gerrit [21:09:54] and search of course [21:10:17] which is currently an empty set but will presumably have some things added to it [21:10:30] <^d> Well we've got two decent proposals here that could share. [21:11:15] MaxSem: for storing the SVGs in swift, I suppose you have seen how Math does it? [21:11:39] yep, looked at it [21:11:47] <^d> fwiw, there's already a java swift library if you end up needing it. [21:11:52] you know I also did swift storage for the lilypond extension (Score) [21:11:56] <^d> we use it in Elastic for backups [21:12:09] there was an alarming amount of code duplication with Math [21:12:10] still am in early stages of implementation, so not very versed in this stuff [21:12:45] ^d, I'd rather do it in MW [21:12:53] <^d> Either way, just throwing it out there :) [21:13:05] :) [21:13:17] ideally the file backend code in Score/Math would be factored out into core to avoid another 500 lines of code duplication [21:13:31] and to allow these kinds of services to be added more easily [21:13:37] because it was technically quite tricky [21:14:15] <^d> So, nobody's spoken up other than us 3. I guess we have consensus that this is a good idea and we're just talking implementation details now? [21:15:00] yep, consensus of the entire MW community currently consisting of 3 people [21:15:06] <^d> Go team [21:15:18] Daniel and Mark gave their apologies btw, it is late for them [21:15:19] 3? [21:15:55] ok, I'll mark it approved [21:15:55] Let me see if I understand, this is... [21:16:24] is there a phab task for "factor out the file backend code in Score/Math into core"? [21:16:24] A proposal to have a backend java that can make .svg from images? [21:16:33] +1 [21:16:59] .svg from Manuel de Codage texts [21:17:03] Is that correct? [21:17:03] ^d: some of us just like to lurk :P [21:17:26] <^d> Silence is consent :) [21:17:30] #info set up a generic java servlet cluster, just JSesh so far, but maybe in the future things like CSS validation [21:18:12] anyone has any preference on tomcat/jetty/whatever? [21:18:19] #info would be nice to factor out shared code between Math and Score into core and also use that for Hierator [21:18:38] MaxSem: that question needs ops involvement which I don't think we have here [21:19:20] #info MaxSem would like to use MW as the swift client rather than have the servlet directly contact swift [21:20:02] <^d> MaxSem: my experiences with tomcat have been nothing but painful, so I'd vote jetty. but like Tim says it's ops' decision really. [21:20:42] T13|naps: the proposal is to have a java backend that makes .svg from Manuel de Codage hieroglyph syntax [21:20:50] yep, i'm familiar with jetty a bit from solr, didn't have any problems with it [21:21:49] we can discuss it, I just don't think we can make it a firm decision without ops consent [21:22:23] I used jetty once, for ehcache [21:22:29] Servlet containers running mixed applications can be a pain in the butt. Hopefully we have some ops experience that can help pick the "right" one or recommend stand alone deploys if that's better. [21:22:38] we deployed ehcache for a few days, then it broke and we reverted it [21:22:43] +1 [21:23:18] I filed a bug against jetty because when it runs out of file descriptors it explodes [21:23:35] like, goes into a busy loop [21:23:47] which prevents it from freeing said file descriptors [21:24:11] <^d> Ugh, fd's on jetty. hit that on gerrit before. [21:24:20] heh. i think jsesh rendering code doesn't need any disk access at all [21:26:00] whereas tomcat just lets the file descriptor exhaustion exceptions propagate, so it breaks in a more obvious and temporary way [21:27:05] #agreed approved (Tim, Chad, Kunal, T13) [21:27:28] bd808|LUNCH, do you have any comments in deployment methods? [21:27:41] s/in/on/ [21:28:00] I guess that depends on the container at bit [21:28:18] <^d> We can build java stuff via our archiva repo and deploy with git-deploy & git-fat [21:28:22] trebuchet knows how to sling jar files around [21:28:22] <^d> Although git-fat kind of sucks. [21:28:49] it is better than putting jars in git :) [21:30:00] The last time I was deploying servlet type stuff was loooong ago. I used ant tasks to upload the jars to the containers back then. [21:31:30] MaxSem: In general I think you need to find a java savvy opsen to work on the server details with you. I bet we have somebody [21:31:51] jgage might be a good bet [21:33:51] ok, are we all done? [21:34:26] #endmeeting [21:34:26] Meeting ended Wed Jan 7 21:34:26 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [21:34:26] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-01-07-21.01.html [21:34:26] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-01-07-21.01.txt [21:34:26] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-01-07-21.01.wiki [21:34:26] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-01-07-21.01.log.html [21:35:14] <^d> TimStarling: That the only one this week? [21:35:20] yes [21:35:38] <^d> Ok, guess we're done then [21:35:42] thanks, ppl! :) [21:35:45] next week's draft agenda: [21:35:49] * https://www.mediawiki.org/wiki/Requests_for_comment/Guidelines_for_extracting,_publishing_and_managing_libraries [21:35:49] * https://www.mediawiki.org/wiki/Requests_for_comment/Service-oriented_architecture_authentication [21:36:23] so bd808, gwicke and csteipp [21:36:26] \o/ I guess that will get some comment on my ramblings [21:40:27] MaxSem: Heirator project needs logo, e.g. https://www.google.com/search?q=Walk+Egyptian&tbm=isch :) [21:44:36] TimStarling hi. What was Sumana's involvement in the RFC process? [21:45:11] Sumana used to schedule meetings and take notes and such [21:45:17] now the architecture committee does that [21:45:37] She was really good about poking people to follow up on commitments too. [21:46:36] one of the main reasons for setting up the architecture committee in its current form and having weekly committee meetings was to replace sumana who didn't want to do it anymore [21:47:33] TimStarling: As the new tech writer I'm happy to contribute when approved RFCs mean documentation needs to be updated. I'm not sure about poking people. [21:48:52] you could have a look at https://www.mediawiki.org/wiki/Architecture_committee/Weekly_tasks [21:49:13] maybe there are some things on that list that would fall into your new job description [21:50:22] there are a couple of links to [[RFC metadata]] -- it's partly broken at the moment due to MZMcBride's changes, but I will fix that [21:51:13] TimStarling: thanks, I'm reading it. [21:58:33] Hi all! VisualEditor office hour in a few minutes here! [21:59:15] James_F: are you ready? :) [22:00:52] Thank you, ChanServ. [22:01:33] hi and welcome everybody! [22:01:38] long time no see. [22:02:42] hope everything is ok with you and you had a great start of the year. [22:03:31] we skipped the appointment in December since there were the holidays, but here we are again. [22:03:56] And later than we've done it for a few months, it feels like? [22:04:26] Anyway, I suppose I should talk about Editing and in particular VisualEditor. :_) [22:04:43] great. go ahead, James. [22:05:00] The big thing that people will notice is that, as of today (for Wikipedias) or yesterday (for non-Wikipedias), the design of VisualEditor has changed a bunch. [22:05:20] This is part of the new work from the Design team to converge our designs across all teams. [22:05:48] It follows on from "Minerva" and "Agora" and "Athena" and "MediaWiki UI" and a bunch of other old code-names. [22:06:08] Technically, the change has been to the OOjs UI interface system, which VisualEditor uses, rather than to VisualEditor itself. [22:06:20] However, from a user perspective the change will feel like it's quite big and sudden. [22:06:33] In general, the new design is simpler, lighter, bolder and bigger. [22:06:42] Backgrounds are now plain white rather than textured. [22:07:02] Buttons are solid-filled rather than gradiented. [22:07:33] Layouts have more padding and a little more space. [22:07:58] This new design has been live in VisualEditor on Mobile for two months or so. [22:08:26] ...that's why it felt familiar! [22:08:28] I believe that the plan is to roll it out to the entirety of MediaWiki in future, though I'm not involved in that work. [22:08:54] Early versions of it have been used in a few places from time to time, like the login page or the Mobile Web interface. [22:09:20] While James writes his updates, please prepare your questions for him! [22:09:25] Lots more to come there, I'm sure. The wikitext editor, Special:Log, Special:RecentChanges for instance. [22:09:55] But that's not really my area of speciality so I'm not sure I'm best to answer questions on that, but if you have one please feel free to ask. :-) [22:09:58] Anyway. [22:10:25] Beyond that, there are some new features and fixes in VisualEditor since the last all staff. [22:11:17] We'd just launched table editing last time, I believe. [22:11:36] I really can't recall if it had already landed, you know. [22:12:05] Just in case: table editing is now out there. It feels pretty much like magic. [22:12:19] Since then we added search-and-replace, category redirects, Esc to escape, and a few others. [22:12:41] Search-and-replace lets you find some content and replace it; this was asked for by a bunch of users. [22:13:17] I have a question about that, actually [22:13:36] There are some fun bits there – case-insensitive searching; regular expressions; replace-all, etc. [22:13:37] Sure! [22:13:56] some users felt like an X button to close it was needed. do you plan to add it? [22:14:13] Aha! Yes, we added that last week. It rolled out to Wikipedias today. [22:14:27] Just this week we worked on performance of the system so searching for ' ' on a really long page doesn't crash the browser trying to highlight every single space on the page. [22:15:10] (One of the perils of Wikipedia is how the pages are much longer than most editor systems have to deal with, and industry-standard solutions aren't good enough for what we need.) [22:15:15] Great! Now I need to remember where I can post the reply, but that's definitely not your problem. [22:15:19] :-) [22:15:45] There are a few more improvements to make to search-and-replace; the interface is still a little janky, with button layout feeling odd. [22:16:12] OK, what else? [22:16:53] Category redirects means if you add [[Category:Cat]] in VisualEditor, and [[Category:Cat]] is actually #REDIRECT[[Category:Cats]], VisualEditor will instead magically add [[Category:Cats]] for you. [22:17:17] This means bots don't have to clean up after you if you accidentally add the redirect category rather than the proper one. [22:17:57] not bad. [22:17:58] Esc to escape is simple but useful: pressing "Esc" will escape the editor – or prompt you to save first. [22:18:27] (There was an unfortunate bug there which meant pressing Escape inside a dialog would also escape the editor, but we fixed it.) [22:18:49] Beyond that, we've fixed a lot of bugs and made a bunch of minor improvements, design tweaks and so on. [22:19:40] when you're done, James, I think we have a guest who's looking forward to asking us something! Let's see if Simon's client works. [22:20:22] (/me also waves to Simon's fellow Wikipedian Trizek) [22:20:50] Looks like Simon's having issues in posting here, I'll copy/paste his question. [22:20:51] Aha. [22:21:00] 177 tickets closed as "Resolved": https://phabricator.wikimedia.org/maniphest/query/XEyDLhjIAKts/#R [22:21:16] So, lots of changes. :-) [22:21:37] Wait, looks like more people are blocked. Let's take a look to what's happening. [22:21:42] Performance is a big piece of work for us. [22:21:45] Oh, that's not good. [22:23:33] Aha. [22:23:39] Elitre: /mode -m [22:24:06] /mode -m [22:24:28] There. [22:24:29] lol. [22:24:39] Now hopefully people can ask some questions. :-) [22:24:45] test [22:24:49] Hey Simon. [22:24:55] \o/ [22:25:02] Success. :-) [22:25:02] (sorry everybody. it's 11pm where I live! thanks for your understanding.) [22:25:04] smothering dissent since 14:01 :) [22:25:05] Elitre, what about +sF? [22:25:11] why did you set those? [22:25:41] Hi James_F. I wanted to know if it is possible to activate the VE on a specitif page ? [22:25:52] I want it for my education projects pages on the French Wikipedia (all subpages of https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Projets_p%C3%A9dagogiques/C%C3%A9gep_de_Chicoutimi&redirect=no and https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Projets_p%C3%A9dagogiques/Universit%C3%A9_du_Qu%C3%A9bec_%C3%A0_Chicoutimi&redirect=no) [22:25:58] Simon: Hey Simon. [22:26:01] Right. [22:26:29] So the quick answer is "no"; VisualEditor has a configuration about a lot of things, and one of them is what namespaces you should make it available in. [22:26:57] Right now, VisualEditor lets you bypass the configuration with ?veaction=edit for some settings, but not for namespaces. [22:27:16] Ok. Can we activate it on the Wikipedia namespace on the French Wikipedia ? Did you have discuss this with the French community before ? [22:27:21] We could make it also bypass-able, or we could enable it in the Project (here, Wikipédia) namespace. [22:27:36] We could do that, and no, we've not had that discussion. [22:27:48] Be bold :p [22:27:55] I have a worry because the Wikipédia namespace has discussions in it often. [22:28:02] And discussions don't work well with VisualEditor. :-) [22:28:18] But that just means people should remember not to get confused. [22:28:31] This is already the way that Wikidata's use of VisualEditor is configured. [22:28:41] James_F: If discussions on Wikipédia namespace on French worries you, we can fix it. [22:28:45] If you want it for French Wikipedia, file a Phabricator ticket. [22:28:55] Trizek: I don't want to be the cause of disruption. [22:29:27] (It's about 5 minutes' work to make VisualEditor available in a namespace, but especially for big wikis it's probably work mentioning it to the community first before making the change just to check. What do you think? [22:29:29] ) [22:29:36] This channel is still secret and with forwarding enabled. [22:29:49] discussions work well in Flow, but the Collaboration team don't want to be the cause of disruption either :) [22:29:49] James_F: Don"t :) I mean we (French community) can study it. [22:29:59] spagewmf: Exactly. :-) [22:30:15] James_F: first, congratulations! I'll miss the lime Apex colors but consistency is a big win. [22:30:18] Krenair: Not germane to the meeting; /query Elitre instead. :-) [22:30:34] I did but it's not changing anything [22:30:42] spagewmf: I miss them too. Special secret: standalone VisualEditor still has Apex, not MediaWiki. ;-) [22:31:16] spagewmf: But thank you. The work of TrevorParscal, MatmaRex and the Design team has been immense, and I'm very grateful to them all. [22:31:23] kaity and I noticed some differences with mw-ui- CSS, e.g. the text-shadow. [22:31:53] spagewmf: Right. Did you tell violetto_? She's the owner of the design. [22:32:10] spagewmf: We're just the users of it, not the designers. :-) [22:33:06] Elitre: Much channel heat [22:33:17] thanks a lot, marktraceur. sorry for the inconvenience. [22:33:28] -o [22:34:06] Anyway. [22:34:16] What other questions do we have? [22:34:23] James_F: Not yet. How is WMF keeping the "simple" mw-ui-button mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget > oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are we able to share LESS rules? [22:35:26] spagewmf: MW UI isn't being kept in sync with the new design, I believe. I don't think it's credible to try to marry the technologies together with shared files – it'd be a huge amount of work for a short-term hack. [22:35:40] James_F : Can we activate EV on a namespace only with a gadget-style option ? [22:36:01] Simon: I'm not sure exactly what you mean? [22:36:57] (on google translate) [22:37:27] I mean : can we activate the EV on a namespace on the French Wikipedia only by checking some special option on our « Preferences » ? [22:37:48] Simon: Oh. Yes, it would be possible, but it might be a bit confusing? [22:38:03] Why ? [22:38:09] Simon: If necessary, you could over-ride it with a gadget right now. [22:38:16] Simon: Because more options == more confusion for users. :-) [22:38:28] But yes, it could be built today if someone had the time. [22:38:43] Ok. This seems to be a law that I didn't know :) [22:39:09] Are there other questions for James? Now it's a good time to ask. [22:39:25] I'm searching a option to activate the EV only for my students of my education projects, [22:39:26] If it is not possible to activate VE on specific pages, is it possible to desactivate it on specific pages? [22:39:33] Simon: Ha. :-) Yeah, we're very careful not to bring in more options without a good reason. [22:39:53] Trizek: No, there's no facility for that, sorry. [22:40:08] James_F: OK, thanks! :) [22:40:52] Trizek: Again, we could build it but you would have to convince people to spend time on it over other things. [22:41:37] Right. [22:42:13] So… questions? :-) [22:42:18] I have an other question: on fr, we are corrently rewriting all help pages. I [22:42:20] James_F : I'm a little bit surprised about the discussion problem issue. For now, the EV is activated on the main and User namespaces, and the user namespace is a lot of discussion [22:42:36] Simon: In User:? Not User talk:? [22:43:05] Ah, yeah, it's true [22:43:11] ;) [22:43:26] James_F: I'll follow up with designers nearby. The mw-ui- classes are a lot easier for humans to grok/reuse, e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be very cool for pages to have OOjs UI gadgets someday. [22:43:38] I would like to know if someone can create a checkbox on the preferences in order to select his favorite tool between VE and wikitext. [22:43:56] Trizek: this is a great question... [22:43:57] Simon: The plan is that Flow will take over all the discussion rôles. [22:44:09] This option would permit to display specific help pages [22:44:16] Trizek: Ah, interesting idea. [22:44:27] James_F: Thanks ^^ [22:44:39] spagewmf: Well, tough. :-) MW-UI won't be around for much longer. [22:44:50] James_F : When ? [22:45:27] Simon: I don't know. A long time, I think. :-( Flow development is slow because they're being very careful to build the perfect tool, which is great. [22:45:35] Trizek: fr.wp is still ezperimenting with Flow, right? [22:45:35] We are currently working on a prototype, with one page for VE https://fr.wikipedia.org/wiki/Utilisateur:Mattho69/r%C3%A9sultats/M/Ins%C3%A9rer_une_r%C3%A9f%C3%A9rence and one for wikitext https://fr.wikipedia.org/wiki/Utilisateur:Mattho69/r%C3%A9sultats/MC/Ins%C3%A9rer_une_r%C3%A9f%C3%A9rence [22:45:53] Trizek: That sounds difficult. [22:45:54] Elitre: Yes. On two pages. [22:46:05] James_F: Oh? Why? [22:46:10] Trizek: Also, sorry for making all the screenshots wrong. ;-) [22:46:21] Trizek: Difficult to keep both pages up-to-date. Twice as much work. [22:46:30] James_F: Which screenshots? [22:46:44] Trizek: The VisualEditor ones on https://fr.wikipedia.org/wiki/Utilisateur:Mattho69/r%C3%A9sultats/M/Ins%C3%A9rer_une_r%C3%A9f%C3%A9rence [22:46:59] But the [22:47:01] Bah. [22:47:05] But the help page looks good. [22:47:16] Don't worry, we love to write Help pages and illustrate them. [22:47:20] * James_F grins. [22:47:20] OK. [22:47:53] Trizek: you probably weren't here while we were discussing the new VE design, landed on Wikipedias today. [22:48:29] Nope. We have a major event on fr today, with a lot of vandalism. :/ [22:48:48] We will change the screenshots soon, I think :p [22:48:50] Trizek: indeed, my sympathies [22:48:55] +1 [22:49:14] Thanks! So, is it possible/imaginable for the option? [22:50:11] (Everybody, last 10 minutes for this office hour. Questions, again?) [22:50:31] Trizek: It is possible to have it, yes. I'm not sure how it would work, though? Users already have both, but the option to hide VE. [22:51:26] James_F: My purpose is to select, or redirect people automatcally to the good help page. [22:51:47] Yes. [22:52:22] So… [22:52:25] (I hope to express myself correctly ^^) [22:52:41] There's a lot of possibilities for us to build around wikitext and VisualEditor options. [22:52:46] Overall preferences. [22:52:54] Preference per namespace. [22:52:56] Etc. [22:53:07] I worry this could be complicated, and not much value. [22:53:16] Ok. [22:53:44] However, a quick gadget to force VisualEditor to be available on every page (or every page in the Wikipédia: namespace, or every page called "foo", or…) is probably pretty easy. [22:54:01] That could solve the immediate problem for Simon. [22:54:06] But not for the help pages. [22:54:11] I think I've not been clear :p [22:54:16] I think this needs more discussion. [22:54:23] Me too ^^ [22:54:28] I send you an email? [22:54:29] No, Trizek, you're very clear, I'm being unclear, sorry. [22:54:32] That would be great. [22:54:35] ok [22:54:41] Let's do this [22:54:45] Trizek: Cool. ;-) [22:55:10] (One more email for a WMF staff member ^^) [22:55:13] or, you can all come back here on Thursday 19 February, 19 UTC! [22:55:27] (I'll spend the rest of my week writing to SF :-)) [22:55:29] can help pages tell if the user asking for help was likely to be using VisualEditor? Seems tricky [22:55:29] the next office hour will be then. [22:55:41] Hi, time for one last question/comment? [22:55:42] Trizek: Sure. :-) [22:55:46] jem: Go for it. [22:55:50] Thanks :) [22:55:50] 5 minutes to go! [22:56:03] spagewmf: They can if we build the help access into VisualEditor… ;-) [22:56:04] Shoot your questions now, ladies and gentlemen. [22:56:05] It's just about https://phabricator.wikimedia.org/T51622 [22:56:29] I commented it and I think it's very interesting for the projects [22:56:47] (and if you are not getting our VisualEditor multilingual mailing list... sign up now at https://meta.wikimedia.org/wiki/VisualEditor/Newsletter ) [22:57:25] *newsletter, of course [22:57:28] jem: Right, yeah. [22:57:31] It could be a way to introduce VE to veteran wikimedians in reluctants projects as es.wiki [22:57:55] By making its petitions to the administrators, etc. [22:58:01] their* [22:58:09] How often is it used for useful things for real users, and not just administration stuff? [22:58:19] Like writing articles? [22:58:41] Mostly I see it used for nominating something for deletion, which is a discussion so isn't suitable for VisualEditor. [22:58:44] In fact, yes... for the sandbox or the article creation assitant [22:59:09] Well, I was thinking in vandalism warnings [22:59:36] Or requests to move, to protect, to speedy delete... [22:59:49] Or requests for new permissions [23:00:12] Most of those are discussions. [23:00:13] All except "Article creation assistant". [23:00:21] And that doesn't work very well I find. [23:00:38] We should provide a better tool, perhaps? Rather than re-implement one that isn't so good. [23:01:00] Anyway. [23:01:02] We're out of time, I think. Thanks a lot for coming and discussing despite technical difficulties. I'll post the logs ASAP on Meta. [23:01:04] I think we're out of time. [23:01:14] Thank you Elitre, and everyone else. [23:01:16] Bye! [23:01:27] Oh [23:02:34] Well, I was going to ask if there are no plans to implement it in the long term... [23:03:01] please feel free to ask on Phabricator directly, jem? [23:03:20] Elitre: In fact I have asked there :) [23:03:23] in the same task you linked above? [23:03:30] Thanks for this office hour Elitre James_F|Away spagewmf and everyone! [23:03:44] Well, I have made a comment, but I don't know if it will ever be answered [23:04:11] I'll make sure James sees it then, that's the least I can do. [23:05:19] Thanks, Elitre [23:05:27] don't mention it! [23:05:30] :) [23:05:37] And if not, I'll try again in the next office hour [23:05:49] that's the spirit ;) [23:06:16] Yes :)