Talk:Requests for comment/Redo skin framework

Feedback
Re: redoing the skins system: yes, please! Even as a draft, I think this RFC looks very good. Implementing this RFC is a goal for 2014? (cc: Dantman, Isarra, Matma Rex) --MZMcBride (talk) 01:56, 17 April 2014 (UTC)
 * I can't speak to official resource allocation, but I'm pretty sure that if I could peel away some time this summer or fall from VisualEditor and pair with someone who might have more backend focus to compliment my skillset (as Roan did with ResourceLoader) it could certainly be accomplished this year. I would really like to see that happen, so that is essentially going to be my pitch should this gain some momentum. I'm aware of the work you have in mind this summer, as far as reorganizing skins, and I think this work would need to be synchronized with that as well. Trevor Parscal (talk) 07:18, 17 April 2014 (UTC)
 * Oh gods I hope this happens. -— Isarra ༆ 00:26, 30 April 2014 (UTC)
 * I second MZMcBride's "yes, please!". I think this is a great RFC and it has my full support. It
 * has been needed for a long time
 * has the potential to affect a great many fringe-developers (skinning is usually my first foray into a new project)
 * has a clearly defined goal
 * is generally awesome
 * --Daniel Renfro 17:18, 16 June 2014 (UTC)

Jack Phoenix would be a good one to get involved too, since he's probably the single most active developer of skins these days. He'd both have an idea of what we need and perhaps how it could be done, and what we already have that does work. -— Isarra ༆ 00:26, 30 April 2014 (UTC)
 * I'm still working on the general when and less on the detailed how. but indeed I will be pulling in active skin developers. When Catrope and I made ResourceLoader we made a very detailed proposal, got feedback, had many discussions with people both in the front-end space and otherwise, and eventually produced something that met everyone's needs as much as possible. We also picked up help from people like Krinkle who became major contributors and later became maintainers. I believe this process was successful, and plan to do something very similar with skins. I will make sure to get in touch with Jack Phoenix as things progress, but I will also be reaching out more generally for others as well. Trevor Parscal (talk) 15:47, 23 May 2014 (UTC)

Relationship to OutputPage RFC
Hi Trevor, thanks for submitting this! This seems like a direction we pretty clearly need to go in. Do you see this RFC being completely complementary to the OutputPage refactor proposal (which could still continue to proceed independently), or something that would need to be accounted for in any rework of OutputPage? -- RobLa-WMF (talk) 19:18, 17 April 2014 (UTC)
 * I will have to familiarize myself with the OutputPage refactor proposal when I return to work (on vacation right now) to answer this accurately, but I believe that the benefits of doing them in tandem are surely going to be offset by the slowness of needing consensus on the design of both changes to proceed with any. If I could advise on the output page stuff I believe we can gain better separation without slowing things down. Trevor Parscal (talk) 15:42, 23 May 2014 (UTC)

Links to stuff
Add items here! (And remove items once they're added to the RfC itself, or if not useful/pertinent). HTH. –Quiddity (talk) 19:30, 25 June 2014 (UTC)
 * Separating skins from core MediaWiki (and /Progress) which is part of the removal of Manual:Skin autodiscovery
 * VisualEditor/Skin requirements
 * Manual:Gallery of user styles
 * Category:Skinning
 * Developer hub
 * Layout architecture of MediaWiki pages
 * Design Team
 * UX standardization
 * Agora/Engineering
 * Wikimedia Foundation Design/status
 * Trello: Mediawiki.ui
 * Category:Skin extensions
 * Category:Design audit
 * Architecture meetings/RFC review 2014-06-20 - Discussion of revamping MediaWiki's skin systems: Trevor Parscal's "Redo skin framework" and Bartosz Dziewoński's "Separating skins from core MediaWiki" work
 * https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-06-25-17.30.log.html (pending onwiki page creation)
 * Requests for comment/HTML templating library
 * Requests for comment/HTML templating library/Knockoff - Tassembly
 * Architecture Summit 2014/RFC clusters (probably many?)
 * https://xkcd.com/927/

June 25th meeting
IRC log from the 25 June 2014 meeting. Sharihareswara (WMF) (talk) 18:57, 7 July 2014 (UTC)

Problem statement, Goals / Requirements, existing vs. new solutions
I think it would be useful to put more effort into making the problem statement more precise, and explicitly define the goals and requirements of this RFC. These can then be discussed on their own merits.

With an agreement on the goals & requirements it then becomes easier to evaluate existing and new solutions. I would love to see such a discussion in this RFC as well, ideally with sufficient detail on new proposed solutions to allow at least a cursory evaluation. -- Gabriel Wicke (GWicke) (talk) 21:06, 9 July 2014 (UTC)
 * I'm sorry you didn't find the problem statement clear. I think other people did, so maybe you could ask a more specific question about it and I could do my best to answer it. The page got modified by a lot of people and much of the information was contradictory or generally incorrect. I have just gone through the entire proposal and ensured it is correct and I believe complete enough for this early stage. Please give it another read and let me know if you have additional questions.Trevor Parscal (talk) 04:07, 10 July 2014 (UTC)
 * Right now it's a bit confusing because we launch right in to specifics about the HTML output and APIs. That's not really a general problem statement. Perhaps we could begin with a summary/thesis statement, like "The structure of MediaWiki skins is highly inflexible, and is often dependent on direction manipulation of HTML output, rather than through well-designed APIs. This lack of abstraction results in a skin architecture that is brittle and ultimately deters developers from creating great new skins." That could be wrong, but I'm following Cunningham's Law here. ;) Steven Walling (WMF) &bull; talk   17:46, 10 July 2014 (UTC)


 * In addition to Steven's point, I still think the goals of this RFC deserve to be more clearly defined in its own section. The 'principles' section at the end of the RFC has some of this material, but arguably also contains some of the proposed solution. Maybe you could move this between 'Problem' and 'Solution' and trim it down to the bare goals? In my experience, a good benchmark for a goal is whether it is useful to evaluate potential solutions. Basically 'what do we want to achieve', not 'how'. -- Gabriel Wicke (GWicke) (talk) 19:20, 10 July 2014 (UTC)

What's the value to end-users?
To piggy back a bit off of Gabriel's question to more clearly understand the problem, I'd like to better understand what the problem is that this resolves from the user's perspective. Is this RFC just resolving problems for the engineers who work on Mediawiki skins, or does this provide value to our users? To engineers, I think there is an intuitive understanding of how this RFC benefits our end users, however I think if this RFC would be stronger if it were framed from the perspective of delivering value to our users - rather than just repaying technical debt. I think this could be achieved by something along the lines of making the end goal of this RFC to be delivering a responsive skin for Mediawiki. A requirement of delivering a responsive skin could (and should) be the deeply needed reworking of the skin framework. I think approaching it from this perspective - letting the thing the user interacts with drive the technical requirements - will set this project up to more successfully 'break the silos' we all keep talking about internally. With up-front design and product involvement, and with an approach of iteratively and frequently delivering a responsive skin (and validating the decisions made as we go), we would be more certain earlier on that the work we put into this project is worthwhile and truly serves end-users. Further, driving this from the perspective of the users helps everyone working on this project better empathize with our users, which has the benefit of calibrating work against users' needs - ideally ensuring that we are not spending effort on things that are less or not valuable to them. Arthur Richards (talk) 21:24, 10 July 2014 (UTC)