Front-end standards group/2016-01-27

Attending: Volker E., Krinkle, James F., Andy R.G., Bartosz, Ed S., Jon Robson, Julien, RobLa, Trevor

Follow-up

 * VE to talk to Sarah to try coming up with a more-human time for this meeting in the next couple of weeks.

New quests
Every second meeting would be later like 9:30 am (PT) and exclude India, the other one is on the edge for Europe then TT, TP bi-weekly in order to implement, because we are in other meetings as well. And it has worked well so far. +1 JR, ES VE: So it stays a once in two weeks meeting
 * Rotate time schedule every second meeting? (VE, ST)
 * Make this a weekly meeting? (VE)

Follow-up
Expose current skins Less vars within RL. > Everybody agrees on this. >TT comes up with a task

Review of WikiDevSummit '16 from User Interface working area (VE, TT, RL…) https://phabricator.wikimedia.org/T119162#1917207

Goals: Treat as first-class citizens: Apps, mobile web, desktop web, logged-in users. All with the same infrastructure and performance. Ability to change skins without breaking extensions and gadgets. Provide page-level APIs instead of HTML or DOM being the API. +1 [+1 prtk] [+1] Make themes (extension:theme style) happen with a practical API! coming from T114071 TP: Reading team has taken action on some of the sub JR: There were no clear goal outcomes and there's nothing planned this quarter. From a product perspective it doesn't fit into our current goals JF: Is this something we can tackle as group, as a "tech debt wishlist"/roadmap that's agreed as areas to tackle? TP: I would find that very helpful TT: we don't have a good skin system. There's the central system to begin with, which is tightly coupled to the core. TP: There's an RFC or even several ones RL: Which RFCs would that be? JF: First, we need agreement on the third question below, the scope of a skin. TT: Agree with James, there's a lot of things that are currently part of a skin and shouldn't. Example skin class(?). TP: Breaking it down, get started. JF: Agreeing with Timo and Trevor. Some of the changes might be really big. Either drop functionality from core. TT: Would take on some of this. TT: identify low-hanging fruits to tackle first => Action: Volker makes another meeting where people interested in this topic (scope of a skin & breakdown of tasks) join in, and we gonna lay-out a possible roadmap. Timo would go for some of the possible low-hanging fruits in the upcoming weeks. Avoid parser cache corruption and inconsistency when skins change. (Relates to T114542). Skin being a run-time layer that is not stuck in HTML page cache. [+1 TT] be done within MW core as start of separation.+1 Establish the scope of a skin, not what it currently is, but what it should be?

Take away points: Encourage skins to theme OOUI. Allow skins to provide an OOUI theme. Discussed about in https://www.mediawiki.org/wiki/Front-end_standards_group/2016-01-13 Action: initiate task [+1 prtk]+1 https://phabricator.wikimedia.org/T100896 Extensions to adopt OOUI and should use Less variables from core to make them look "right", without hardcoding details of specific any skins or themes. Expose Less variables to MediaWiki:Common.css (.less) and gadgets. Allows them to make components that "fit in" with all current and future skins. Mobile friendly. +1

https://phabricator.wikimedia.org/T119162

module registration PS28 Anyone looked at it aside from Bartosz and Timo (or want to look at it?) https://gerrit.wikimedia.org/r/#/c/260071/

mediawiki.router Anyone looked at it aside from Florian ? https://gerrit.wikimedia.org/r/260950

Postponed to/scheduled for next meeting

 * https://phabricator.wikimedia.org/T65491, https://phabricator.wikimedia.org/T74547 (VE)
 * TP: we should switch to BlueJeans for capacity reasons (+4mtg)