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.
Objective
Key result
Dependency
ETA
Status
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
Parsing team
Services team
Community department
Team Practices Group
Communications department
June 2015
Done
Run a test for new accounts on the English Wikipedia, providing VisualEditor by default to measure the impact.
April 2015
June 2015
Done
[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.
Next quarter.
NDelayed
[Contingent on previous result.]
VisualEditor default availability on the English Wikipedia for anonymous users.
Migrate application servers to Ubuntu 14.04 Trusty, and assist with HHVM Done
Oct–Dec 2014
SSL with PFS Done
Varnish 4 in limited production Done
codfw fundraising infrastructure fully functional in time for the fundraiser Done
Jan–Mar 2015
IPsec on cross-data centre links for private data Done
Scale up HTTPS infrastructure to be able to serve HTTPS-by-default Done
Virtualization for miscellaneous servers at codfw Done
Ability to serve core site services (wikis) at codfw Done
Improve monitoring
New external monitoring for performance and uptime metrics from the user's perspective Done
Articulate a plan to replace current Icinga monitoring with something more scaleable and flexible (stretch goal) Done
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
Streamline deployment steps for SOA services
Reduce the number of individual manual service deployments steps from currently (typically) 11 to <= 5 using consolidation, increased abstraction and automation
Implement a configuration discovery system to aid fully automatic configuration of load balancing, Varnish caching and availability and metrics monitoring in one automated process
Evaluation of container systems and deployment system options Done
Services
Release Engineering
June 2015
Done
Interdependencies:
Assist other teams in Q3 on:
Deployments of RESTbase, Wikidata Query Service, HHVM image scalers, Hierator
Labs available in the new data centre (with Neutron/IPv6) NNot done
Distributing tools, deployment-prep to both data centers (availability/redundancy) NNot done
Jan–Mar 2015
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
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
Improve reliability of ToolLabs
ToolLabs has at least 99.5% provable, measured uptime for each individual 'service' that ToolLabs provides its users
June 2015
Done
Interdependencies:
Assist other teams in Q3 on:
Beta Labs improvements (RelEng)
Assist other teams in Q4 on:
Isolated CI instances (RelEng)
Dependencies:
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
Oct–Dec 2014
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
Jan–Mar 2015
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.
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
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.
Make Flow a discussion system that can handle all of the core Discussion use cases to a level that can be used on active project and article talk pages
One Wikipedia language using Flow on every talk page in the project and/or article talk namespace, enabled with the active support of the community on that language.
Community involvement to help prioritize, test and evaluate features required to earn enthusiastic support for Flow being enabled on an active namespace
June 2015
To do
Interdependencies:
Mobile web – Jon Robson joining the Flow team for Q1
Visual Editor and Multimedia for the Mini-VE and Media Uploader
See this page for additional details. Besides these high level goals, we will continue to focus on bug fixing, supporting existing Parsoid clients, improving performance, and regular deploys.
Quarter
Goals
Jul–Sep 2014
NPostponed Must: Likely spillover from 2013 goals: Basic language variant support
NPostponed Must: Stable element ids (supports content translation, WT/HTML switching in VE, other features)
RT testing, visual diffs, lots of fixes Must: Prepare to use Parsoid HTML for page view (finish up visual diffs, set up RT testing, a prototype for all page views)
Working with IneZ with Wikia Should: Native gallery impl
NPostponed Should/Could: Start experimentation with content widgets: Cross-team effort (Parsoid, VE, Services, Community Engagment, ...)
Oct–Dec 2014
Prepare to use Parsoid HTML for page view (beta for mobile?, all page views?)
Done Implement V2 Parsoid API for integration with RESTbase
Final reviews and work needed CSS based customization of Cite extension
Awaiting final review and deploy Support mixed content-style templates used heavily in some infoboxes
Supporting clients
Done Ongoing critical bug fixes
Partially done Explore performance issues with HTML parameters
Initial work done Must: Stable element ids (supports content translation, WT/HTML switching in VE, other features)
NPostponed Language variant support
Technical debt and maintenance
Done Migrate cluster to node 0.10
Done First pass migrating codebase to use Promises
Fixed some RT server endpoints to keep it usable Unclog RT server
MySQL db yet to be purged of old test results
NPostponed New applications
Jan–Mar 2015
Primary Focus: Supporting VE goals this quarter
Experiment improving efficiency of data-mw, data-parsoid encoding to reduce size of HTML.
Fix functionality and correctness bugs that affect VE
Additional work on implementing stable ids to enable HTML <--> wikitext switching in VE (Stretch goal)
Continue eliminating blockers and rendering issues that impact Parsoid-HTML read views
Site-specific customizations replicated in CSS in modern browsers w/ fallback for older browsers
Rendering of language variants
Initiate work to properly scope output of templates: easier to reason about, no WYSIWYG surprises in VE, supports incremental parsing (Stretch goal)
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).
Editing Team
June 2015
To be done
Interdependencies
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.
Quarter
Goals
Jul–Sep 2014
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
Load performance: No significant changes expected – 3s 50%ile, 5s 75%ile, 25s 99%ile (same as baseline)
Save performance: Major improvement is compressing save data before submitted for save – 3s 50%ile, 6s 75%ile, 15s 99%ile (from 4s 50%ile, 8s 75%ile, 15s 99%ile baseline)
Per-edit adoption: No significant changes expected – 35% IPs, 20% post-default users, 4% pre-default users (same as baseline)
Oct–Dec 2014
NNot yet completeCore: Initial improved support for IMEs, for key expanded if not all language groups
NNot yet completeFeature: Auto-filling citations from ISBN, DOI or URL
DoneFeature: Table editing – inserting new and deleting existing rows and columns, and common "advanced" tools like sortable columns & table header
Not yet complete; some improvements madeExperience: Clearer link editing tools based on design research
NNot yet completeExperience: Simplified citation system based on design research
DoneExperience: Improved media search based on design research
Jan–Mar 2015
In progressDeployment: Engaging with English Wikipedia to run a test enablement of VisualEditor for new users to measure impact, subject to community discussions
In progressCore: Initial improved support for IMEs, for key languages – e.g. ja, ko, ar, fa, Indic languages – if not all language groups
DoneFeature: Auto-filling citations from ISBN, DOI or URL
DoneExperience: Improved special character inserter based on design research
Not yet complete; some improvements madeExperience: Clearer link editing tools based on design research
DoneExperience: Simplified citation system based on design research
DoneExperience: Media editing tool redesign
Apr–Jun 2015
See overall Q4 priority.
Additional work areas:
NNot yet startedCore: Work to support partial document editing for performance
NNot yet startedCore: Work to support editing on mobile devices
NPostponedFeature: Editing templates’ field as rich content, not wikitext, including nested templates
NNot yet startedFeature: Auto-save local-only drafts if a browser crashes/disconnects mid-edit
DoneExperience: Clearer link editing tools based on design research
In progressExperience: Clearer citation editing tools based on design research
Interdependencies:
Auto-filling citations depends on the Outreach Program for Women work to do this led by the Services team (and partially mentored by the Editing team).
Uploading media functionality relies on work planned to be done in the Multimedia team.
Language variants support relies entirely on work planned to be done in the Parsoid team.
Continued key on-going dependencies on the Parsoid, Services, Platform Core MediaWiki and Mobile teams, and collaboration with the Core Features and Growth teams for their VisualEditor-related goals.
Likely delayed until FY 2015/16:
Deployment: Engaging with non-Wikipedias to consider issues for them like which key extensions and gadgets will need VisualEditor support
Feature: Uploading media – uploading an image/video/etc. to Commons mid-edit via a button in the toolbar, inserting into the edited page on completion
Feature: Rich gallery editing and creation support
Step towards allowing WikiGrok to execute queries against Wikidata and enable third parties to run own query service:
Publicly downloadable prototype (query and import and update)
Labs install (details hazy)
Hardware requested
12 month roadmap
Multi datacenter MediaWiki
Remove obvious implementation problems for running a MediaWiki farm across multiple geographically dispersed data centers in an active write-active read configuration.
Interdependencies:
SPDY – TechOps
SOA Auth – Services
API discoverability improvements – ECT
Q1 HHVM targets, expressed as wall time for PHP methods in milliseconds
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.
Quarter
Goals
Jul–Sep 2014
Previous content (now outdated) available in this revision.
Oct–Dec 2014
Previous content (now outdated) available in this revision.
Jan–Mar 2015
Objective
Beneficiaries
Measures of success
Project Lead
Accountable executive
Personnel and teams involved
Status
Release and test two new reader-targeted contribution features on the mobile web: WikiGrok and Collections
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)
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.
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
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)
Team Practices
Design
User Research
Analytics
Community Liaison
Communications
end of June 2015
Pending
>1000 shares per month rate
(subject to correction based on beta results)
end of June 2015
Pending
Interdependencies:
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.
Build and evaluate the success of a prototype which supports quick lookup and browsing by making taps on Wikipedia links show article information. more info
Link taps per user per session will increase.
Link taps followed through to destination per user per session will not decrease.
End of June 2015
NLink taps per user/session increased but link taps followed decreased. We do not feel this is a suitable metric in retrospect.
Build and evaluate the success of a prototype which supports quick lookup and browsing by making taps on Wikipedia links show article information. more info
Link taps per user per session will increase.
Link taps followed through to destination per user per session will not decrease.
End of June 2015
NLink taps per user/session increased, but link taps followed decreased. We do not feel this is a suitable metric in retrospect.
We build the anonymous path of discovery to a trusted and relevant source of knowledge.
Our focus will be on building on-top of our anonymous and trusted search stack to improve relevancy, expose additional content and leverage locally relevant knowledge.
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.
Goalsetting process owner: (Previously Jared Zimmerman) Mun May Tee (UI Standardization, Living Style Guide)
Quarter
Goals
Jul–Sep 2014
Done — Define goals and requirements for State of the User Reports (REFLEX) with Product and Analytics
Done — Consistency audit of released projects alignment with Living Style Guide
Oct–Dec 2014
NPostponed —Hire Sr. Designer with technical focus for partner projects and other feature areas (Moved from Q1)
NNot yet complete — Initial version of Living Style Guide with basic controls, palette, typography, iconography, behaviour, and best practices for desktop and mobile posted (Started in Q1)
NNot yet complete — Full coverage of iconography in core and foundation default extensions with mediawiki.ui icon set (Started in Q1)
NPostponed — Release Hovercards Beta Feature to selected small language wikis based on community requests (Postponed due to SendBeacon testing)
Jan–Mar 2015
Done — UI Standardization : Full coverage of iconography in core and foundation default extensions with mediawiki.ui icon set (Started in Q1), dependant on hire of Visual Design Fellow
NPostponed — Hire Sr. Designer with technical focus for partner projects and other feature areas (Moved from Q3)
In progress — Release Hovercards Beta Feature to selected small language wikis based on community requests
NNot yet complete — UI Standardization : Extend mediawiki theme and Living Style Guide to include all components used by current foundation projects
NNot yet complete — UI Standardization : OOJS controls for all in-use (core) controls completed
NPostponed — UI Standardization : Replace 50% of core form controls with OOJS template methods
NPostponed — Finch Extension with limited data gathering running in production (js support level, screen & browser size)
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
Standard toolkit of components, behaviors, language and tone in products and services
Extend mediawiki theme and Living Style Guide to include all components used by current foundation projects
Community Engagement
June 2015
In progress
Engineering Community
Product management support for prioritizing UI and behavior consistency in story prioritization
Wikidata/WMDE support for certain mediawiki.ui components
Replace 50% of core form controls with OOJS template methods
Done — Define goals and requirements for State of the User Reports (REFLEX) with Product and Analytics
NPostponed — Finalize plan for Research Internship Program
Done Define and prototype tools for qualitative research and data gathering.
Oct–Dec 2014
NPostponed — Hire Sr. Design Researcher to extend research coverage
Done — Hire Research Recruiter to extend team's ability to do recurring qualitative evaluative research
NPostponed — Make decision on software for State of the User (REFLEX), work with platform, and ops to get initial small scale test environment running
Done — Begin infrastructure planning for test environment
Jan–Mar 2015
Done — Begin infrastructure planning for test environment
In progress — Collaboratively create a set of pragmatic personae to start with and build those over time as we gather data for validation
Done — Grow the database of opted in research participants to over 1,000
Done — Reader behavior design research - ethnography and several other iterative research studies to learn more about reader behavior
Done — Support the Editing team in determining MVP for Visual Editor and providing needed evaluative and generative research to support this quarter's goals
Done — Support the Flow team with needed evaluative and generative research to support this quarter's goals
In progress — Make decision on software for State of the User (REFLEX), work with platform, and ops to get initial small scale test environment running
NPostponed — Publish State of the User Report (REFLEX)' in conjunction with Product and Analytics
NPostponed — Finalize plan for Research Internship Program
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
Evaluate the usability and user experience of editing tasks for VE launch.
This will also be a start to REFLEX : user segment based tasks to evaluate effects of changes to products and services on users over time.
Run 100 readers through reader task set
OPS/Labs team for REFLEX hosting
June 2015
In progress
Run 25 editors through editor task set
Product and Analytics support for State of the User Report
The team's focus is on modularizing our technical infrastructure and enabling other teams by developing internal services and a high-performance external REST API.
Quarter
Goals
Jul–Sep 2014
Implement first iteration of REST API front-end (restface)
Alpha deploy to api.wikimedia.org
Simple proof of concept implementation of page metadata end point for Parsoid HTML views (redlinks etc)
PDF render service deployment
First iteration on Rashomon storage service (with versioned blob and queue buckets & 'lame' auth)
Deploy & start using it with Parsoid
Wrap HTML load/save in restface
Citation service
Mathoid deploy
HTML templating: documentation, in particular KnockOff compiler & PHP implementation
Iterate once we have feedback from users & think more about use for content & messages
Teams immediately benefiting: Growth, Mobile, VE, Multimedia
Stretch Goals
Add the following metrics to the dashboards (broken down by 882 projects and target site):
Page Views
Unique Visitors (depends on introducing client side tokens, reviewing the privacy implications and ensuring un-sampled data in Hadoop can be relied upon for counting uniques)
Oct–Dec 2014
Fill out Vital Signs
PageViews & PageViews broken down by target site
Implement Breakdowns for existing metrics
Investigate Open Source BI tool
Grantmaking
User can expand uploaded cohorts to include users across all wikis
User can delete a member of a cohort
User can tag a cohort with pre-defined tags
User can list cohorts from an existing tag
EventLogging
Identify and direct the purging of raw logs older than 90 days (executed by ops)
Identify and direct the purging of rows older than 90 days (executed by sean and ops with input from product)
Work with product teams who need to keep some data longer than 90 days to comply with the privacy policy
Goals are dependent on Tech Ops work on EventLogging and standing up a data warehouse
Jan–Mar 2015
For the Editing Team, 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
Develop a prototype report and visualization on Unique Clients per project per day and month.
Goal is dependent on community engagement, engineering design and Mediawiki work.
Apr–Jun 2015
Objective
Key result
Dependency
ETA
Status
Provide metrics, a dashboard and ad-hoc support for Editing Team
The dashboard for Editing is used over time (measured in Pageviews for the dashboard)
Editing Team
End of Q4
In progress
Interdependencies:
Technical Operations: we work closely with operations, particularly on the Hadoop buildout
Research and Data: we depend on this team to provide definitions for metrics we need to collect and graph
Foundation: we need input from our many stakeholders to ensure we are producing the correct data and research
Design: we need design to help us build useful interfaces to our data
Facilitate the achievement of 80% of the goals by teams receiving dedicated resourcing and/or undergoing multi-day workshops with the Team Practices Group
Establish a mechanism to transparently and iteratively measure engineering team health
Ongoing work across all quarters: support teams in process/practice improvements, driven by health-check survey results. See also the Complete list of work for the Team Practices Group.
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.
Quarter
Goals
Jul–Sep 2014
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
Jan–Mar 2015
Hire an additional TPG resource to work with the MediaWiki Core team Done
Goalsetting process owner: Tilman Bayer / Erik Moeller
Quarter
Goals
Apr–Jun 2015
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
The Growth team was merged into the Mobile Web and Collaboration teams, respectively, in fall 2014. The growth team goals for the current fiscal year are obsolete.
Anonymous editor signup invitations and basic signup workflow improvements released on desktop version of all top 10 Wikipedias or more. Stretch goal: collaboration with Mobile Web and Apps teams on mobile versions.
Oct–Dec 2014
Personalized task suggestions and notifications for new editors released as default on Wikipedias where onboarding (GettingStarted and GuidedTour) is present. Stretch goal: task suggestions and notification aimed at very active editors (100+ edits/month).
Jan–Mar 2015
Product roadmap for Q3 and Q4 to be determined based on mid-year targets data.
Apr–Jun 2015
End of year targets: by June 2015, we aim to have gained at least one of the following...
Acquisition: we will increase (compared to a control) new registrations across Wikimedia projects by 23%.
Activation: we will increase (compared to a control) the rate at which new registrations become active editors (5+ content edits/month) by 23%.
Retention: we will increase (compared to a control) the survival rate of active editors on Wikimedia projects by 87%.
Individually, any of these conversion rate increases will lead to a full reversal of the year-over-year decline in total active editors. If all three targets are addressed, only a 7.6% increase in acquisition and activation are required, along with a 29% increase in retention.
Research & Data and User Experience: Both of these teams are core dependencies for Growth. Currently, the Research and Data embeds a full-time research scientist (Aaron Halfaker), and in order to support continued A/B testing capacity this will continue to be a key need on the team. Additionally, User Experience embeds a primary and secondary design on the team (currently Moiz Syed and Kaity Hammerstein).
Analytics: First and foremost, Growth depends on Analytics development for continued support of EventLogging, Wikimetrics, and analytics slave databases. In addition, Growth plans to use planned data products built by Analytics, such as an interest graph, to better attract new editors.
Community Engagement (Product): The Community Engagement group did not provide support for Growth during the 2013–14 fiscal year. We think providing some form of dedicated community liason will be critical if the team is to tackle more contentious areas of the user experience, such as article creation. Currently Product (Steven Walling) is filling this role on an as-needed basis, which puts the team primarily in a reactive mode, rather than having a proactive outreach plan.
Team Practices Group: The Growth team is small but is relatively inexperienced with Agile practices, and the new team practices group could provide extremely valuable support. Growth has implemented some Scrum practices, but its capacity for process improvement is limited since the team has never had a dedicated scrum master.
Mobile Web: There is close alignment this coming year with the goals of the Mobile Web team and Growth. Mobile wants to spread its knowledge about mobile-first product development and engineering, while Growth wants to help develop mobile versions of its products.
Mobile Apps: As we introduce login, editing, and other contributory workflows to our native apps, Growth should work closely with the Apps team to make sure there is consistent experience, discover ways to integrate its findings in to the apps, and consider methods for attracting apps users to desktop products.
Done
Delayed
