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

Midst-meeting notes on Etherpad

Provisional Proposal edit

  • The "front-end architecture group" comprises:
    1. The front-end engineering units: VisualEditor, E2, E3, Fundraising, Mobile, Language, Multimedia, Analytics
    2. Contributors from the front-end development community
    3. (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 edit

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

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