Jump to content

Architecture meetings/RFC review 2014-06-02

From mediawiki.org

23:00 UTC, Monday, 2 June, at #wikimedia-office connect.

Request for Comment to review

[edit]
  1. Requests for comment/Grid system

Summary and logs

[edit]


Meeting ended at 00:00:08 UTC.


Action items

[edit]
  • sumanah to ask Product to check on IE versions we need to support, document it?
  • quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
  • Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs!
  • shahyar to mention a few small concerns on Pau's change


Action items, by person

[edit]
  • Deskana
    • Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs!
  • quiddity
    • quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
  • shahyar
    • shahyar to mention a few small concerns on Pau's change
  • sumanah
    • sumanah to ask Product to check on IE versions we need to support, document it?



Full log

[edit]
Meeting logs


23:00:12 <sumanah> #startmeeting Discussion of grid system RfC | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours
23:00:12 <wm-labs-meetbot> Meeting started Mon Jun  2 23:00:12 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.
23:00:12 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
23:00:12 <wm-labs-meetbot> The meeting name has been set to 'discussion_of_grid_system_rfc___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'
23:00:25 <sumanah> #chair sumanah TimStarling
23:00:25 <wm-labs-meetbot> Current chairs: TimStarling sumanah
23:00:30 <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-02
23:00:38 <sumanah> #topic Grid system RfC
23:00:47 <sumanah> #info We're discussing Pau Giner's proposal for "a Grid system in MediaWiki to simplify the creation of user interfaces and make them ready for multiple screen sizes."
23:01:15 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system
23:01:30 <sumanah> wave hello, pginer :-)
23:01:38 <sumanah> #link https://gerrit.wikimedia.org/r/#/c/133683/ is the new test/example patchset. "It makes the log-in form responsive (adjusting layout, typography and visibility to the current screen size). It does not leverage all the potential of responsive design, but may be useful as a demo to help the reviewers."
23:01:47 <pginer> hi!
23:01:57 <sumanah> cscott - I'll also be asking you for your thoughts :)
23:01:59 <sumanah> #link https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui".
23:02:08 <sumanah> #link https://pauginer.github.io/agora-grid/ has more information.
23:02:13 <cscott> hello ;)
23:02:21 <sumanah> pginer: what would you like from today's chat?
23:02:30 <sumanah> #info cscott has said "A grid system for content authors would be useful as well." http://lists.wikimedia.org/pipermail/wikitech-l/2014-June/076810.html and the following message have more.  cscott what are your thoughts?
23:03:10 <cscott> i agree with peter coomb's followup in that thread:
23:03:26 <cscott> "IANA "grid expert", but I think it would be a huge missed opportunity not to let this be used for content. It could be a great help with pages like Portals, which are currently reliant on loads of inline styles for layout, or worse, tables."
23:03:31 <TimStarling> I think we discussed this at the architecture summit?
23:03:31 <pginer> Last time I was asked to provide some example of use, and I tried to provide so with the example patchset. I would like to know if there is anything else I could do to facilitate the review process.
23:03:39 <TimStarling> maybe very briefly anyway
23:03:54 <sumanah> We did TimStarling
23:04:00 <sumanah> #link https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling#Grids our discussion at arch summit
23:04:10 <TimStarling> I think the "implementation" section wasn't there at the time?
23:04:19 <pginer> You are right
23:04:57 <cscott> gwicke expressed some reservations about adding Yet Another non-semantic markup for content -- grids give size hints, but not the semantic reasons behind that.  i agree with that concern about exposing grid systems as well.  so i'm on both sides of the fence.
23:05:31 <pginer> cscott, this is based on LESSCSS, so it is a bunch of mixins
23:05:37 <pginer> the HTML does not get affected
23:06:09 <the-wub> it's not any less semantic than the ways content is being laid out at the moment though
23:06:09 <sumanah> #info when asked for his thoughts on the matter, jorm said: "1) We need a grid system 2) Not having one makes us look like stone-age "sophisticates"  3) The grid system should work with div#content "
23:06:25 <sumanah> pginer: I'm presuming your proposed system does work with div#content ? Sorry I haven't looked yet
23:06:49 <sumanah> (a control-f does not find that string in the pg)
23:07:00 <TimStarling> so the question for gwicke was whether or not to apply the grid classes to style attributes?
23:07:25 <cscott> the most obvious way of tying them together would be something like [[File:Foo.jpg|class=foo]] where the skin gave foo a style which referenced the grid system.
23:07:47 <cscott> the alternative would be directly exposing the grid, something like [[File:Foo.jpg|grid=mxn]]
23:08:06 <cscott> perhaps there are other, even better, options?
23:09:09 <TimStarling> cscott: I don't see anything about files on the RFC
23:09:58 <cscott> TimStarling: yes, my quick read of the RfC didn't turn up any indication that it applied to content.  which i view as somewhat unfortunate.
23:10:03 <cscott> but i could be wrong
23:10:21 <pginer> The grid system just provides some basic constructs you can use when creating style classes. Those classes can have different purposes (content or UI).
23:10:25 <TimStarling> jorm is also saying (in jargon) that it should apply to content
23:10:43 <cscott> i agree with jorm's jargon (and style)
23:10:53 <pginer> I think the first place to apply it is for UI, but there is nothing that prevents its use on content
23:11:15 <pginer> or to create new classes or new mixins that are used on both
23:11:32 <TimStarling> pginer: to use in content, the mixins would have to be applied to specific classes and made available on all pages, right?
23:11:35 <the-wub> under "Implementation" on https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system it says that LESS mixins will "avoid grid classes to be used out of their intended target (UI as opposed to user-generated content)."
23:11:49 <the-wub> is that something which can be changed?
23:12:02 <pginer> TimStarling: yes
23:12:45 <TimStarling> that wouldn't be much extra code, would it?
23:13:17 <cscott> i'd like to think that the skin would be an intermediary.  so the enwiki community (for example) could agree on some semantic classes (like "one column figure", "full width figure", etc, but with better names!) and these classes could be implemented by the skin, in the content section, using the grid system.
23:13:53 <pginer> cscott: that is how I see it
23:13:58 <cscott> that is, the grid classes wouldn't be directly exposed to #content, but would be available for the skin to expose indirectly to content?
23:14:21 <pginer> yes
23:14:25 * jorm likes it when people agree with his style.
23:14:54 <cscott> i should say, "the skin and Common.css" or something like that.
23:15:26 <the-wub> cscott: that makes a lot of sense
23:15:31 <pginer> In the same way that “width:50%” can be used anywhere, the grid system just provides constructs to say “width:50% if small-screen”
23:16:38 <shahyar> I’ve got a few questions. #1 Why does .mw-ui-grid have overflow: hidden, instead of something like the micro-clearfix? #2 Why don’t we just calculate widths, instead of having a couple dozen LESS proportion mixins? #3 How does this work with older browsers like, IE6? Particularly with regards to subpixel rounding differences in browsers.
23:19:42 <TimStarling> sorry, connection dropped out for 5 minutes before I realised
23:19:54 <TimStarling> I don't think the community would be happy with the idea of delegating layout to MW, making it difficult for them to change it
23:20:01 <sumanah> nod
23:20:27 <TimStarling> and maybe today is not the best day to try to sell the idea of "WMF knows article layout better than you"
23:20:32 <pginer> Regarding #1, there are several techniques for sorrounding floating elements. I don’t remember the pros/cons, but I’m open to apply a different technique.
23:21:21 <pginer> Regarding #2, I don’t understand what do you refer by “why don’t we just calculate widths?"
23:22:05 <pginer> Php-less was a bit limited in terms of applying dynamicly generated mixins.
23:22:10 <cscott> TimStarling: the proposal was just to expose the grid system to common.css, so the community could use it to create their own layouts.
23:22:47 <TimStarling> ah right
23:22:54 <TimStarling> <cscott> i should say, "the skin and Common.css" or something like that.
23:23:02 <cscott> http://pastebin.com/vg7ueSXY <- a little backlog
23:23:04 <TimStarling> this was just after my connection dropped out
23:23:14 <TimStarling> yeah, my bouncer was still connected
23:24:24 <cscott> from my recent experiences with wikiquotes :) one of the things they like to do is put a column of illustrative figures in a column down the right-hand side of the article
23:24:53 <shahyar> pginer: #2 I mean we could have a generic mixin to which you give a number (eg. 1/5), and that returns the calculated CSS given its arguments.
23:25:06 <cscott> not exactly sure how the specific grid system in the RfC handles it, but some systems would make it easy to drop these out on narrow screens.
23:25:11 <tgr> cscott: common.css does not currently support LESS though
23:26:18 <TimStarling> #3 I don't think we need to support accurate layout in IE6 anymore
23:26:25 <pginer> shahyar: we could go with the parameter route, but the human readable mixins may make easy to understand when used.
23:26:32 <TimStarling> if they can read the text without their browser crashing, that's a plus
23:27:01 <TimStarling> but I don't think there is a guarantee that it should look nice
23:28:05 <sumanah> http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140602.txt for people who had trouble connecting/staying connected
23:28:35 <cscott> fwiw, from https://en.wikipedia.org/wiki/Moon there are two "full width" or "wide" figures: https://en.wikipedia.org/wiki/File:Speed_of_light_from_Earth_to_Moon.gif and https://en.wikipedia.org/wiki/File:Speed_of_light_from_Earth_to_Moon.gif
23:28:45 <pginer> I have not made an intensive cross-browser analysis, but using float-based grids are widerly supported that other alternatives (inline-block or flexbox)
23:28:57 <cscott> i'm participating because i'd eventually like to see better/more consistent markup for things like that.
23:29:09 <shahyar> TimStarling: while I would personally like to agree with you, in our scenario, IE6 and 7 together represent something like 2% of requests. it’s significant enough that it needs to work better than just “not crash” :)
23:29:34 <TimStarling> IE 7 yes, IE 6 no
23:29:59 <quiddity> and https://en.wikipedia.org/wiki/File:Moon_phases_en.jpg  *  is the second "wide" image ;)
23:30:30 <shahyar> I think there’s a possible balance to be had, but the current state of the code does not account for either of them. and neither IE6 nor 7 support box-sizing, so supporting one is essentially both.
23:30:46 <jorm> My reasoning for including div#content is specifically because i don't think we're in a position to dictate to autonomous wikis how to do layout.
23:30:49 <shahyar> TimStarling: IE6 is in more use than 7.
23:30:55 <sumanah> robla: do you have thoughts on what IE versions we need to support?
23:31:15 <TimStarling> IE 6 is 0.22%, IE 7 is 0.74%
23:31:20 <TimStarling> http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
23:31:40 <shahyar> TimStarling: of all requests. of HTML requests it’s over 1%.
23:32:09 <TimStarling> fair enough
23:32:16 <TimStarling> I still don't think we should support layout in it though
23:32:32 <robla> sumanah: I think that's probably a question for Product
23:32:41 <tgr> shahyar: is your concern about some images being positioned 1px off on IE6 (and maybe 7) or something different? Because that does not sound like a big deal, even for 2% of the users
23:32:49 <sumanah> robla: cool - you see Dan Garry around?
23:33:02 <robla> not immediately
23:33:13 <cscott> quiddity: thanks, chrome hates cut-and-paste on linux these days.
23:33:17 <shahyar> tgr: the problem isn’t that they would be incorrectly positioned, but rather that the value would be completely miscalculated and one of the colums would end up on a new line.
23:33:31 <sumanah> James_F|Away: ping re your IE versions research...
23:33:31 <sumanah> #action sumanah to ask Product to check on IE versions we need to support, document it?
23:33:32 <TimStarling> IIRC, layout in IE6 was a much more complicated and idiosyncratic business than IE7
23:33:44 <shahyar> I am in fact in support of _forcing_ IE6-7 to render off by a few pixels so that they don’t have this problem.
23:34:02 <TimStarling> and I think we have stopped doing IE6 support in a few other projects
23:34:30 <shahyar> unfortunately, we support IE6-7 (to an extent; it’s not pixel-perfect, that’s for sure) in Flow, and should we implement grid, we’d need it to do so as well.
23:34:53 <sumanah> should we put off the IE discussion/chat until I've had a chance to grab a Product person to weigh in on the talk page?
23:35:16 <jorm> we are slowly removing support for old things like that.  like, not designing for them at all.
23:35:49 <jorm> the problem is that those things (the non-ie 6 designs) are for editor features, not reader features.
23:36:18 <quiddity> Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
23:36:49 <tgr> shahyar: couldn't that be avoided by targeting old IE separately with a CSS hack/conditional comments/whatever and making the columns a little smaller?
23:36:53 <sumanah> quiddity: you willing to help follow that up after this meeting, with analytics?
23:37:00 <jorm> i gotta go, but my bouncer is recording everything.
23:37:03 <TimStarling> http://www.modern.ie/en-us/ie6countdown
23:37:38 <pginer> there are also polyfills for supporting box-sizing on IE6/7
23:37:38 <the-wub> I think there are polyfills around for box-sizing on IE6/7. not sure if that's the only problem though.
23:37:49 <the-wub> pginer: jinx!
23:37:54 <quiddity> sumanah, sure
23:38:07 <sumanah> #action quiddity to Should also check browser-stats regarding geographic distribution. Eg. if IE6 makes up a significant percentage of Global South readers/editors.
23:38:09 <TimStarling> mostly PRC then, followed by Taiwan
23:38:18 <TimStarling> yeah, that's what I am doing
23:38:19 <tgr> eg. if you set 3-column to 30% on IE, that will not overflow as long as the container is larger than 30px
23:38:33 <TimStarling> it is mostly used in China
23:38:50 <sumanah> IE's big in South Korea, right?
23:38:58 <shahyar> tgr: yes, and it might be doable with mixins. we have to come up with a weird calculation to do it.
23:39:00 <shahyar> the-wub: we shouldn’t use polyfills for something like this, because we already have a LOT of elements on the page, and the page will come to a crawl with a polyfill for something like this.
23:39:07 <TimStarling> IE6 is 1.3% in Korea
23:39:15 <sumanah> oh! nm
23:39:15 <TimStarling> according to that page
23:39:18 <shahyar> quiddity: Oliver has browser talk page stats, iirc.
23:39:28 <quiddity> yupyup
23:40:01 <sumanah> ok pginer what additional topics would you like to address today? or mark for further discussion onlist etc.?
23:40:04 <TimStarling> that page has IE6 at 4.2% globally, so the fact that we measure 1% tells you something about how popular we are in China
23:40:41 <TimStarling> it is 22.2%, for the log
23:40:56 <TimStarling> IE6 usage in PRC
23:41:08 <cscott> rly? wow.
23:42:12 <pginer> Just encourage to provide comments on the talk page or the patchsets
23:42:38 <TimStarling> ok, maybe it is worthwhile to support IE6 then
23:42:47 <sumanah> pginer: but on what specific open questions?
23:43:32 <pginer> Aspects that can be changed
23:44:16 <pginer> With this proposal I’m more interested in the big picture (having a responsive grid available) than the underlying implementation
23:44:16 <sumanah> hey Deskana - which IE versions are we committed to supporting, in MediaWiki?
23:44:23 <TimStarling> anyway, should we merge the existing change?
23:44:47 <TimStarling> #link https://gerrit.wikimedia.org/r/#/c/125387/
23:44:52 <Deskana> sumanah: I don't think we really have an answer to that question. We should think about this as a group.
23:45:37 <TimStarling> it has no positive CR from anyone
23:45:38 <sumanah> Deskana: is it possible for me to assign this question to you to follow up on and advise pginer in this context?
23:45:46 <sumanah> it seems to be a blocker for this discussion
23:46:25 <shahyar> it’s not really a blocker. IE6-7 can be solved with hacks in the mixin.
23:46:28 <TimStarling> I think we should support IE 6 if it is not too difficult
23:46:56 <TimStarling> 1% thinly spread is not a concern, but 22% of China is a concern
23:47:01 <pginer> I don’t see it as a blocker. It just means that at the moment the mixins cannot be used if you are creating a UI for those browsers.
23:47:21 <sumanah> TimStarling: #agreed that IE version question is not a blocker?
23:47:39 <TimStarling> yes, fine
23:47:47 <Deskana> You can assign it to me in the sense that I can get a discussion going about it, sure.
23:47:49 <TimStarling> what we need to merge it is for some people to give +1 on it
23:48:00 <sumanah> #agreed we don't need to block this discussion on the question of which IE versions we specifically support
23:48:19 <sumanah> #action Deskana (Dan Garry) to follow up with Product to form policy on what IE versions we support, for future RfCs!
23:48:26 <TimStarling> i.e. actual code review
23:48:59 <pginer> Someone reviewing the patchset would be awesome
23:49:06 <cscott> what was the answer to the question about #content?
23:49:30 <cscott> is that still a "yes, it would be nice if the patch would do this" or a "yes, the existing patch could be used to style #content"?
23:49:37 <Deskana> It's not just going to be product; it's also an engineering question (e.g. "What is the engineering cost of supporting IE6?") and a design cost (e.g. "How does supporting older browsers affect what designs we can create for our site?")
23:49:44 <TimStarling> I think a separate patch can do it
23:49:44 <Deskana> *design question
23:50:06 <cscott> TimStarling: meaning, once this is committed, a future patch can investigate the #content issues?
23:50:11 <TimStarling> AFAICT, the existing patch does not block development of a feature which exposes these mixins to the content
23:50:16 <sumanah> Deskana: yes, it's interdisciplinary for sure, it's just that it seems to be a decision Product could own after consulting with others to make it :-) IMO
23:50:24 <TimStarling> so yes
23:50:26 <Deskana> YEAH
23:50:29 <cscott> TimStarling: ok, thanks
23:50:31 <Deskana> YEAHHHHHH
23:50:34 <Deskana> (ACCIDENTAL CAPS)
23:50:42 * sumanah laughs aloud
23:50:57 <marktraceur> Deskana: I guess you...*takes off shades*...popped a cap in this channel. YEAHHHHHH
23:50:58 * cscott LAUGHS ALSO
23:51:07 <TimStarling> exposing it to content should probably be deployed separately
23:51:43 <TimStarling> from a deployment perspective, it is much more scary to expose a feature for users to incorporate into content than it is to expose a feature for developers to use in UIs
23:51:50 <TimStarling> much easier to revert the latter
23:52:08 <sumanah> Deskana: (I was like, "yes, I am glad you agree, I think I did articulate that well if I do say so myself......oh. you just meant yes.")
23:53:23 <sumanah> TimStarling: indeed
23:53:43 <sumanah> cscott: are you reviewing pginer's patchset?
23:53:43 <cscott> TimStarling: yes, my concern is just deploying a developer feature that can't be eventually used for content editors without tearing everything out and starting over.  as long as we can build on this, +1 from me.
23:53:47 <sumanah> marktraceur: you wanna do that?
23:53:54 <cscott> sumanah: not at the moment, i'm eating dinner ;)
23:53:59 * marktraceur looks around
23:54:00 <marktraceur> Do what?
23:54:08 <cscott> i'm trusting TimStarling's assessment :)
23:54:23 <sumanah> marktraceur: review the patchset
23:54:37 <TimStarling> well, it's based on my fairly murky understanding of what a LESS mixin is
23:54:37 <marktraceur> Maybe.
23:55:04 <sumanah> is this something Roan, Krinkle, or TrevorParscal would be interested in reviewing?
23:55:07 <TimStarling> but I think pginer agrees that it is a reasonable foundation for a content feature?
23:55:14 <sumanah> (Pau's grid patchset)
23:55:36 <sumanah> or MatmaRex
23:55:38 <shahyar> I have some simple, addressable concerns for the patch. I’ll put those up. after that, I’m happy to +1.
23:55:57 <sumanah> #action shahyar to mention a few small concerns on Pau's change
23:56:00 <pginer> TimStarling yes
23:56:15 <pginer> shahyar thanks!
23:56:20 <marktraceur> #pingthewholechannel
23:56:24 <marktraceur> sumanah: Could you link to it?
23:56:43 <sumanah> https://gerrit.wikimedia.org/r/#/c/125387/ is the actual patch to be merged - "Grid system for mediawiki.ui".
23:57:04 <marktraceur> This is actually surprisingly small
23:57:09 <quiddity> I would recommend removing any automatic text-size changes, in demo-models.  Some people with desktops just like small windows, and won't appreciate their text size changing.  (I realize that's just an example of how variables-can-work in the mockup, but I think it worth noting explicitly.)
23:57:11 <TimStarling> #agreed merge 125387 first, please everyone review it; content feature will be based on top of it
23:58:39 * quiddity apologizes for being a curmudgeon.
23:59:10 <sumanah> ok, sounds like we're done
23:59:23 <sumanah> gonna end the meeting in a few seconds :)
23:59:31 <gwicke> I'm not convinced that directly exposing grid layouts to content authors is the best way to leverage grids; it might be better to encode semantics in content, and then style semantic content using something like a grid system
23:59:32 <sumanah> https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix
23:59:48 <sumanah> #link https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix browser support guide
23:59:50 <TimStarling> gwicke: we've been there, postcard is in the mail
00:00:08 <sumanah> #endmeeting


