Front-end standards group/2015-11-04

Agenda

Reschedule?

VE: Success! :) From here on it's taking place on Wednesdays bi-weekly from 8am - 8:50am PDT

Opening-up meeting to more community members:

VE: Reached out to Florian and to Santhosh from Language Engineering team to join, also updated the MediaWiki page to reflect recent changes.
Also invited RobLa

Workboards improvement for visibility?

A new workboard has been created: https://phabricator.wikimedia.org/project/board/1616/
- Open for inputs on how to structure and what to populate there.

Separation between this group and UI standardization group?

Last week decided, that separation useful, workboard as begin on phabricator level

RobLa: Developer summit and front-end topics

TP: Defining the roles of the two groups, what differs them and how to inter-operate
TT: This group does not see itself outside of RFC process, but coming up with solutions, where people in FE std group can stand together on for upcoming RFCs.

VE: Still awaiting feedback from you guys if we can as a group agree on one of the proposals.
- BD/JR: "VE JDI" :)

Have a standard way of doing hash fragment routing in MediaWiki [1]

JR: using Window manager?
performance issues when used mw wide
JR: not used for key interfaces; the other benefit of this is that it encourages is defer loading code.
AG: for modals ok

Better JS minification? (RK, JR) - https://phabricator.wikimedia.org/T49437

Max Semenik proposed usage of UglifyJS a while ago, but there were some concerns around performance and reliability. Nowadays after the reorg, the performance team is doing a great job of owning ResourceLoader, so we should talk to Timo and Ori about this
TT: we would need a way to communicate with that Minifier in a low-latency way.
TT: caching issues
TT: stalled for now

usage of jquery.tipsy and alternatives (Ori)

OOUI Forms - Status?

implements most of the existing HTMLForm fields, you just need to pass "ooui" to the constructor to use it
-> that doesn't work, if the form inherits directly from SpecialPage and not from FormSpecialPage or/and does not use HTMLForm directly (some special pages use HTMLForm directly), but converting plain HTML to OOUI shouldn't be that big problem, too, it "just" takes a bit longer
--> Done, see https://phabricator.wikimedia.org/T107037
~10 Special Pages done
Missing special pages should have a phabricator task blocking https://phabricator.wikimedia.org/T107037, to see how many pages needs to be converted (I'll take a look on it)

We should switch to BlueJeans for capacity reasons (TP)