I'd like to nominate T112984: Real Time Collaborative Editing, and T113004: Make it easy to fork, branch, and merge pages (or more), and T114454: [RFC] Visual Templates: Authoring templates with Visual Editor as "secondary" proposals to watch. Implementation of these would require "user interaction experiments" of the sort which seem to be contemplated by this working group, and we certainly wouldn't want to push forward with them without UX input.

(There are likely other summit proposals which this working group should keep a similar eye on; I haven't audited the entire set of proposals, I'm just listing the ones I'm personally familiar with/involved in.)

I think this is a great area for the Front-end-Standards-Group to own. @Volker_E, is this something y'all can take on?

I think T114065: The future of MobileFrontend is a big deal, completely possible, and something that would benefit from discussion at the conference where it can get noticed by a wider audience who may be willing to pitch in with the refactorings that are needed. It would be especially useful if that discussion made the benefits of doing the work more visible to the Product Managers that may be present. I think this is often seen as a "developers want to pay down tech debt" topic rather than a "core features that move us towards first class non-traditional device support".

From @Volker_E and myself from a UI-Standardization and Front-end-Standards-Group perspective.

Must have:

• T111588: RFC: API-driven web front-end (and related T106099). Need to better separate business logic from skin formatting. Motivation: Improved performance for logged-in users and ability to effectively do Edge Side Includes (ESI) embedding for updates to the skin HTML at a global level. Thus skin variants wouldn't linger in varnish.
• T114065: The future of MobileFrontend

Nice to have:

• T114071: Let's discuss the skin creation process. Developers in the community have been repeatedly asking for it. Resolution on T111588 would provide flexibility to consider non-PHP skins. Either way, a possible abstraction layer could be supported in both PHP and Node.
• T112996: A vision for templates / wikitext 2.0. Interesting to raise awareness, but seems too generic at the moment. T114445 is related (also by @cscott) and worth discussing at the summit (also covered by "Content format" working area).
• T112984: Real Time Collaborative Editing. Summit plan sounds good. Medium priority.
• T113004: Make it easy to fork, branch, and merge pages (or more). Brainstorm session about UX solutions. Related to T90948 – alternative diff visualisation.

Less important:

• T114454: [RFC] Visual Templates: Authoring templates with Visual Editor. Not sure editors want this. Could be interesting for a breakout session though.

Not at summit:

• T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces. Already on-track with little controversy. If further consensus or guidance is needed, can use the regular RFC process for finalizing it.
• T112991: Semantic image styles / beautiful layout. Not actionable at the moment. If we have progress on a clear proposal, we can bring it back in. @Volker_E to catch up with May (@violetto) and @cscott. The summit would be a good venue for this!

@Volker_E and @Krinkle: Excellent work on the first pass! This is really helpfully and clearly expressed. I copied and pasted your current version into the description, but please refine it as the discussion progresses.

FYI, I'm working on a very drafty-draft of the schedule now. See Monday 2016-01-04. In particular, my current bias is to hold the big room for this area at 2pm in the first version of the schedule. You all may choose to address the elephant in the room at this session, or you might instead choose to make it lightning talk city. We'll be refining this part of the schedule in this task.

We talked about this in the Frontend Standards Group meeting this morning (notes will be posted to mw.org: FSG/2015-12-16). I suggested that we might be combining skinning/presentation - possible combination of

• T114071: Let's discuss the skin creation process
• T114065: The future of MobileFrontend

...and that the people interested in this area may decide to use the Monday User Interface spot to talk through this one. Timo pointed out that any next generation skinning process would need to support the Mobile Frontend case, so that aspect of the combination is good, but there are other items in the MobileFrontend task that could be distractions from the overall skinning process. Having a smaller breakout session for "MobileFrontend other stuff" could work.

Note that I'm leading the session "across the hall" in R2 in this time slot (T112987: Separating infoboxes and navboxes from article content). So I wouldn't be available for discussion of T112996: A vision for templates / wikitext 2.0, T114445: [RFC] Balanced templates, T112984: Real Time Collaborative Editing, T113004: Make it easy to fork, branch, and merge pages (or more), T114454: [RFC] Visual Templates: Authoring templates with Visual Editor, or T112991: Semantic image styles / beautiful layout. If that's a problem, we should probably reschedule one or the other.

cc @RobLa-WMF, @Krinkle, @Volker_E.

Per @cscott's edit from earlier today (schedule edit), he's no longer running a conflicting session.

A few questions we explored during this session:

• What are we trying to solve here? Trevor pointed out this question: How can we change things without breaking everything?
• Is the skin layout stable? Jiang from Google pointed out that it's hard to get infoboxes, and Timo pointed out that infoboxes aren't recognized in MediaWiki.
• Semantic annotations? Jiang poitns out Wikipedia is multilingual. RTL vs LTR
• Skins and mobile: is the goal to fix skins so that we don't have to hack on things like mobile frontend other methods? Next 3-5 years for skins perhaps?
• What/who are we going to optimize for? Trevor points out "we don't know; lots of ideas"

More detailed notes here: https://etherpad.wikimedia.org/p/WikiDev16-T119162

Real-time notes: https://etherpad.wikimedia.org/p/WikiDev16-T119162

Take away points:

• Improve backend methods that Skins use and create methods where missing. Move away from "blobby" datavars that can only be embedded. These methods should expose actual data instead of just html blobs.
• Encourage skins to theme OOUI. Allow skins to provide an OOUI theme.
• Extensions to adopt OOUI and should use less-variables from core to make them look "right", without hardcoding details of specific any skins or themes.
• Need more methods like addPortletLink(). They should be provided and maintained by the skin (mw.skins) instead of mw.util. Exposed without requiring gadgets/extensions to hardcode any html when extending interfaces.
• Allow wiki templates to add CSS to a page.
• Wiki templates and Lua modules to use OOUI. (There are WIP patches introducing something like <button> and <icon> tags in wikitext, rendering OOUI icons and buttons. Make usable from Lua. Security for WMF production?)
• Expose Less variables to MediaWiki:Common.css (.less) and gadgets. Allows them to make components that "fit in" with all current and future skins. Mobile friendly.
• Make infobox, nav boxex etc. page components that are expanded by post-processing (e.g. <mw-infobox>). Not as part of wikitext parse. Reduces cache fragmentation and rendering inconsistencies after changes.
• Standardise mark up for things like infoboxes, nav boxes etc. across projects/langs wikis. Does not require skin rendering or wiki specific styles to change per se.

Goals:

• Treat as first-class citizens: Apps, mobile web, desktop web, logged-in users. All with the same infrastructure and performance.
• Ability to change skins without breaking extensions and gadgets. Provide page-level APIs instead of HTML or DOM being the API.
• Avoid parser cache corruption and inconsistency when skins change. (Relates to T114542). Skin being a run-time layer that is not stuck in html page cache.

Action items with owners: (from T114071: Let's discuss the skin creation process)

• Establish the scope of a skin, not what it currently is, but what it should be
• Make themes (extension:theme style) happen with a practical API!

@GWicke, @Volker_E, and I had an impromptu meeting yesterday to discuss how this area might be part of the transition planned in T124504: Transition WikiDev '16 working areas into working groups and RFC @GWicke drafted in T123606: RFC: Implement ArchCom-affiliated working groups (process inspired by Rust's "subteams"). I don't think we reached consensus in that meeting on the subject. @GWicke seemed skeptical, but we agreed it would be best if he expressed his concerns here. Gabriel?