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:
 * 1) Your name
 * 2) The thing to be delivered
 * 3) Success criteria which are specific, measurable, assignable, realistic, and achievable within the quarter
 * 4) 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
 * 5) Resourcing requirements and team dependencies

Cross-wiki notifications
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 ' (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.