Wikimedia Engineering/WMF Tech Days 2013/Front-end Direction
Front-end Direction
?
Event: | WMF Tech Days 2013 |
Details: | 2012-09-10 13:30 - 60 minutes - North-side of 3rd floor |
Group: | {{{group}}} |
Start: | {{{start}}} |
End: | {{{end}}} |
Team: | {{{team}}} |
Lead: | James Forrester, Terry Chay |
Status: | See updates |
Provisional Proposal
edit- 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.
- 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:
- 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- Talk through the proposal
- Is this the right group for making a decision on this?
- If not, why not? Who's missing?
- Talk through a few current RfCs and possible RfCs (whether the process can work for them, and to kick off these discussions in breakout)
- Make sure proposal (or adjust) can deal with Front-end engineering code review backlog
- Plan to document, announce, and criteria for safe-to-fail testing of proposal and various parts
- Brainstorm some RfCs that should exist but don't
Etherpad http://etherpad.wikimedia.org/p/WikimediaEngineering2013-FrontEndRfC