Frontend standards group/2014-09-19-Weekly

= Kickoff meeting agenda (2014-09-19) =

Discussion (~10min)

 * Who is on the team?
 * Members were chose by time available, previous work, critical to the groups success
 * How can the group can be most effective?
 * How does the group fit into the RFC process?
 * Not trying to sideline the RFC process
 * May not fit well into the day to day foundation acitivities
 * RFC's arent the great at follow and GSD
 * Jon wants to make sure he is not detached from Mobile
 * Jon will continue to be in Mobile Web working on tasks as neded but will involve the web team in using what this group produces
 * When should meetings be scheduled and how often?
 * Does this need to be a weekly meeting?
 * Play it by ear
 * What time? Early morning in SF
 * yeah probably a bit earlier for the remotes! +1
 * What are the group's short, mid and long term goals?
 * Trevor: "Every single team will be using the same technology to make the features that we make."
 * Brion: Mobile Apps will be a little different but still keep consistent where makes sense: use RL for styles, use a common templating system for customizable strings, etc
 * Making it easier for horizontal movement between teams by keeping things more consistent
 * Making it easier for newcomers to hack on our codebases by having simple, concise, common idioms for common tasks.
 * External stakeholder
 * Invite them as needed

= Status check (10min max) =
 * MediaWiki theme for OOjs UI (soon)
 * Trevor with Bartosz, pretty much done
 * Teams will be able to use OOUI (not off brand) next week
 * Server-side OOjs UI (weeks)
 * set of PHP classes that have the same API as JS classes (subset, naturally)
 * WIP [Trevor]
 * for next meeting: bringing items 'back to life' with JS after created statically?
 * Icon system (needs scope)
 * Form standardisation (buttons, inputs, selects, checkboxes, radios etc.)
 * Mobile and Growth (and soon Flow) to be using same markup/css
 * Bartosz has done the early work for a Grunt task that can a pile of SVGs and a JSON config file to generate the colored svg and png renderings and the LESS for them
 * (how can we do this at runtime with ResourceLoader? figure this out in near future!)
 * It aligns with the Core team's wish to "librarize" components that are currently internal to MediaWiki and to have a build step that readies the source tree for deployment.
 * It's almost certainly impossible to do rasterizing SVG→PNG in RL, as that takes on the order of seconds. Build step needed? :(
 * i would recommend modifying SVGs in RL and rasterizing via 404 handler?
 * Summary: The generated built files should also be included in version control. MW should be runnable straight from git/tarball.
 * Templating (needs a decision)
 * Brion -> putting this onto the agenda for the arch committee, let's make a decision soon
 * We would recommend mustache based language
 * Skin system (needs Trevors times)
 * Trevor has ideas but no implentation yet
 * Expect to use server-side OOjs UI bits
 * OOUI template widget (days)

= Architectural issues (20min, or at least leave 10min) =
 * Icon generation + ResourceLoader
 * in general agreement that build step is best for now
 * include build artifacts in source control & tarballs (this is consistent with what we do on mobile apps!)
 * runtime conversion could be great for user scripts and gadgets but more infrastructure is needed to make that really feasible. revisit then?
 * but want to standardize that build step on npm+grunt
 * and have a consistent way jenkins can be configured to make sure things don't get out of sync

= Planning (10min) =
 * Action items for coming week
 * Reach out to Derk-Jan [Tomasz]
 * Schedule re-ocurring meeting [Tomasz]
 * Get some movement going on the template RfC, with input from frontend group usage needs [Brion]
 * Start thinking about and divide down the template vs live dynamic issues
 * Generate tentative Roadmap [Trevor]
 * Agenda for next meeting
 * Templating language
 * Who should we include? Shahyar, Erik B, Kaldari
 * Review RFC
 * open questions on dynamicalization of statically-generated template output?
 * (does this relate to oojs ui server-side generation?)
 * Server-side OOUI
 * How to bind the generated HTML to the JavaScript objects.
 * (shared html templates that are recognised, KnockoutJS-like bind detection without rerendering the DOM)

= Team members & advisors =

Implementors

 * Trevor Parscal
 * Jon Robson
 * Bartosz Dziewoński
 * Timo Tijhof

Advisors

 * Ori Livneh
 * Roan Kattouw
 * Brion Vibber

= External stake holders =
 * Growth: Matt Flaschen
 * Flow: Shahyar Ghobadpour
 * Multimedia: Mark Holmquist
 * Design: Pau Giner
 * Mobile Apps: Brion Vibber (or Monte Hurd if Brion isn't advising)
 * Mobile Web: Jon Robson
 * VisualEditor: Trevor Parscal
 * Non-WMF skin authors

= Team meeting schedule =

TBD

Team goals

Short-term ...

Mid-term ...

Long-term ...

Next meeting(s): Server-side OOUI How to bind the generated HTML to the JavaScript objects. (shared html templates that are recognised, KnockoutJS-like bind detection without rerendering the DOM)

Add'l todos: Brion: get some movement going on the template RfC, with input from frontend group usage needs start thinking about and divide down the template vs live dynamic issues