Wikimedia Engineering/2014-15 Goals/Q3

Early notes for consideration in December.

We distinguish between:


 * Above waterline - top 5 priorities
 * Below waterline - high priority projects/needs, close competitors for top spots
 * Below lava line - not a contender for a top priority

Right now we're not in the sorting stage yet, but we can collect some candidates already identified in the Q2 planning. As we get closer to Q3, we'll collect input from various team leads, the architecture team, and other stakeholders.


 * Strong candidate: Editing performance cont'd from Q2, as anticipated, unless the project is just not working.
 * Why: We're only kicking this off in November, so need some time to dig in.
 * Strong candidate: Mobile web/apps again, unless we're so disappointed with what we're achieving in Q2 that we need time to re-group.
 * Why: Biggest organic growth & green field opportunity.
 * Strong candidate: Improved test/QA/CI infrastructure. Make deployments less painful and improve our QA.
 * Why: Must-have to improve product quality.
 * Strong candidate: A/B and multivariate testing infrastructure. Create better foundations for testing, comparing and validating user experience changes.
 * Why: Must-have to increase product development velocity (though should be driven by concrete product needs for Q3).
 * Strong candidate: Fundraising tech refactor. Make fr-tech less of an island internally and ensure the team can add and rotate team members.
 * Why: Fr-tech needs to staff up to support new integrations (e.g. mobile), and to support that, and create more team sustainability, this has long been identified as a must-have.
 * Candidate: Phabricator for code review, phase out Gerrit.
 * Why maybe not: This may be premature as we'll still be in the early days of using Phabricator as a PM tool, and may not yet fully understand the requirements. It may also contend for resources with critical test infrastructure work.
 * Candidate: Front-end standardization / UX standardization cont'd as a top priority.
 * Why maybe not: We're now establishing a lot of technical foundations and working parameters for the team; we may not need to continue it as a top priority to keep the momentum going.
 * Candidate: Library infrastructure work cont'd.
 * Why: So it doesn't immediately fall by the wayside after making some initial efforts.

General thoughts

 * Are some of these still too specific, too project-focused? E.g. could fr-tech refactor and library infrastructure work be collapsed into cross-organizational efforts to reduce technical debt, to break up monolithic code, to increase test coverage, etc.?--Erik Moeller (WMF) (talk) 08:02, 17 October 2014 (UTC)