OOUI/Adoption discussion 2016-10-21

OOjs UI

Participants:
 * Prateek Saxena (PS)
 * Niklas Laxström (NL)
 * Moriel Schottlender (MS)
 * Frédéric Bolduc (FB)
 * Matt Flaschen (MF)
 * Benoît Evellin (BE)
 * Volker Eckl (VE)
 * Helen Jiang (HJ)
 * Bartosz Dziewoński (BD)

Intro Why we're here:
 * MS: Front-end libraries. A lot of websites use existing libraries like jQuery UI.  We have unique requirements, plus performance, plus display things.  We want to make sure everyone is using the same thing.  WE dev'd OOjs and OOjs UI.  OOjs makes JS OO, OOjs UI is a widgeting library.
 * It started out in VE, not a library. Got split to a library.  Other things started using it.  Decision came out to use it everywhere.  All of the styles of it is meant to allow this unified view.
 * Big problem: Within WMF, there is a big problem with OOjs UI being adoptable. It's a different mentality.
 * a. If you look at things like Bootstrap, there is tons of documentation, whether you have a lot of JS knowledge or a little.
 * b. Another thing we don't have is an owner. This is a really big problem.
 * MF: This has come up in practice.
 * MS: There is no official owner, James it the product owner, but it's not the same thing. People don't know who to talk to.
 * MF: Doesn't it make sense to have multiple engineers working on it, if it's a shared library? I agree there should still be an owner.
 * VE: I not only feel that Bartosz is the gate-keeper, but also James. Second thing to your point, that VE is still, because there's no ownership, VE is seen as the main consumer of OOjs UI.  VE problems or possible problems are weighed in higher.
 * MF: Is that because they have more people working on it?
 * VE: Not necessarily, it's just that you can't break VE. Would you disagree with my sentiment that it's the most important consumers.
 * MS: It's kind of like saying WP is the biggest consumer of MW? We do it for MW, but also cater.
 * VE: With MW, there is a lot more adoption.
 * VE: With MW, there is a lot more adoption.
 * NL: We have a couple popups (using it?). The reason it's not used is we target multiple stable versions of core with our extensions.  Main concern which makes me think whether to use it, is will it stay?  I was reading the JS survey, and all of our technologies are not the most popular.
 * Obviously, there is a lot of existing code that would need to be updated to adopt OOjs UI. This would need a designer.
 * MS: One of things that is helpful: If you use it, you never need to touch the styling again. If MW changes something, it propogates.  Is that a high enough consideration, or is it too much of a cost?
 * NL: It's a plus, but there are still concerns.
 * VE: I want to challenge that, it's the same with MW UI.
 * PS: I'm here because I want to see this happen. I understand there are barriers to adoption, but it makes things a lot easier.  There are multiple languages and weird things, but it solves this for you.  It makes things easier in the long run, but harder in the short run.
 * Something like a category selector can be complicated in MW, but with OOjs UI it's easy.
 * HJ: I want to understand what OOjs UI is, and how it interacts with things like VE.
 * VE: I want to bring consistency and easy adoption to the default theme. I understand the problems in the adoption, and I want to see how we can help put or timely efforts into something that could be used more widely.
 * BE: I have questions about UI especially about it being shared between WMF and non-WMF. Would it be possible to have different colors on WMF and non-WMF?  More about reading than editing, is it possible to use UI as a volunteer to improve my wiki.  There are some forms and modules and templates, but not all possibilities are available.
 * MS: If we make it more flexible and easy to adopt, that will also get more people working on it (?)
 * MF: I want to learn about the current status about the library, and adoption, and the challenges and progress.
 * FB: I've been using on my VE work, and I have a couple custom widgets, and I want to learn the big plan for adoption. Do we intend to have this library mainly used for the specific needs of the Foundation.

