notes taken mostly by me and terry
New page
The following are notes from the '''[[Metrics and activities meetings/Quarterly reviews|Quarterly Review meeting]] with the Wikimedia Foundation's [[mw:VisualEditor|VisualEditor]] and [[mw:Parsoid|Parsoid]] team on July 17, 2013 (2pm-5pm)
'''Present:''' Roan Kattouw, Trevor Parscal, Gabriel Wicke, Howie Fung, Terry Chay, Sue Gardner, Erik Möller, Tilman Bayer (taking minutes), James Forrester, Rob Moen, Phillippe Beaudette
'''Participating remotely:''' Ed Sanders, Timo Tijhof, C. Scott Ananian, Subbu Sastry
''Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material''
__TOC__
James: Welcome<br/>
will review past quarter (Q4), but also look at this Q1: July-September<br/>
both about VisualEditor and Parsoid
Gabriel on Parsoid<br/>
achievements in past Q4, tasks for Q1
== Parsoid ==
[[File:Parsoid review Q2 2013.pdf|thumb|420px|Presentation slides from the meeting]]
Gabriel:
=== Objectives ===
Make it easy to view, reuse, and edit content
1. convert wikitext to semantic HTML+RDFa (faithfully)<br/>
a standard format we are moving to
2. Support HTML editing, converting back without dirty wikitext diffs<br/>
^^ we are at here
3. once this is achieved, use HTML in MediaWiki core
4. Support wikitext editing with Parsoid
Long term, Parsoid would be used in reverse, to convert to wikitext on demand (instead of converting wikitext to HTML).
=== Progress in 2012/13 Q4 ===
1-2 above: Solid parsing and roundtripping of basically all content without dirty diffs
* achieved high degree of compatibility with existing content
* delta some pretty rare edge cases
* used a combination of several innovative technicques to achieve that (see our [https://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/ blog post] a while ago)
then shifted focus on performance and scaling
* goal met with pragmatic caching setup, on-edit parsing and expansion reuse
* Paid off to start tracking full load in early June
* tracked all edits in early June.
* Resulting in success: Can *not* see VE or parsoid deployments on server load graphs :)
Other features:
* templates: {{done}} exceeded
** went for simple wikitext editing, because we don't yet have the necessary information to check input type for template fields
** hope to move to visual editing of templates, too
** Erik: when doing editing of template parameters, you still encounter wikitext
* cite extension: {{done}}
* tag extensions: {{done}}
** not implemented in VE yet, but done
** there is a GSoC project on <nowiki><math></nowiki> that uses code
* categories, defaultsort parameter: {{done}}
* images and parameters: partially met, ongoing
** rendering: fine, editing: not quite
** Erik: like changing the size? Gabriel: ex. when doing "left" and "right" alignment at the same time, it doesn't exclude them. Straightforward to do, just needs a bit of time
* Public HTML load / save / expand API for VE, Google, bots, offline readers like Kiwix, etc. (Deferred to Q3 2013 = Q1 2013/14)
** ex. Google would like to load the Parsoid HTML and get rid of their custom parsers
** Kiwix
* Incremental re-parsing after wikitext edits
** - was planned for performance, but turned out not to be necessary because load not on parsoid cluster
** possibly use for HTML<->WP switching in Q3 2013 (= Q1 2013/14))
=== High-level goals in 2013/14 ===
see also: https://www.mediawiki.org/wiki/Parsoid/Roadmap
* continued support of VE with editing features, bug fixes etc.
* start leveraging HTML in MediaWiki core (see 3)
** HTML and page property (e.g. categories) storage (also, Flow might use the HTML format): idea, store the meta-data outside page content
** HTML diffing (already doing this, but no frontend for it yet), basic authorship maps - we already diff on the way in, so this is not expensive
*** James: Scott would like us to call them praise maps instead of blame maps ;)
**Stretch goal: Parsoid HTML for page views.
*** Erik (explains): so far, legacy MediaWiki still does the HTML rendering for readers. When you press edit, the brower contacts Parsoid to get payload for VE to edit. The idea here would be that the reader would have a parsoid-parsed version of the content and could skip this process == instantaneously switch between it
*** Roan: it would also remove some of the small remaining rendering differences between editor and reader HTML.
*** Trevor: It's not trivial. The extra parsing of the page adds bloat to the page. Also, gadgets do stuff to modify content. So it's not trusted. It's not Parsoid, it's Parsoid + gadget modifications.
*** Erik: still fundamental reservations about doing this?
*** Trevor: agree with principle.
***Gabriel: could always fall back to the DOM that was sent in case gadgets modified the displayed DOM
* Forward-looking: Investigate HTML-based templating
*** Problem right now: templates still entirely based on wikitext
*** Gabriel: Could eliminate unbalanced template
*** eliminate wikitext from templating
*** Erik: could also make MediaWiki for 3rd parties without wikitext
*** Trevor: ultimately, would like to use a DOM for templates too
=== Tasks for Q3 2013 (= Q1 2013/14)===
* Image editing refinements
** [straightforward]
* provide public HTML API
** [straightforward]
* research: Language variant support
** [hard, Q3-Q4>]
** need this for Chinese (multiple variants in same document)
** difficult because of intricacies in the way variants are processed in MediaWiki
* Research: Support switching between HTML and wikitext within one edit
** [hard, Q3-Q4 >]
** without saving in between
** trouble: we'd like to preserve annotations in the DOM while switching between the two. difficult to do in wikitext
**don't know how long it will take, but it will be important. It has been requested quite often. Sue: How essential is this? Gabriel: VE is not the most efficient workflow for everything yet, so people would like to switch back for some tasks. Sue: so it's important for power users? Erik: yes
* HTML / Wikitext compound storage; support Flow
** [medium, Q3-Q4 2013 = Q1-Q2 2013/14]
** requires some forethought for figuring out the right interface. optimize, and interact with Flow team
** Erik: substitute Varnish based caching with db storage? Gabriel: Yes
* Enforce proper nesting of transclusions.
** [hard, Q3-Q4 2013]
** We do this currently through fully expanding them, and figuring out which part of page is affected. Unbalanced tags can affect the entire page (via template dialog)
** do something that would nest tags (ex. table start, table row, table end would still be allowed to live in different templates, but proper nesting of whole table would be enforced)
** James: proposal might be to have metadata that says if you start it this way, you must end it that way
** Erik: Could we burn this all down. Is that legitimate? JamesF: Now that we have Lua, you can replace that with Lua-generated HTML. Gabriel: Issue is a choice to pass information into template as a parameter (e.g. Table content). might be doable but we don't have good data
** Gabriel: thought about disabling some of those templates, but would disrupt too much existing content
** Trevor: also, can't do proper looping of wikitext templates
** C.Scott: other template systems invent new [[w:Syntactic sugar|sugar]]. The basic problem: they don't want to shove content from article into template as arg. Make a sugar for template so that what looks like start and end of tables actually looks a certain way. Gabriel: still need to enforce nesting for that construct. Cscott: imagines VE has a nice way of editing such a thing, so that thing goes away long term.
* Testing infrastructure improvements
** [straightforward, Q3-Q4, 2013 = Q1-Q2 2013/14]
*** Testing 160k pages, thus ailing a bit (Marco is working on it)
*** might be reused by VE or Mobile for browser testing (it's a framework)
* Performance: More efficient template updates (which part of page affected by changed template?), currently biggest issue for API
** [straightforward]
** Need more information from preprocessor
Other tasks on the horizon (beyond Q1)
* Parse most transclusion parameters to DOM once type info is available<br/>
(medium, likely Q2)
* HTML-only wiki support
** [hard, Q2-Q4 2013/2014]
** pretty difficult, not just storage, but also all those extensions that rely on hooks in PHP parser
** James: outcome would be you can use without every using wikitext anywhere<br/>
Erik: so HTML based templating not going to be in Parsoid, but core?<br/>
Gabriel: Lets see what the best solution is after figuring out what it should do.
* Non-Wikipedia projects
** [likely hard, Q2-Q3 2013/2014?]<br/>
e.g. Wikibooks: labeled section transclusion (LST)<br/>
problem there: currently extension tags wrapping whole page<br/>
Erik: labeled section transclusion is our one feature that would probably make Ted Nelson proud ;)<br/>
Gabriel: probably lots of special cases, for example treat section as HTML5 tag - need to investigate
* Research DOM-based templating
** [hard, Q2-Q3 2013/14]
* Use Parsoid HTML for all page views
** [ hard, stretch goal for Q4 2013/14?]
=== Questions and Discussion ===
Erik: To restate one part: There is interest in Flow to go HTML-native. Store HTML from beginning and not surface wikitext (or restricted wikitext) through UI<br/>
That would be pretty big change of UX.
Erik: Any implications for Parsoid from real-time collaboration plans?<br/>
Roan/Trevor: Unlikely. It's about VE. At the end of the day Parsoid doesn't care about that.<br/>
Gabriel: When you need a snapshot, then Parsoid gets involved.<br/>
James: it would affect blame maps<br/>
Trevor: need to annotate which user created what<br/>
C. Scott: you mean "praise maps" ;)
== VisualEditor ==
[[File:VisualEditor - 2012-13 Q4 quarterly review deck.pdf|thumb|420px|Presentation slides from the meeting]]
James:
=== Objectives ===
* Be the default (and best) editor for all Wikimedia wikis
** adding currently-missing editing abilities (e.g. tables)
** better l10n/i18n (e.g. language variants)<br/>
improve performance, stability, scalability (get easier, faster, better)
* Be the default editor for MediaWiki core (shipped with tarball) available for 3rd parties
* Be a great general editor for non-MediaWiki users to (e.g. WordPress), encouraging an ecosystem of reusers<br/>
keeps us honest in terms of architecture, too
=== Progress in 2012/13 Q4 ===
(see also [[:File:VisualEditor-Parsoid - 2012-13 Q3 quarterly review deck.pdf|slides from last review]])
* 2012/13 Q4: a beta "general content" editor in production as default for "all" '''[Ongoing]'''<br/>
fully deployed on enwiki this Monday
** templates: met/exceeded
*** as promised (see mockup)
*** met: dialog editor
*** exceeded: did multi-part templates
*** we didn't more for smooth editing environment (did some changes since end of Q2)
*** (ex. hinting, delays dealt with)
** references: last time, didn't have a mockup yet
** met: dialog - add new references, duplicate references, and edit content, citation name. can remove/insert/replace reference lists
*** exceeded: do group references (not happy with design, though)
*** more work on better workflow for adding references particularly in integration with wiki-specific standard citation templates<br/>
Erik, Sue: ref groups from POV of editors?<br/>
James, Trevor: will be drop-down list, collapse fields that are not relevant for most<br/>
Trevor: initially, this was our most ugly feature ;), got a lot of feedback, improved workflow (commit is already in Gerrit, deploy soon)<br/>
Erik: VE right now driven by features that exist in wikitext, some of which were ill thought out in the first place (which now impact VE experience negatively, too), can improve these later<br/>
Sue: can we make it so that <nowiki><references/></nowiki> shows up automatically as soon as I add a ref? (I believe there may be a bug for that already.)<br/>
Trevor: strongly believe that this should not be in VE<br/>
currently shows red error message when not present<br/>
instead, should generate reflist automatically<br/>
Erik: but for consistency of UX, should ...<br/>
James: some complication: templates for reflist eg. on ptwiki<br/>
some discussion on how much invest in cite extension rather than replacing it?<br/>
Roan: Trevor's change (plan on improving the UX with respect to handling existing references, ISBN and URL recognition, etc.)<br/>
(James:)
** categories
*** '''met''': page-level dialog lists current categories, and category sort key and page's DEFAULTSORT setting
*** '''not met''': show editors the (uneditable) categories transcluded from templates
*** Further work: transcluded and hidden categories; editable language links and page behavior settings (#REDIRECT, etc.)<br/>
in Amsterdam, flagged language links to Wikidata team, but no followup yet<br/>
Erik: language inspector?<br/>
James: that's a different thing, helps with rendering of RTL content etc.
** images
*** '''Met''': can add images, videos, change captions, resize thumbnails by dragging
*** '''NOT Met''': Change non-caption settings on a media item, like thumb/frame, float status, exact size in pixels, etc.
*** Further work: Uploading new items on page (through drag-and-drop)
**** Erik: for multimedia team, might be nice to have a tab or option to list user's current uploads. James: this is something we discussed with Wikia<br/>
Trevor: showing content time-based is a problem, but if uploaded "by you" it is much safer<br/>
Scott: could offer people to use camera to capture people's photos while writing, for avatars in version history :-)<br/>
James: maybe for third party users ;)
** deployed for all users on main and user namespace on *all* Wikipedias
=== Expected Deliverables in 2013/14 ===
(legend for slides:)
* * = parsoid work
* ! = significant work in parsoid
* [component] = depends on component
====Core platform====
[Q1] 3rd parties can easily add integrations<br/>
[Q2] Stability - Squashing every bug we can, improving glitches <br/>
[Q2] Performance<br/>
[* Q2] Scalability
James: magic thing at the end: real time collaboration. need to sit down and figure this out, mostly form a product perspective. default for all articles? problem: e.g. edit conflicts when one users starts a big edit and the other makes small edits
[Q1] Hiddent content <br/>
[Q1] Rich text copy and paste<br/>
[Q1] no-wiki blocks<br/>
[Q1] better browser support (IE9)<br/>
[[MW] Q1] Content style hitting (redlinks showing as redlinks, stublinks as stublinks by CSS preferences and applied using the same HTML)<br/>
Gabriel: basically removed all this from Parsoid, so we could show all logged-in users same cached page<br/>
James: currently, our logged-in users put up with really slow (uncached) site anyway<br/>
[Q2] re-evaluate content munging<br/>
(e.g. template placing padlock in corner)<br/>
Roan: e.g. [[:en:Arsenal F.C.]] has a [[:en:Template:Football kit box|template for shirt colors]] ;), breaks in VE (done by Ed Sanders in a previous life)<br/>
Juliusz's suggestion about separating CSS from content
[Q2] Bailing to source mode: one-way switch from VE to wikitext editor without saving<br/>
closely related:<br/>
[Q3] Outline mode: lets you see structure of document<br/>
current system: lots of hacks<br/>
Trevor: get rid of [[w:Slug (typesetting)|slugs]] - content that is not in wikitext, only added for rendering (e.g. separation of two tables so cursor can be placed there)<br/>
images and other floated content - very unintuitive to interact with
(James:)<br/>
[Q3] Drag *& drop<br/>
[* Q4] Micro VE: edit summary and log entries, currently these take (a subset of) wikitext only<br/>
needs some work with Parsoid<br/>
Trevor: these are the only bits on the site that are written one time only (i.e. not editable). This means as long as the users are happy with tool, it could be written one-way (no two way)<br/>
Erik: also, currently editors parse wikitext with their brain ;) (in places where rendered version not shown)<br/>
Trevor: in 20 years, wikitext will still be in the back of some people's minds ;)<br/>
[! Q4] editor switching: switching between wikitext & VE mid-edit<br/>
challenging to do<br/>
[Unscheduled] Commenting : GSoC on document side-by-side commenting (annotation system, using OKFN's model...): help integrating<br/>
Erik: long-term, might need to build some way of quoting/referring article content into design<br/>
Trevor: so far, little to no communication between us and Flow team<br/>
Gabriel: Needs DOM attribute (uid) preservation in Parsoid, just as authorship maps
====New Editing Tools====
[Q1] Language settings<br/>
(GSoc)
[! Q2] Language variant tool<br/>
Gabriel: this is wikitext-based right now.<br/>
messy backend + UX problem, critical for Chinese and others
(James:)<br/>
[* Q2] Table of Contents<br/>
drag and drop <nowiki>__TOC__</nowiki>
[Q3] Layout HTML items<br/>
<nowiki><br /> <hr /> <div></nowiki><br/>
Erik: no br's might be a blocker for some wikis
(James:)<br/>
[Q4] Arbitrary user CSS <br/>
setting "color:red" and similar
[Unscheduled] [[:w:Definition list|Definition list]]s<br/>
relatively unused in content space with complex editing needs<br/>
Erik: colon-based annotation is common
====Extended Dialogs====
[* Q1] Nested templates<br/>
Trevor, Roan: more likely Q2<br/>
Gabriel: needs type information for parsing (-> TemplateData)<br/>
(James:)<br/>
[* Q1] Media settings: media item size (default), display type, alignment, alt text, link<br/>
will expose all kinds of preferences that users are currently not aware of (like image links), might create issues with inexperienced users if they start using them in unintended ways
[Q1] References: set local citation templates for auto-suggest<br/>
local communities could designate like 5 templates as presets
[[UW] Q2] Media upload: triggered by button, drag and drop or (maybe) copy-and-paste<br/>
use UploadWizard<br/>
Erik: this entire item could be outsourced to Multimedia team<br/>
James: mobile team did some work
[Q2] non-templates: parserfunctions, content magic words like <nowiki>{{CURRENTDAY}}</nowiki> etc.<br/>
make it easier to use those<br/>
[Q2] categories: hidden categories /inherited categories (from templates)<br/>
[[Wikidata] Q2] language links --> Wikidata
[* Q2] magic words: ex. #REDIRECT, NOTOC, NOCC<br/>
Erik: have we done some prioritization here? e.g. redirects frequently requested<br/>
James: not yet
Erik: do we have special character insertion? e.g. non-Latin, like toolbar in Vector<br/>
Trevor: not yet, but simple to do. might just port current Vector toolbar, it's well-curated
(James:)<br/>
[[MW] Q4] edit notices: setting/editing page-specific edit notices in-page<br/>
enwiki has system where admins can add editnotice (appears on top when page is edited)
[Unscheduled] media searching: filtering by media type (still/video/audio), length, etc.<br/>
currently gives thumbnail icons
====New Dialogs====
[* Q1] Galleries<br/>
Wikia (Inez) already working on it, this is vital for Commons<br/>
[Q1] Equations<br/>
widely asked for: click on LaTeX block, edit it<br/>
currently only edits as LaTeX<br/>
discussion on letting anyone edit content of tag extensions<br/>
for math, currently a GSOC project<br/>
timelines?<br/>
[Q1] Code: edit code in syntaxhighlight block<br/>
GSOC
[Q2] Tables: add/remove row/column, merge/split cells; set headers, sortable, caption, float<br/>
more difficult in terms of UX
[Q3] Table styling: setting colors on table row, column,cell
New and extended integrations
[Q1] Consistency: ensure all parts of integration are as expected (edit links in diffs)<br/>
[Q2] Flow (Q2): VE will be an editing experience in Flow<br/>
Erik: VE as sole editor for this might not be possible yet (since not all browsers supported by VE)<br/>
(James:)<br/>
[Q2] ProofReadPage: Necessary for deployment on Wikisource; unclear who owns it<br/>
[Q3] Mobile: Rich editing on mobile devices (tablets and phones)<br/>
[Q4] Visual Histories: Visual diffs, "playback" of history<br/>
might be nice for readers. Sue: agrees
(James:)
====Deployment and release====
[Q2] Stable MW integration release<br/>
- easy install by 3rd parties<br/>
maybe without Parsoid first (i.e. just for HTML only wikis). Parsoid might be too demanding for many 3rd parties<br/>
[Q2] Cover all content: all non-talk pages except MediaWiki: and Template: namespace<br/>
this is mostly just a config change<br/>
[* Q2] Deploy to all WMF content wikis: Wiktionary, Wikivoyage, Commons<br/>
big dependency on Parsoid. would like to do it this in 2013<br/>
would like to sit down with people from each of these projects to discuss issues<br/>
e.g. Wiktionary might be easy, Wikisource tricky<br/>
[[OAuth] * Q4] Deploy to all WMF wikis: requires Parsoid to auth for private wikis<br/>
plug into OAuth work that Platform team is doing now<br/>
[Unscheduled] A stand-alone version: for "keeping ourselves honest' and encouraging 3rd parties<br/>
Trevor: to be clear, we have been doing this all the time<br/>
[Unscheduled] a WordPress integration: for using VE in WordPress, initially as demo<br/>
Trevor: talked to ca. 4 people who work for WordPress outfits. Local installations often break parts of the VE with their own variants, most serious Wordpress users don't trust Wordpress' VE, ours could be very useful for them. We can't put much energy into it, but might kickstart it<br/>
Erik: Wordpress uses their own component?<br/>
Terry: they adapted TinyMCE, adding features by shortcodes<br/>
James: also, this would bring more eyeballs
--break--
== Questions and Discussion ==
http://ee-dashboard.wmflabs.org/graphs/enwiki_ve_hourly_perc_by_user_type :<br/>
(mainspace edits, excluding bots, but including bot-like tools like AWB)<br/>
about 9% (fluctuating) of edits by existing registered users<br/>
about 45% (trending upwards) among edits by new users<br/>
On Monday, switched on for anonymous users (but artefact: fading in gradually because of caching - a previously cached page does not yet include a VE edit link)<br/>
Trevor: could purge entire cache gradually (this has been done before)<br/>
Erik: need to start conversation about purging now, because it will occur for every language<br/>
Trevor: i.e. anons use it pretty exclusively<br/>
James: about 19% of views are with blacklisted browsers<br/>
Trevor: editors have different browser distribution than readers<br/>
James: disappointing that not used at higher rate among newly created accounts. should go up to 50-60% with all browsers supported, but still<br/>
caveat: "new" users could be experienced users from other wikis coming in via SUL<br/>
Sue: so currently ca. 87% of anon edits still use wikitext?<br/>
James, Erik: yes, but distorted by caching<br/>
Sue: and among existing registered users, massive majority use wikitext?<br/>
James: yes<br/>
Erik: this is % of edits, not users<br/>
http://ee-dashboard.wmflabs.org/graphs/enwiki_ve_daily_editors :<br/>
Trevor: anons look similar to our browser support ratio?<br/>
Roan etc: not quite<br/>
14000 wikitext vs. 200-300 VE<br/>
Howie: just calculated percentages<br/>
Erik etc: so actually not a huge discrepancy of percentages between edits and users<br/>
I.e. existing editors: about 1 in 5, new editors: 40-45%<br/>
Sue: so we think that the proportion using it currently is lower than we wanted?<br/>
James: yes, but partly due to caching issues, and need to win over power users<br/>
Sue: if we were done already, this would be disappointing. But we are not done yet.<br/>
Erik: also, confidence needs to build that VE does not mess up things<br/>
and: copy+paste is a big deal, not supported yet<br/>
Gabriel: performance issue, I did some tests on e.g. [[:en:San Francisco]]<br/>
Roan: browsers make a huge difference re performance, e.g. IE9 very slow<br/>
Trevor: we have a lot of performance work to do, for sure
reasons summary:
* browser support
* cache for anons
* power user support
* bot on user accounts
* performance (to intialize stuff in browser, or browser dealing with large documents)
Sue: any more material to cover? <br/>
James: no<br/>
Sue: Jimmy might cover VE in his Wikimania keynote. my general sense: we are getting less pushback than I personally expected<br/>
time has passed for a mere "help us test this" message<br/>
Trevor: what convinces community members is us reacting to their concerns and needs, incorporating feedback<br/>
Philippe: yes, we fixed ~200 bugs. also: this whole project has been a reactive one from the very beginning, taking up concerns/needs that were voiced in the community for a very long time<br/>
Sue: imagine all the awful things (breakages etc.) that *could* have happened, but didn't<br/>
do we have some illustrative examples of people whom VE empowered? of "wanted" editors, e.g. subject matter experts<br/>
Erik: we have some, ID'ed by community liasons. e.g. comments on feedback page<br/>
Erik: most contentious issue: made a conscious decision not to offer an "off" switch<br/>
James: other questions about further development?<br/>
Erik: I think you spoke to pretty much everything<br/>
Mobile and Flow integration will be important<br/>
Trevor, James: for that, need someone "embedded" in the mobile team<br/>
Erik: worked with Jon yet?<br/>
Trevor: yes, he's great<br/>
Erik: any general cross-team coordination yet?<br/>
No<br/>
Erik: we have Kenan now. development has been siloed, which was fine so far, but need to start coordination now. Howie, can you drive this? Howie: OK<br/>
Roan: VE on mobile *basically* already works, except issues like dialog boxes blocking screen (demoes it on his phone)<br/>
Erik: (I already discussed this with James a bit:) We need to think more about task efficiency.<br/>
important both in dialogue with editing community, and in product decisions<br/>
like "experienced user needs 7 seconds in VE for task x, 2 seconds in wikitext"<br/>
e.g. wikitext useful for large-scale changes (like search-replace in 200k of text, or lots of insertions of same template)<br/>
when talking to experienced users, point out that VE already tells them much that they need to look up when using wikitext (like template parameters)<br/>
lots of different user/tasks types (e.g. "I add redirects all the time")<br/>
Trevor: yes, VE shows a lot, but not all is discoverable<br/>
James: we do have a manual for VE<br/>
Erik: any blockers you want to flag?<br/>
James: could talk about hooks between...<br/>
Trevor: talked about this last quarter: contentEditable code is dependent on Wikia, creates a bit of a bus factor. I think we need a CE engineer in our team, with more of a computer science background, that works for our style of coding, especially the responsiveness of it<br/>
Roan: need a variety of skillsets for this<br/>
Erik: maybe some shared responsibility with other teams/tasks(?)<br/>
Trevor: if we are serious, might need 2 people for this. doesn't differ much between mobile and desktop<br/>
Erik: ok, let's think about the resourcing issue<br/>
Erik: volume of their input currently?<br/>
Trevor, James: low, they were pulled off right before our July launch<br/>
Erik: Anything else?<br/>
Sue: No. Thanks for VisualEditor ;)<br/>
Gabriel: And Parsoid ;)