[21:00:52] #startmeeting RFC meeting [21:00:53] Meeting started Wed Sep 30 21:00:52 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:53] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:53] The meeting name has been set to 'rfc_meeting' [21:01:12] #topic RFC meeting | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:41] o/ hi everyone! [21:01:56] timezone appropriate greetings [21:02:05] so we have two RFCs on the agenda today, and we're not exactly sure how much time to schedule for each [21:02:23] yo, robla can you mention the new Phab event thingies while avengers assemble [21:02:26] #link https://phabricator.wikimedia.org/E68 [21:02:32] hello, avengers [21:02:59] hello! [21:03:08] we're going to start with gabriel's one, cscott do you think 30 mins is appropriate? [21:03:33] hi [21:03:45] still catching up with the lively discussion on https://phabricator.wikimedia.org/T112553 [21:04:08] well, if you're asking me then I'll say that I don't think we've gotten input from designers yet, so I'm not sure how useful our discussion will be. [21:04:27] so, about a year ago Aaron & I created a HTTP / REST request abstraction layer called VRS [21:04:43] (i'm happy to take up whatever spare attention is left over) [21:04:50] which has been used since to inteface with RESTBase and Parsoid [21:05:01] hi! [21:05:08] the goal is to provide some common functionality and basic abstractions for interacting with services [21:05:25] also, the ability to send off several requests in parallel [21:05:57] currently, this is in core, but every user has to build their own VRS object [21:06:21] which partly defeats the goal of making access to services 'easy' [21:06:59] so, the proposal is to integrate the configuration better with core, and provide a factory method that makes it easy to get a VRS instance on demand [21:07:13] if you want to see what "every user has to build their own VRS object" means in practice, then I provided links to source code at https://phabricator.wikimedia.org/T112553#1689829 [21:07:15] there is also some cleanup that could happen in the process [21:08:19] there has been a lot of discussion on the task about how this interacts with PHP service objects, and I hope it's clear that it's a lower-level and lighter-weight facility [21:08:28] which can be used by higher-level PHP services [21:08:48] TimStarling: is this where we should be using the #topic thing? [21:08:59] it's basically some minimal infrastructure around CurlMultiHTTPClient [21:09:04] too late, let's just use a single topic [21:09:28] moving all the duplicate code out of extensions and into core seems like a good idea [21:10:31] so there is already centralised configuration in the form of $wgVirtualRestConfig, right? [21:10:50] yes, we have already moved in the integration direction [21:10:59] cscott has driven much of this effort [21:11:27] the first version had ad-hoc configs per extension [21:11:27] and it's worth noting that nothing in core actually uses $wgVirtualRestConfig. We set it up in DefaultSettings.php, but it's up to the extensions to use it to create VRS objects. [21:12:06] gwicke: I think the largest confusion I see for VRS is whether it is a cURL wrapper or something else. Can you make a definitive statement on this? [21:12:35] bd808: it's an interface, which is currently backed by CURL [21:12:36] and in terms of possible improvements that could be made: VE/Collection/Flow/ContentTranslation used to have completely separate configs. Now they share a single VRS config, but it would be worth adding some standard mechanism to allow a specific extension to override the global VRS config. [21:12:56] right now it would be cut-and-paste code between four different extensions, so i didn't think it would be worth the effort. [21:13:09] the path-based services could use HTTP, but could also use protobuf RPCs under the hood if we absolutely wanted [21:13:09] also, if the intention is for VRS to be used by application code directly, or via a (more or less thin) layer service objects, like DatabaseBase is now used. [21:13:21] but, for now it's just HTTP [21:13:22] but something like VRS looks at the 'parsoid-' module first, and then falls back to the 'parsoid' module if that's not present. something like that. [21:13:58] bd808: does this answer your question? [21:14:23] DanielK_WMDE: currently, it is used by application code, like the VE extension [21:14:35] gwicke: I think so, yes. Mostly I wanted tgr and DanielK_WMDE to see you say that clearly [21:14:40] it replaced the raw HTTP calls there [21:14:41] (and ContentTranslation, and Collection, and Flow) [21:14:53] * so, the proposal is to integrate the configuration better with core, and provide a factory method that makes it easy to get a VRS instance on demand [21:15:00] can you clarify what you mean by "integrate the configuration better with core"? [21:15:30] ori: looking at the code I highlight in https://phabricator.wikimedia.org/T112553#1689829 should provide one answer to your question. [21:15:30] is it cscott's "adding some standard mechanism to allow a specific extension to override the global VRS config"? [21:15:44] as mentioned, there is already a global config object, but creating the instance is still something each consumer needs to do manually [21:15:49] and, what cscott says [21:15:49] #link https://phabricator.wikimedia.org/T112553#1689829 [21:16:08] In my oppinion direct use of VRS by application logic should be strongly discouraged. Just like directly using SQL queries in application logic should be discouraged [21:16:09] creating the instance isn't exactly trivial, since you need to make sure you inherit global settings, eg. [21:16:49] DanielK_WMDE: this is about a light-weight alternative to raw HTTP [21:17:10] you are proposing to go one abstraction layer higher [21:17:10] ...and i'm all for that! [21:17:14] and there are some fallback mechanisms coded in, since multiple services can provide the same API. so in addition to inheriting global stuff, you need to ensure you do the fallback correctly/consistently. [21:17:24] which is fine, but I'm not sure that it should be required for everything [21:17:27] I'm just warning agains "look at this shiny new hammer, let's use it everywhere" [21:17:45] so if I understand correctly VRS is just for services that are already URL-based, and anomie's concern https://phabricator.wikimedia.org/T112553#1690134 about layering this on top of API FauxRequest doesn't apply? [21:18:01] spagewmf: yes [21:18:16] gwicke: maybe i come across as overly critical. i very much like the idea of a nice wrapper around http. [21:18:30] the only reason for accessing the action api through something like VRS I could see is if we wanted to distribute / parallelize those requests [21:18:42] for in-process requests, there is really no reason to go through VRS [21:19:16] and even then, it would probably make more sense to hide that in FauxRequest [21:19:48] although we'd need to figure out how running things in parallel would look like interface-wise [21:20:05] is there anyone present who was (a) not involved in the writing of this code, (b) feels that they have a pretty good understanding of what it does and how to use it? [21:20:28] gwicke: as I understand it people assembling API requests, like the mobile app service, are doing them behind a RESTBase-like service. [21:20:34] gwicke: i think part of the confusion comes from the phrasing of "basic abstractions for interacting with services". If I read "services" as "remote" services, I'm all for it. When I read it as "all the backend stuff", then I'm not. [21:20:51] the in-process request feature could be useful for unit testing [21:21:11] TimStarling: yeah, for mocking remote services [21:21:32] of course [21:21:37] DanielK_WMDE: when gwicke says "accessing services" he means remote procedure calls almost every time [21:21:42] it just shouldn't be *the* way to access local services [21:22:08] ori: well, i wasn't involved in the writing of the code, or the initial RFC for VRS. but i've patched it extensively, so i have a pretty good understanding of it now. [21:22:24] bd808: sometimes i fear this means he wants to *make* everythign a remote procedure call :) [21:22:43] DanielK_WMDE: parallelism is the wave of the future ;) [21:22:48] [21:22:53] * cscott waves [21:22:56] heh [21:23:06] with both hands, naturally [21:23:12] gwicke: maybe we shoud port mediawiki to erlang, then [21:23:26] said many people in 1993 [21:23:31] So, I think there is an immediate use-case in core for this [21:23:32] ;) [21:23:34] hehe [21:24:17] Krinkle is planning to make the ResourceLoader startup module compute versions for RL modules by actually building them and hashing their contents, rather than trying to short-circuit the build process by detecting when a module's inputs have changed. [21:24:22] TimStarling: that would have been DCOM ;) [21:24:35] The risk with that is that it is a lot of work to perform in one request [21:24:51] but having the request to the startup module fan out to individual requests for modules would be pretty efficient [21:25:21] ori: we just ran into performance issues with that approach in wikibase [21:25:22] could this use-case help structure how we approach integrating this with core? [21:25:50] ...well, you know that, you pointed it out. [21:26:18] ori: so the idea is to parallelize requests to.. the action API? [21:26:28] to load.php [21:26:38] *nod* [21:26:43] don't see why that wouldn't work [21:26:57] so I don't think I've heard any objections yet [21:27:02] of course, whether parallelism is worth it in that particular case depends.. [21:27:19] were there any objections to the actual planned work of making VRS generally available e.g. via RequestContext? [21:27:21] sounds reasonable for RL [21:27:31] or retrospectively to the idea of having it in core? [21:27:53] for the actual implementation, we could use some guidance [21:28:00] what about this new idea of having a VRS module for action.php or load.php for this resourceloader work? [21:28:02] * AaronSchulz is always very skeptical of new RequestContext additions [21:28:04] TimStarling: no objections to adding it to core. I don't like adding more stuff to the kitchen sink that is RequestContext. [21:28:28] RequestContext is the new global scope ;) [21:28:32] RequestContext is the first thing that came to mind to expose a factory, but there might be better ways to do this [21:28:39] other than that no objections [21:28:42] i'd much prefer to inject narrow service interfaces and get away from the "everything depends on everything" model [21:28:58] well, we have singletons and RequestContext [21:29:10] and very limited usage of dependency injection via constructors [21:29:14] Flow will have to tweak their code to use RequestContext, they are still using globals. But that's work it would be good for them to tackle anyway. [21:29:16] I haven't read everything yet, but I don't see what the advantage would be of having it in RequestContext. It = MultiCurlRequest? [21:29:31] a singleton SPI is IMO still a better way to go [21:29:31] a singleton via the constructor could work too [21:29:32] TimStarling: the issue is that something that depends on RequestContext basically depends on *everything*. [21:29:34] Krinkle: it = getVrsObject() [21:29:44] like it was done for LoggerFactory for example [21:29:46] Right. [21:29:46] or something like that [21:29:57] TimStarling: which means that nothing should depends on RequestContext [21:30:04] I think it was a good move to have Logger be a separate injection instead of via RequestContext. [21:30:05] sure [21:30:26] Because it's re-usable across third party libraries (as well as first-party libraries). [21:30:49] A good question would be, do we have use for VRS (need to pass it to) code that is not in mediawiki-core that itself should also be re-uable outside core? [21:30:55] so to me it sounds like generally there is more support for doing this as a singleton [21:30:57] well, VRS lives in include/libs/virtualrest now. The proposal is specifically about adding some hooks to core. [21:31:07] gwicke: yeah [21:31:42] my problem with class-static singletons is that they are hard to wipe in unit testing [21:31:47] but that is a problem for another RFC [21:31:48] #info consensus is that implementing this as a singleton is preferable over RequestContext [21:32:03] since it is unit testing, maybe a reflection hack is the best way to solve that [21:32:07] we could add some general 'build a VRS object' stuff to libs/virtualrest, but specific MW tie-ins (like default names for the restbase service, fallback between restbase and parsoid, etc) are MW-specific. [21:32:09] gwicke: ...and avoid accessing it via global scope. or passing around the VRS service. doing this should be considered a last resort, not best practice [21:33:19] DanielK_WMDE: how would you propose to access it from extensions? [21:34:11] gwicke: the extension defines a static hook handler. the static hook handler accesses the static singleton, and injects it into whatever implements the app logic. [21:34:55] ok, any other questions to deal with before we move on to the other RFC? [21:34:57] unit tests inject a mock instead. the static hook handler remains untested, but it contains no logic anyweay [21:35:17] so there would always be a PHP object layer over it? [21:35:27] DanielK_WMDE: okay; sounds a bit more complex, but lets take the details offline [21:35:34] otherwise callers would need to know the vrs client object [21:35:54] AaronSchulz: in my oppinion yes, there should always be a service object wrapped around the vrs [21:35:56] AaronSchulz: current clients like VE etc use VRS directly [21:36:19] a RESTBase service object is something we could build separately [21:36:29] gwicke: well, that's mostly right. they actually implement their own helpers over VRS. and they don't agree on exactly what those helpers should be. [21:36:31] DanielK_WMDE: I think gwick wants vrs to be used directly in some simple cases...which could be useful [21:36:59] you'd have to make a proxy methods for all the stock rest APIs the http daemon already supports [21:37:09] anyway, we should probably move on ;) [21:37:10] #agreed Integrate the Virtual Rest Service into core [21:37:17] ie, Flow has a utility class which uses either VRS->parsoid or the mediawiki core parser inside its implementation. [21:37:27] thanks, everybody! [21:37:29] #topic Provide semantic wiki-configurable styles for media display | RFC meeting | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:38:02] TimStarling, AaronSchulz, DanielK_WMDE, cscott: it would be great if we could work out the best way to hook this up on the task [21:38:38] not a lot of time to discuss T90914, but we invited pizzzacat and violetto_ at the last minute [21:38:41] i'm agnostic about how it looks in core, so long as the amount of duplicate code in Flow/ContentTranslation/Collection/VE decreases. [21:38:46] #link https://phabricator.wikimedia.org/T90914 [21:39:37] i added some thoughts here https://phabricator.wikimedia.org/T90914#1691048 [21:39:44] gwicke: example https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikibase/master/client%2Fincludes%2FHooks%2FParserLimitHookHandlers.php [21:39:47] James proposed an interesting syntax at https://phabricator.wikimedia.org/T90914#1670526, but maybe we should discuss the topic in general before diving into implementation. [21:40:17] DanielK_WMDE: thanks! [21:40:48] #link https://phabricator.wikimedia.org/T112991 [21:41:00] ^ as well, apologies for spreading the discussion over two bugs. [21:41:20] Let's say T112991 is the broader task, and T90914 focuses on image layout. [21:41:33] gwicke: this is actually stuff for the DI RFC (T384). Need to overhaul it. [21:42:26] perhaps I should introduce the topic? [21:42:36] yes please, and questions you would like input on [21:42:36] or let people read the phab tickets before going on? [21:42:48] we can read while you are typing [21:43:21] well, I just started a discussion at design@ here: https://lists.wikimedia.org/pipermail/design/2015-September/002389.html [21:43:55] i expect/hope that the broader question of how we separate content from layout will evolve from there (and from https://phabricator.wikimedia.org/T112991) [21:44:04] cscott: one question i have is which level of abstraction is meant by "semantic". is "fullwidth" semantic? or should that be "banner"? [21:44:08] let's concentrate for this discussion on the idea of revamping image syntax in wikitext. [21:44:15] +1 [21:44:27] DanielK_WMDE: that's an excellent question, and i hope that inheritance solves the issue. [21:44:45] that is, "semantic" styles should be composable or inheritable, so that you can have a "banner" which is also "fullwidth" [21:44:55] that lets local wikis tweak things, without removing all the semantic hints. [21:45:16] for example, for the PDF backend, it maybe doesn't care about "banner", but it knows that "fullwidth" images should span two columns. [21:45:36] on mobile, "banner" is different than "fullwidth", because "banner" stays pinned to the top of the screen (say) [21:46:21] cscott: would the ineritance be the same everywhere, hardcoded? would it be guaranteed that banner is always fullwidth, or could it be something else on another wiki (or even for another medium)? [21:46:28] also obviously an image might be both a "lead" image and a "full width" image; "lead" means feel free to yoink it from the body to use in previews and such. [21:47:10] * DanielK_WMDE likes inheritance of styles [21:47:16] DanielK_WMDE: I think https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces is orthogonal, but complementary. [21:47:34] what is a backend? [21:47:53] so, in my ideal world, we can specify some "universal" styles for wikipedias on meta, but then still allow each language the ability to inherit them and do local tweaks as they need to. [21:48:04] you think that's air you're breathing now? [21:48:07] I mean, in code structure, will we have more than one of them in MW for instance [21:48:07] TimStarling: i'm using "backend" to mean "consumer of our content". loose usage, i apologize. [21:48:16] cscott: sorry, i don't see the connection with namespaces. what am i missing? [21:48:37] so PDF, mobile, web, kiwix, etc, are all backends in my loose usage. different things which want to use and style our content. [21:49:13] hm, seems like i have only read half of what is proposed [21:49:26] * DanielK_WMDE goes to read more [21:49:34] DanielK_WMDE: well, the strawman proposed in the task description https://phabricator.wikimedia.org/T90914 says that [[File:Foo.jpg|type=Foo]] is just a funny sort of template, which is defined at ImageStyle:Foo or something like that. [21:49:48] those backends are basically clients of our two parsers [21:49:55] we're calling it semantics, so name the attribute semantics=thumbnail [21:49:58] DanielK_WMDE: so we use the same shadow namespace mechanism to ensure that ImageStyle:Foo gets inherited from meta if it's not present on the local wiki. [21:50:20] can there be more than one? type=thumbnail+bordered ? [21:50:21] and that also allows for localization: ImageStyle:FooInFrench is a trivial style which inherits from ImageStyle:Foo [21:51:00] spagewmf: i think i would prefer to see that happen via multiple inheritance between styles, *not* on the image itself. [21:51:06] it seems like it would be good if the parsers had some awareness of what "backend" they were serving [21:51:09] spagewmf: the idea is to (subtly) discourage really low-level styles [21:51:10] * robla knows cscott needs to leave early-ish, and hopes we can wrap it up pretty quickly [21:51:25] so that they don't have to hack the DOM and rescale the images [21:51:34] cscott: got it. but... doesn't that mean two dimensions of inheritance, one between styles (say, banner -> fullwidth), plus a fallback from local to meta? [21:51:48] TimStarling: yes, that's an interesting point. [21:52:09] would local and meta styles be combined? or would local override meta completely? [21:52:21] would you retain the current image syntax and add a type parameter or use something new like {{#file:Foo.jpg|type=Foo}} ? [21:52:29] DanielK_WMDE: i'm punting to the shadow namespace RFC for that. whatever they decide. [21:52:40] although of course that breaks caching [21:52:45] tgr: that's another interesting question i'd like to hear more about. [21:52:49] alternatively we could not expand images at all in the parsers [21:53:17] just leave them as structured data initially, and have either the client or a middle layer expand them to scaled images [21:53:20] I generally like the idea of moving towards more "semantic" media elements, but am sceptical about the concrete solutions proposed [21:53:21] TimStarling: yes, orthogonally we might be moving to a model where more of the page composition is done after the parse step. [21:54:01] cscott: yeah, I think that direction would be more promising [21:54:03] not just when ParserCache is used, but on the CDN level too [21:54:10] which we are not good at ;) [21:54:12] TimStarling: for this particular RFC i'm going to try to concentrate on how it is done for core PHP targetting desktop, and then just make sure the semantic info is easily available so that PDF/mobile/etc can restyle as they wish. [21:54:21] just because i'm trying hard not to solve all the problems at once. [21:54:22] I think one thing that we may just need to decide is the relative priority of T90914 vs T112991, but we may need to take that to Phab [21:54:22] cscott: rephrase: if we want to move towards a different image syntax, is there a compelling reason to do that the same time as introducing semantic styles, or should those be treated as orthogonal concerns? [21:54:26] provide the skin or client with the info they need to render a page component, but leave much of the rendering to the client [21:54:45] cscott: did you want input on the {{#file:}} thing? [21:54:46] at least, let the client override a supplied render [21:54:49] I believe usability-wise {{#file}} makes a lot more sense than [[File]] [21:55:22] tgr: so the biggest problem with the current image syntax is the ambiguity between options and captions. caption is "anything which doesn't currently parse as an option", so it's technically unsafe to add any additional options to the image syntax or change any existing options. [21:55:33] I'm more ambivalent about combining the two by e.g. not allowing non-semantic formatting on {{#file}} [21:55:38] i agree... actually, {{File:...}} would make even more sense, in a way. but that would be a major breaking change. [21:55:43] tgr: of course, in practice more images have explicit captions, and the image options are before the captions, so this is a slightly theoretical concern. [21:55:54] adding options is not really a problem in practice [21:56:08] since captions do not usually start with things like border= [21:56:08] I guess it would have to be JS or proxy based post-processing...Vary: on agent isn't going to fly [21:56:08] tgr: still, parsing image links is quite technically challenging (even parsoid doesn't have all the details right yet) so simplification would be a nice thing. [21:56:18] tgr et al, are we moving towards or {{#parser function}} for new page elements, or both? [21:56:32] gwicke: I like the idea of cleaned up and more symantic syntax...but I agree that the caching seems like a headache [21:56:34] but there is a practical problem which is that typos in parameter names leak into captions [21:56:46] fun fact: image captions can contain images. and people use that feature. [21:56:56] AaronSchulz: I think we might be able to make some progress on doing that client-side [21:57:02] * robla sees the time running out on the hour [21:57:20] TimStarling: what does "input on the {{#file:}} thing" mean? [21:57:21] ok, let's wrap up [21:57:34] never mind, too late [21:57:43] any action items? [21:57:43] AaronSchulz: https://phabricator.wikimedia.org/T106099 and https://phabricator.wikimedia.org/T105845 describes an experiment in that direction [21:57:44] we can also rely on the mobile/desktop domain split for binary size buckets...of course if we want to vary on small smartphones vs phablet vs tablet that's not enough [21:57:53] i like the idea. i think the syntax needs more discussion to make sure we pick something good, and don't break too much existing content. [21:58:22] I'm not sure we have action items, we have only touched on the issues, right? [21:58:33] TimStarling: I think that's right [21:58:45] DanielK_WMDE: yes, caption is problematic, also need something VisualEditor can edit. [21:58:46] there's also the question of what the "magic image styling template" looks like. easiest thing is just to use our existing template mechanism, but perhaps that provides opportunities for abuse that we won't be able to easily walk back. [21:58:55] we need to schedule a full hour for this [21:59:06] right cscott? [21:59:07] besides caching and usability/community buy-in do we see other major concerns? [21:59:09] is anybody opposed to the direction of marking up media elements more "semantically" ? [21:59:17] i've accomplished my immediate goal of getting people talking and thinking about it. [21:59:26] \o/ [21:59:35] gwicke: if there is still one rendering initially then it seems OK [21:59:42] AaronSchulz: Vary on agent indeed doesn't fly, but beware that standards are getting out there with regards to Client-Hints. Which would potentially phase out the need for srcset=1x,1.5x,2x. Instead if would Vary on Client-Hints-DPR [21:59:56] AaronSchulz: that's my understanding, yes [22:00:11] i'd like to give design@ a week to weigh in, to see if there are any semantic tags for images which can't be handled by this basic framework. focal area tagging is one, but i think the idea is that is going to be metadata in commons. [22:00:12] Krinkle: I still worry about the cadinality of possible values [22:00:32] sounds good....let's continue the conversation on T90914 and related stuff, and then plan on slating an hour for this one. [22:00:59] AaronSchulz: i am agnostic about that, since i would like to see the community play with something for a while and see what sorts of semantic tags they think up and can use regularly. [22:01:11] ok, thanks everyone [22:01:18] i think punting to the community on that will in the end be more useful than my trying to think up all the possible semantic tags apriori. [22:01:28] * cscott has to run to pick up his kid from daycare [22:01:39] yay for faith in the community! [22:01:42] #endmeeting [22:01:43] Meeting ended Wed Sep 30 22:01:42 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:01:43] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-30-21.00.html [22:01:43] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-30-21.00.txt [22:01:43] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-30-21.00.wiki [22:01:43] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-30-21.00.log.html [22:02:05] sorry about turning abruptly into a pumpkin, but there's a thread on design@ (for design side issues) and/or feel free to comment on the phab tickets. perhaps i (or someone) should start a wikitech-l thread as well. [22:02:15] * cscott waves goodbye. in parallel. [22:05:22] TimStarling: I will mention the meeting on T90914 unless you want to make tan ArchCom pronouncement :-) [22:32:07] folks, FYI we're having another RFC meeting in 1.5 hours on https://phabricator.wikimedia.org/T30085 : Allow user login with email address in addition to username [22:41:02] The meeting in <1.5 hours: https://phabricator.wikimedia.org/E74 [23:03:46] Okay, so 8 p.m. EDT.