Meeting: [Discussion of things like mediawiki.widgets, VE widgets that could be in OOjs UI, idea of OOjs UI Plus, where to put things]
 * MS: How to start meeting? What are we aiming for?
 * MF: Is this really an ownership problem, or a resourcing problem? Should we talk about ideas like spinning up an OOjs UI team, or half-team, with people responsible to work on it?
 * MS: Yes, James is the owner, it's more of a technical ownership problem. Bartosz and I work on things, but it's not official.
 * BD: I work on it, but really I'm on Multimedia team. VE is principal now.
 * VE: Imagine you were not available.
 * BD: A couple months ago, that would be catostrophic, now you're pretty good.
 * VE: What we're talking about re ownership is also about resources and general direction of the library. These are ownership problems.  From a structural position, I'm not in a role to be able to give a direction currently.
 * MS: James is really the owner. I do think there's no proper priority, and thus it's harder to approach him if you're not sitting next to him.
 * BE: Who decides the evolution of the UI?
 * VE: At a UI level, it's my responsibility. It's partly consensus, but I'm caring about these things.
 * PS: I do want some actionable items.
 * MF: It seems like we should talk about resourcing.
 * MS: I would be happy if we leave this meeting, defining a task force, to continue deciding on these things. "We care about OOjs UI, we want to keep up with what's going on.  Here's a group of people that care about it."  It's not official yet.  Let's team up.
 * BE: Is it possible to open to volunteers? Is it easy to contribute?
 * VE: Yes and no.
 * BE: Which skills do you use?
 * VE: JS and CSS.
 * PS: We need a widget library
 * MS: The technical documentation is actually really good. If you are a casual developer, someone who would use Bootstrap, not an engineer, there's nothing.
 * VE: Copy and paste solutions for people who want to create gadgets.
 * BD: I think we have a lot of things like this. Comparing it to Bootstrap, it's not so good, but there is a lot of documentation, there are a lot of examples. https://www.mediawiki.org/wiki/OOjs_UI
 * VE: If I'm a dev in my spare time, and I'm looking for a MW library, and I see the buttons there look different from the demo page.
 * VE: We have 3 problems:
 * There have been several changes in the library not reflected in MW.org documentation.
 * We probably don't document some of the newer features.
 * Apex theme is featured in screenshots, but MediaWiki theme Is the default.
 * MW documentation is not set up to... it would be more classy if we also provide rendered code, not just code. Like the OOjs UI playground.
 * PS: We could use guides feature of JSDuck.
 * MS: It's not a fair comparison to Bootstrap. I think one of the things we're missing here is, "What is this library?  What is it for?  What should we use it for?"
 * [Improvements to demo pages]
 * Add a button to display a snippet that generates the widget, beside the "Console" button


 * VE: Most developers start by copy/paste.
 * MS: If we want to help gadget authors, why should you use OOjs UI instead of jQuery UI.
 * PS: If we had to make a choice between fixing the documentation or fixing the adoptability.
 * VE: Low-hanging fruits in the docs, like code examples.
 * http://moriel.smarterthanthat.com/tips/tutorial-building-a-todo-app-with-oojs-ui-part-1/
 * MS: Do you know Tutsplus? You can read the tutorial or skip to the code.
 * MS: This is a two-part post (URL above). Part 1: Setup, prep, getting OOjs UI, project files, building the base, etc.
 * PS: One problem is documentation, people don't know what it is to begin with. Adoptability has other issues, it's not stable, we don't have version 1.  Things are missing, we don't know what.
 * BD: The version is 0.18.6 or something. But it's stable, it's really 18.6, without the zero.
 * VE: From a technical perspective, there's not much blocking 1.0. It's also psychological.
 * FB: So it's like React. They suddenly changed to a major version (0.14 to 15.0).
 * MS: If we compare OOjs UI to React, we might have a logical entry point. In some comparisons, React is known to be component-ized.  The counter things is that OOjs UI is not interpreted.  OOjs UI solves that by just being pure JS.

Action items:

PS:
 * Start working on docs.
 * What on earth is OOUI (and why)?
 * Code snippets in demos page
 * Tutorials/Cookbooks/Guides (tuts+, jsduck, MW, StackOverflow, Blog)
 * Widgets Repo (Central)
 * Contributing.md


 * Talk to the community about converting tools, e.g. gadget owners.


 * MS: While improving docs, collect feedback of a different nature. Why aren't you using OOjs UI?
 * BE: We might also get feedback about too-spacey, etc.
 * VE: What we did in the last months are work on consistency for spacing.
 * BE: Is that kind of project documented on MW?
 * VE: My problem with OOjs UI from a UI library is that the UI sucks in some ways. I would not take it as a dev in some ways.  I want to make sure our docs reflect that.  I know there are fans of Apex, but it's getting less and less usable compared to MW theme.

VE notes:
 * Naming/PR
 * OOjs UI is a widgeting library, but is labelled a UI library.
 * Problems:
 * not easy to use/to adopt it
 * documentation
 * ownership (official): Editing kinda
 * Doesn't mean that several engineers are editing it
 * Translation: several version of MW need to be supported
 * Multiple languages,
 * Usage on different websites