Purpose of this document: Goals for the Wikimedia Engineering and Product Development department, fiscal year 2014–15 (July 1, 2014 – June 30, 2015). The goalsetting process owner in each section is the person responsible for coordinating completion of the section, in partnership with the team and relevant stakeholders.
These goals will be iterated on a quarterly basis. Each quarter, the top priorities for the department as a whole will be elucidated and highlighted.
Context: Our top objective for the April-June quarter is to progressively release VisualEditor on the English Wikipedia. This is a major software release with significant risks, and consistent with its importance and expected long term impact, we are declaring this as the only top priority for the quarter. Everyone in the engineering/product organization will be called upon to support it as needed.
Improve the editing experience for new and anonymous users on the English Wikipedia by giving them VisualEditor
Maintain VisualEditor production service at our quality criteria:
No loss/corruption of existing article data
No loss/corruption of the user's contribution
No security issues
No regression in performance
No regression in usability
Data Research team
User Research team
Analytics Engineering team
Team Practices Group
Run a test for new accounts on the English Wikipedia, providing VisualEditor by default to measure the impact.
[Contingent on previous result.]
Gradual ramp-up of VisualEditor availability on the English Wikipedia for new users, starting from 5% increasing to 100%.
Timing to follow from previous result.
[Contingent on previous result.]
VisualEditor default availability on the English Wikipedia for anonymous users.
Labs available in the new data centre (with Neutron/IPv6) NNot done
Distributing tools, deployment-prep to both data centers (availability/redundancy) NNot done
Horizon dashboard proof-of-concept available, as a future replacement of OpenStack Manager Done
Storage capacity & redundancy expansion Done
Replace our internal DNS (PowerDNS) code with Designate Done
Improve reliability of ToolLabs
ToolLabs has at least 99.5% provable, measured uptime for each individual 'service' that ToolLabs provides its users
Assist other teams in Q3 on:
Beta Labs improvements (RelEng)
Assist other teams in Q4 on:
Isolated CI instances (RelEng)
Improvements to the Labs management web interface (MediaWiki OpenStack manager or possibly Horizon) will need involvement from the UX group, and potentially development assistent from a (MediaWiki?) development team.
Upload Wizard - Features - progress bar, drag and drop, better FAQ, replace infographic
Structured Data - planning with Wikidata, new metadata structure, design file page/editing tools, community discussions
Critical bug fixes - Examples: Image scalers, Core media handling, Media Viewer, TimedMediaHandler load on every page
Multimedia Metrics - upload funnel analysis, drop-off rate, UI clicks, # uploads, # uploaders, other upload tools, files used
Upload Wizard - Platform - fix more bugs, separate interface code, metadata-related infrastructure
Upload Wizard - Features - better licensing & category tools, add metadata anytime during load
Structured Data - implement structured data on Commons with Wikidata and community
Critical bug fixes - Examples: Image scalers, Core media handling, Media Viewer, TimedMediaHandler upgrade
Upload Wizard - refactoring and unit testing (and possibly stability and UX improvements enabled by that). Bugs encountered while undertaking this effort will be fixed, but might not be as high-profile as the ones we'll handle once we have JS error visibility. Tracking funnel metrics over time instead of only having a rolling snapshot.
JS error logging - getting it working on beta and on a small set of pages (including the Upload Wizard page) on production. The goal for the team is to get visibility on which main errors/bugs are responsible for the Upload Wizard funnel drops.
Platform - investigating a better solution for thumbnail storage.
Make uploading media an easy, integrated process
Users can upload media to Commons by clicking upload or using drag-and-drop inside VisualEditor and the wikitext editor whilst they edit.
This quarter, the team is focusing on the feature requests coming from communities that have enabled or are planning to enable Flow on their wikis. This includes French WP, Catalan WP, Portuguese WP and Translatewiki, with more language partners coming up.
Identify and fix the most prominent remaining semantic roundtripping diffs
At least 99.95% of the 160K test pages roundtrip (wikitext -> HTML -> wikitext) without semantic errors in full roundtrip testing (which translates to significantly higher accuracy using the selective serializer in production).
To be done
Rashomon / Content API is needed for html page views, stable element ids, efficient template updates.
VE, Flow, Mobile depend on Parsoid output
i18n consultation for language variant support
Content translation group on stable ids
Collaboration / interaction with editors community for wikilint/linttrap
TheVisualEditorTeam is working to make VisualEditor a great editor for new and experienced editors alike, focusing on improving the performance and usability whilst adding some more features to make VisualEditor more helpful, intuitive and practical for use for every content edit, alongside maintaining, improving, and extending the existing editor software. Below are a set of goals that we hope to achieve over the next financial year (July 2014 – June 2015), with a balance of optimistic and pessimistic assumptions about speed of delivery; not all goals may be achieved in the time period indicated, and some may be updated over time.
On-going work happening every quarter:
Stability and bug fixing, prioritising any bugs that cause wikitext corruption or any other form of disruption for our wikis’ communities (including in the wikitext editor);
Performance improvements for users, tracking load & save times, execution speed;
UX improvements tracked regularly and reported in a quarterly public user testing narrative;
Ensuring the success of VisualEditor on mobile, with a target of feature equivalence on tablet and at least some features on phone, with responsibility for both VisualEditor and wikitext editing pipelines on tablets and phones as well as desktop transitioning from Mobile to the team; and
Collaborating with volunteers and other Engineering teams like Parsoid, Services, Platform, & Core on related efforts like skin improvements, front-end performance, and other areas.
NPostponedDeployment: Engaging with English Wikipedia to discover pain points as part of agreeing the criteria for a gradual ramp-up of VisualEditor availability and usage to default, expected to happen in Q2, subject to community discussions (after this point, ongoing support)
DoneCore: Internet Explorer 10+ browser support
Service deployed in production but client not createdFeature: Auto-filling citations from ISBN, DOI or URL
NPostponedFeature: Editing templates’ parameters as rich content, not wikitext, with helper tools for some types like image (searching Commons), link (searching wikis), date (date selector extended from Wikidata’s), and possibly others
This fiscal year, the Mobile Apps team will be focused on getting data on feature usage of the new native mobile applications for iOS and Android in order to set goals and prioritize work on new apps features.
The Mobile Web team will split their time between two main focus areas:
Technical enablement – ensuring that other teams can work with MobileFrontend code, standardizing UI and code across desktop and mobile, and helping other teams design and build features that are responsive and work cross-platform.
Product work – this encompasses both a) porting select desktop experiences to tablets and handsets; and b) creating new features and contribution streams that help raise the number of new mobile users who hit the active editor threshold (5+ edits per month; below, referred to as new mobile active editors), so that we not only acquire but retain a healthy new editor population via mobile apps and web.
Our quantitative targets are based on the Growth team's editor model and focus on acquisition (getting more users to register for accounts via mobile), activation (getting more newly registered users to make 5+ edits in their first month), and retention (retaining new mobile active editors for 2+ months post registration). Note: targets for acquisition may change based on ongoing data collection around total edit numbers on tablets; if we observe a sustained drop in total contributions post tablet redirect, we may prioritize work on anonymous editing on mobile, which may change the number of signups on mobile.
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.
Allow users to create individualized collections of articles and share them with others by launching Gather on English Wikipedia, Mobile web
>10,000 creators/month rate
(subject to correction based on beta results)
end of June 2015
>1000 shares per month rate
(subject to correction based on beta results)
end of June 2015
Editing team: We'll be working with the Editing team throughout the year to create a standardized editing experience (both wikitext and VisualEditor) across devices.
Flow: A MobileFrontend engineer with be embedded with the Flow team throughout Q1 to help build a mobile-first Flow experience.
Research & Data and User experience: We will be doing more in-person qualitative testing of new and existing mobile features to ensure good usability and a high-quality user experience. We will also run controlled tests and gather quantitative data on features to determine their effects on new and active editor numbers.
Analytics: We will need help from Analytics to continue monitoring and analyzing pageview traffic to determine the flow of readership to the desktop and mobile sites of all our projects.
Growth: Some of the mobile-specific contribution experiments planned for this year may dovetail with Growth experiments. Because we will be focusing on the same set of metrics/targets, the Growth and Mobile team should be working closely and sharing product thinking, experimental setup and overall strategy.
The Maps & Geo team will be a new team at the Wikimedia Foundation tasked with scaling our existing mapping resources to enable the world to visualize Wikipedia all around them. They will start the year forming the team, inventorying existing work, and scale our tile services and osm db to be production ready. Next they'll work with the Mobile Web and App team to empower our users to use mapping resources.
The success of this team will be determined by the success of the teams that leverage TPG's services. A guiding belief of TPG is that healthy teams build better products. It is the TPG's assumption that by supporting WMF engineering teams in becoming healthier and more sustainable, WMF engineering will be more successful as a whole. In addition to qualitative feedback, we can measure the TPG's impact by the success achieved by the individual teams engaged with the TPG - as measured by those teams meeting, or coming close to meeting, their goals. Further, the TPG can begin to validate its assumptions about team health impacting sustainability and product quality by first establishing a mechanism to measure and evaluate engineering team health.
Hire 1 scrummaster to work with the Mobile Web and Mobile Apps teams Done
Iterate on and deliver updated health-check survey to Mobile Web, Mobile Apps, Mediawiki Core, Analytics Engineering, and Analytics Research, Fundraising, Release Engineering, Core Features, Language Done
Conduct a structured team practices workshop with the Mediawiki Core team Done
Hire an additional TPG resource to work with the MediaWiki Core team Done
Note: This team was dissolved at the end of April, with its members and tasks being absorbed into other teams. With this qualification for the objective, we will still make an assessment at the end of the quarter on whether it was a success or miss.
Significantly contribute to the Editing team's work in avoiding or fixing problems in VisualEditor, and support communications by e.g. the Community Engagement and Communications teams regarding VisualEditor, including:
Run weekly tally of VE edits, e.g. to provide insight into how the frequency of problematic edits develops
Provide quantitative community analytics on VE users as needed
Provide qualitative analysis of VE usage, characterizing usage by 20 or more accounts, e.g. to support communications about VE