<sumanah> let's continue this chat onwiki or onlist :) Thanks all
<pginer> quiddity the text-size example was to ilustrate that although there are especific mixins for size, you could make any property to be responsive (in addition type changes were exaggerated to be noticeable)
<quiddity> Yup, that's what I figured.  Thanks for confirming though. :)
<cscott> gwicke: yes, that's what we were proposing i think
<gwicke> okay, great
<the-wub> alright. I just want to say big thanks pginer for working on this! I've been wishing for a grid system for a while, both as an editor and a fundraiser
<gwicke> just came back from a meeting, now reading the backlog
<cscott> basically exposing the grid system to the skin and/or common.css, and letting the wiki itself define appropriate semantic classes using the grid system
<cscott> and then those semantic classes would be the thing exposed to content (rather than the grid system directly)
<cscott> but that's step two or three or four, i gather
<TimStarling> we would like authors to use semantic classes
<TimStarling> whether we can force them to use semantic classes is another matter
<TimStarling> we can probably gently encourage it using the template styling feature
<cscott> fwiw, wikiquotes was very diligent itself about not adding extraneous size or other styling to their images.
<cscott> the problem is that 'bare thumb' is only a single semantic class.  it would be nice if there were more. ;)
<cscott> i think we can also encourage semantic markup w/ VE
<TimStarling> if you provide classes for use in MediaWiki:Common.css or in some new template style feature, presumably it will be possible to use those classes in style attributes
<TimStarling> well, in class attributes
<cscott> ideally there should be checkboxes or a drop down for 'type of image', and the direct manipulation of handles should be mildly discouraged
<TimStarling> I'm not sure how you would technically discourage that
<TimStarling> but maybe it's not necessary if we provide appropriate tools for semantic classes
<cscott> yes, [[Image:Foo.jpg|class=bar]] works now.  it's not the tersest markup, but if VE is generating the class attributes, the extra typing shouldn't matter.
<TimStarling> template styling is probably critical
<cscott> TimStarling: one way to discourage it would be switch between (say) one-column and two-column styles when you drag the image handles, instead of adding MxNpx attributes.
<cscott> there might be a checkbox to allow direct image sizing, but it would be an 'advanced' option.
<cscott> it's all about what you make easy
Retrieved from "https://www.mediawiki.org/w/index.php?title=Architecture_meetings/RFC_review_2014-06-02&oldid=5068592"