Talk:Wikimedia Engineering/2014-15 Goals/Q4

WMF Top priority proposals

Top priority deliverables can be proposed by anyone, and the 3 top priority deliverables will be decided upon by WMF's Executive Director (Lila), VP of Engineering (Damon), and VP of Product (Erik), based on input and feedback from product and engineering. As in the past, the ‘top priority’ process serves a few purposes:

To identify high-impact work, or work which requires high internal visibility
To clearly communicate our commitments as an organization internally and externally
To help ensure we have the right people and enough people working on the top priority deliverables to be successful
To help guide all of us in our day-to-day decision making and prioritization

Timeline

Top priority proposals due by COB 10 March, 2015 (anyone)
Discuss proposals 11 March, 2015 (Proposal owners, product and engineering management)
First draft top priority deliverables finalized 13 March, 2015 (Damon, Erik)

Guidelines

Top priorities identify clear, singular deliverables we are committed to (“Progressive rollout of VisualEditor as default editing environment on English Wikipedia”). They typically draw from multiple teams. We select for work that is strategically important to propel Wikimedia forward, but we will sometimes include a priority that is more operational/tactical if it requires a high level of internal dependencies and benefits from the internal and external visibility (the recent migration of our bug tracking / PM tooling is an example). We will aim for no more than three top priorities each quarter.

If you’d like to propose a top priority deliverable, please do so below by COB 10 March, 2015, and include the following:

Your name
The thing to be delivered
Success criteria which are specific, measurable, assignable, realistic, and achievable within the quarter
An explanation of why this is important: what problem it solves, who it serves, what value it provides, how it aligns with the WMF strategy/mission
Resourcing requirements and team dependencies

Proposals

Cross-wiki notifications

phab:T67661 Echo only notifies on the local wiki (comment 2 years ago: "no cross-wiki support in 1st release").

Success criteria: if my SUL account has Echo notifications on commons, then I see them in my Echo notification count and Special:Notifications on enwiki. The MVP proposed in Echo planning was: "'You have 6 new notifications on <Commons>' (the first cross-wiki notification we expect to implement)"

Why: Improves communication (even monolingual editors interact on home wikipedia, commons, Wikidata, and mediawiki.org), avoids per-wiki "silos", makes it easier for users to make additional contributions to less popular projects. .

