Wikimedia Engineering/WMF Tech Days 2013/Front-end Direction

Midst-meeting notes on Etherpad

Provisional Proposal

 * The "front-end architecture group" comprises:
 * The front-end engineering units: VisualEditor, E2, E3, Fundraising, Mobile, Language, Multimedia, Analytics
 * Contributors from the front-end development community
 * (Participation, as needed from Design, Platform, etc.)
 * Each unit will have one person from each of these units who will be expected to read and respond to RfCs on behalf of their team; for those teams for which it makes sense, this might be split between people, or merged across teams.
 * I'd imagine this would be the following - there may be people I've missed, for which I apologise, and people shouldn't feel pressured into accepting a nomination:
 * VisualEditor: Roan Kattouw (Trevor Parscal as a second).
 * Editor Engagement teams: Matt Flaschen.
 * Fundraising: Matt Walker (Katie Horn as a second).
 * Mobile: Jon Robson (Ryan Kaldari as a second).
 * Language: Santhosh Thottingal.
 * Multimedia: Mark Holmquist.
 * Analytics: Ori Livneh (Dan Andrescu as second).
 * Community: Bartosz Dziewoński ("Matma Rex") and Derk-Jan Hartman ("TheDJ") - possibly others?
 * "General front-end architecture": Timo Tijhof.
 * Administrivia: James Forrester.
 * The group would be part of the forthcoming RfC process
 * As the experts who would as a group give the "Front-End" point of view for general RfCs
 * Front-end specific RfC evaluation, needs to work in a process-compatible manner for the general architectural meeting (and summit). [Note: Architectural meeting is after this one]
 * RfCs would be triaged and improved as currently, and be flagged to people in the group who might in particular have something to add/improve on them
 * All members of the group would need to "sign off" on RfCs for them to pass (or say they weren't interested in passing an opinion ("opt-out"). When an RfC was sufficiently discussed, group members could "approve" or "reject" it; the secretary (or whomever) would ping those who hadn't responded every now and then to remind them to comment, and mark those that were passed by the group as such.
 * Every couple of months or so the secretary would organise a quick (IRC?) meeting to see if anything needed pushing forward, or any new RfCs needed commissioning.

Things to discuss

 * 1) Talk through the proposal
 * 2) * Is this the right group for making a decision on this?
 * 3) * If not, why not? Who's missing?
 * 4) Talk through a few current RfCs and possible RfCs (whether the process can work for them, and to kick off these discussions in breakout)
 * 5) * LESS
 * 6) * Grid system
 * 7) * Moving language files into JSON blobs
 * 8) * Gadgets 2.0
 * 9) * Ajax page loading in MediaWiki
 * 10) * CSS in Templates
 * 11) Make sure proposal (or adjust) can deal with Front-end engineering code review backlog
 * 12) Plan to document, announce, and criteria for safe-to-fail testing of proposal and various parts
 * 13) Brainstorm some RfCs that should exist but don't

Etherpad http://etherpad.wikimedia.org/p/WikimediaEngineering2013-FrontEndRfC