Wikimedia Engineering/2014-15 Goals/Q3

Q2 Wikimedia Engineering Top Priorities, FY2014-15, Q3 Q4


Strategic context for this quarter:

  • We are renewing our focus on VisualEditor as a core commitment we must deliver at a high level of quality, to make it easier for anyone to edit our projects. After two quarters of foundational work, many key blockers have been addressed and we are confident that we can make a successful push toward wider usage.
  • On the mobile web, we continue to focus on contributions beyond editing. While we have seen success and growth of mobile editors, we recognize that the mobile web is not simply a smaller version of the desktop, and offers new opportunities for casual participation. This quarter, we are calling out specifically the work on the mobile web, but the work in apps continues, consolidating and building on the readership focused features we launched last quarter.
  • We have long committed to being a data-driven organization. In order to make data a part of every product team's day-to-day decision-making, we need to ensure that key metrics are reliably collected (instrumentation). We will demonstrate this in the context of the VisualEditor release, to improve practices across the organization in the long term.

What we are consciously not yet calling out as a top priority:

  • The Wikidata Query Service. We are continuing work on this project, prototyping different technical solutions and specifically using the mobile web team's work and the existing WDQ-based tools to inform requirements. However, we recognize that we are still in the prototyping stage, and we're not yet staffed to make this a top priority for this quarter.
  • SOA Auth. The priorities of the services engineering team in particular will need to be fully aligned with shipping VisualEditor and mobile features, so we are reluctant to call out any specific service that may need to be de-prioritized.
  • Fundraising refactor / A/B testing. With the analytics team focused on instrumentation and fundraising-tech busy with post-fundraiser cleanup and payment processing related work, now is not the best time for a major cross-functional initiative to consolidate e.g. A/B testing functionality across teams.
  • Front-end standardization / UX standardization work. This will take a backseat to VisualEditor work this quarter (many of the same individuals are involved), and deliverables will be scoped accordingly.
Objective

Beneficiaries

Measures of success Project Lead Accountable executive Personnel and teams involved Status
Prepare for bringing VisualEditor to all new users on wikis where it is currently opt-in New Editor, Casual Editor
  • We will get VisualEditor by the end of Q3 to be ready to be on by default ("opt-out") on the English Wikipedia and other wikis in desktop mode, subject to community happiness, for "new users" – anonymous users and logged in users who have never edited; doing nothing to existing accounts with edits.
  • Stretch goal: We aim to run a trial for new and IP users getting VisualEditor on by default for a week or two to test the value before the end of Q3.

Prioritised functional and technical objectives:

  • Any identified major stability issues fixed – no regressions or data corruptions
  • Improved performance, especially in editor load
  • Existing features provided, plus in-flight UX and product changes:
  • Expanded unit, regression and content testing
  • Fit-for-purpose special character inserter; currently blocking ~50 languages which need it, like Navajo and Welsh
  • IME support for top 10 (etc.) IME users; currently blocking ~80 languages which use it, like Hindi and Japanese
Trevor Parscal Damon Sicore Full Editing team (including Engineering, Product, QA, Community Engagement and Design members), plus Ori Livneh & Tim Starling.

Existing dependencies on the Parsoid and Services teams.

Some likely minor dependencies on the Analytics and Platform teams.


Front-end standards and continuous integration workstreams will be supported on a much lower basis by Bartosz and Timo respectively

Overall: On track
  • Stability issues: On track
  • Performance: On track
  • Features: Delayed due to citoid service issues
  • Testing: On track
  • Language support: On track
Release and test two new reader-targeted contribution features on the mobile web: WikiGrok and Collections
  • Wikidata
  • Readers
  • Casual editors
  • WikiGrok:
    • Establish baseline (percentage & absolute numbers) at 100% enwiki for:
      • quality of responses (primary success metric)
      • engagement of users who land on a WikiGrok enabled article (secondary success metric).
      • retention: how many users come back to answer more
    • Measure against other quality and engagement metrics:
      • quality: compare WikiGrok response quality ratio to successful/reverted edits ratio from new users on mobile – are WikiGrok responses better, worse, or comparable?
      • engagement: compare WikiGrok engagement to reader-to-editor conversion on mobile – are we engaging a wider circle of readers with this more lightweight, mobile-friendly contribution?
      • retention: compare rates of returning WikiGrok users to mobile editor retention – are we engaging a wide pool shallowly, or can we get repeat WikiGrok users?
  • Collections:
    • Launch pilot of a new reader curation + sharing feature.
    • Begin collecting baseline usage statistics (creating, adding, consuming) and characterizing use cases
    • Decide on further development on this feature based on initial baseline stats on:
      • number of creators (as compared to mobile web editors and desktop page creators)
      • user class of creators (are we reaching outside the power editor group?)
      • list type and quality (qualitative assessment of the content created via this feature)
Maryana Pinchuk Erik Moeller The Mobile Web WikiGrok and Collections teams, including engineering, product, design/UX and support from Research and Analytics WikiGrok: on track – first reader test live

Collections: renamed "Gather", due to launch a pilot by the end of March; scale expected to be limited to qualitative analysis initially.

Fully instrument editing experiences across devices/platforms to support VisualEditor development
  • Editing Team
  • Product teams
  • Interested power editors

Collect and continually visualize key metrics including but not limited to:

  • initialization time and save time (perceived and actual)
  • edit funnel from start of an edit action to successful save
    • save rates, abort rates, error rates
    • across experiences: mobile, desktop, wikitext, VE.
  • Prioritization of metrics will be driven by VisualEditor success criteria.
  • Provide ad-hoc support as needed to VE team
Dan Andreescu Erik Moeller Analytics Engineering and Research,

Design U/X,

Ops

Just Beginning
Implement standardized product development methodology which includes community input across teams working on user-facing functionality
  • All users
  • Publicize integrated draft process which addresses all stages of a product's lifecycle and incorporates data-based decision-making and evaluation, qualitative research, and community input
  • Revise process based on feedback from Wikimedia communities (at least one well-publicized online meeting; outreach on lists and wikis).
Erik Moeller Erik Moeller Primarily: UX, Community Engagement, Product, Analytics In progress In progress

For discussion and context see the talk page.