Resourcing: ? engineers, a designer for cross-wiki interactions (show this wiki's/all wikis' notifications, mark this wiki's/all wiki notifications read, etc.)

Progressive Deployment System

Develop a System by which features can be pushed to a percentage of our user base

Why: Makes easy to gather data and evaluate feature without having to impact every single user. Any unexpected side effects of feature deployment are by definition small and quirks can be sorted out before reaching the user base at large.

In-line Wikidata description editing on the Wikipedia app

Proposer

Dan Garry, on behalf of the Mobile Apps Team

Statement of the problem

The Wikidata description in the app might help you find out what Bern is, but the long and complex first sentence doesn't help you at all.

As a user, I'd like to look something up on Wikipedia so I can find out what it is.

The above user story is central to Wikipedia's existence. People look things up on Wikipedia to find out what they are every day. But the long, complex prose in the first sentences of Wikipedia articles make it difficult to find out what something is at a glance. On the other hand, Wikidata descriptions are short, simple, and factual definitions of what something is, but they are not exposed to readers. To address the above problem, the Mobile Apps Team developed and shipped the lead image feature (see image to the right). But many articles still don't have Wikidata descriptions in English, a problem which is even worse when you consider languages that are not English.

In Q4, the Mobile Apps Team will pilot a feature which will let logged in app users seamlessly edit Wikidata descriptions in-line from articles. The process should be no more complex than tapping an edit pencil, entering some text into a text box, and tapping save. We could even use automatically generated descriptions (like those offered by Magnus Manske's AutoDesc API) to give the user a place to start. This will allow motivated power readers to contribute descriptions, without even having to realise they're interacting with Wikidata. This quick win will allow us to fill out Wikidata descriptions more completely, so that looking something up on Wikipedia to find out what it is is even better than before, and will lay the groundwork for further experiments in mobile-appropriate contributions in the app.

Deliverables

The feature the team will commit to getting into production by the end of Q4 is:

Wikidata descriptions will be editable by logged in users in production on the Wikipedia app for iOS and Android

Success criteria

The metrics that will determine success is:

The proportion of articles that do not have Wikidata descriptions will decrease
All successful edits to a Wikidata description in the Wikipedia app make it to Wikidata instantaneously
Wikidata description editing will have a higher number of people starting the workflow than wikitext editing on the Wikipedia app
Wikidata description editing will have a higher completion rate (from start to finish) than wikitext editing on the Wikipedia app

Resourcing requirements

The proposer of this project estimates that the following resources are the minimum required to achieve this goal:

2 FTE iOS engineers
2 FTE Android engineers
1 FTE user-experience designer
1 FTE product manager
0.5 FTE scrum master
0.5 FTE QA tester

Gather MVP

Proposer

Maryana Pinchuk and Jon Katz, on behalf of the Mobile Web Team

Overview

Improve quick look up reader experience and bring exploratory projects to stable states. The mobile web team is looking to shift this quarter from spending nearly all of its resources on exploratory projects to a balance between solving known user problems for established use cases (65%) and exploring new use cases and features (35%). However, our top priority in Q4 will be launching the Gather MVP. Following on the Q3 pilot, we expect that this will continue to be a way to share lists of articles that a user has curated:

Here are some details about the MVP:

Summary	"Checkout my list of the best philosophers"
Location	En Wikipedia/Production (Mobile Web)
Deliverables	Users can access Gather on En Wikipedia (Mobile Web), Users are given facilitated sharing options
Value	The value of this is to delight readers and reward creators at scale, and learn more about new levers we are pulling (new article views, social, identity, lightweight moderation, etc). The immediate success driver will be PV’s generated, but the fact that this is an entirely new product direction is where the ultimate value lies. “find-in-page” and other readership improvements have might lead to equal user delight, but have less strategic value.
Questions Answered	Do lists drive engagement? What are problems with non-NPOV, social, etc?
Success Criteria	At this stage, a yes/no on continue based on engagement is appropriate. Lowest Estimate (based on Book’s engagement): Expected Creators: >2,000 creators/month, Lists/creator: 1.1, PVs: >3,000, Shares: 200, Signups: >100 (based on shares and watchstar click->signup, not on sign ups to create book) High Estimates: (based on mobile web editing by editors with less than 10 edits): >20,000 creators/month, lists/creator: 2.5, Shares: 6,000, Signups: >1000 (based on shares and watchstar click->signup,, not on signups to mobile edit) Best Guess (based on above): >10,000 creators/month, Lists/creator: 1.5, PVs: >15,000, Shares: 1000, Signups: >500

Here is a very early stage draft of our overall quarter: Q4 MW Draft

Resourcing requirements

The proposer of this project estimates that the following resources are the minimum required to achieve this goal:

4 FTE engineers (at least 1 backend for mobile web)
1 FTE product managers
.25 FTE scrum master
.5 FTE designer
.5 Community Liaison
.5 FTE QA tester

Finish and deploy Gadgets 2.0 (aka global gadgets)

Proposer: Kunal (Legoktm), Alex (Krenair)

Why: The current Gadgets extension is outdated and doesn't scale to the needs of a wiki farm. However, it's still one of the most important tools used by Wikimedians for reading, editing, patrolling, and most other on-wiki tasks. The Gadgets 2.0 project is to modernize gadgets to allow them to use the full features provided by ResourceLoader (messages, dependencies, etc.).

Maintenance: We wouldn't have to copy the exact same javascript from wiki to wiki
Localization:
- Can properly localize gadgets through the normal MediaWiki procedures
- Proper server-side language fallback
Performance:
- Proper server-side message support through normal ResourceLoader features
- All non-ResourceLoader gadgets will be removed (some of the most requested pages in varnish)
- No having to make extra HTTP requests to load global gadgets
- Estimated savings for Commons, Wikidata and Meta would likely see similar stats
Timing: Much of the code has already been written (80-90%), it just needs to be cleaned up and prepared for deployment. The longer we wait, the more code needs to be re-written and updated to modern standards.
Support: Tons of community support for this feature, likely we can also involve community developers
From the MediaWiki Core team backlog
RL2 branch of Gadgets

Success criteria: The RL2 branch is merged into master and deployed to all Wikimedia sites.

Resourcing requirements:

2-3 FTE engineers
Consulting time with Krinkle and/or Roan
1 FTE product manager

OAuth and WDQ

Proposer: Erik Moeller

Release two critical new services/APIs that support rapid prototyping and community-driven innovation.
- OAuth exists, but has many bugs and user experience issue, and does not support non-web consumers.
- Wikidata Query Service is still in the prototyping stage, and will have to undergo rapid scaling and testing.
Concrete success criteria:
- Resolve all identified OAuth issues of high severity
- Support non-web OAuth consumers
- Launch production-grade Wikidata Query Service and use it in Wikipedia apps
This supports the potential creation of a new UX prototyping effort, continued experiments around micro-contributions (now or later), as well as existing community innovation and tooling efforts in Wikimedia Labs.
- While mobile apps function without OAuth, a secure OAuth login could provide a more integrated mobile web/apps login experience, and avoid having to enter passwords in the app.
- Web based prototyping that does not request user passwords depends on OAuth from the get-go.
- Whether or not we continue immediately on WikiGrok, Wikidata queries are necessary for many of the read/browse/discover/search experiences we wish to prototype and build.

Very different tech / different teams - may not make sense to group into one effort

Add topic