Analytics/Development Process

Purpose

 * This is a reference document to help you understand the processes followed by the Analytics Development Team.

Audience

 * Development Team
 * Stakeholders who need details

Getting in Touch
[mailto:analytics@lists.wikimedia.org analytics@lists.wikimedia.org] is the best way to initiate communications with the team.

This is a public list and is archived here

Work Breakdown Structure
For Example:

Epic: Editor Engagement Vital Signs Minimum Viable Product

Features:
 * CronUser runs report on entire project
 * User runs report for Newly Registered User
 * User runs report for New Editor
 * Analyst selects metrics to graph
 * Analyst selects projects to graph

Stakeholder Communications
Features are tracked in Phabricator. Each feature has points, sub-tasks associated to it.

Epics are prioritized and tracked on a wiki page.

Showcases are run every two weeks (at the end of a sprint) to demonstrate progress.

Production Issues

 * Production issues are always top priority
 * If you’re not sure if an issue is a production issue ask peers/managers/directors/VPs
 * We track these against a special Epic called Production Issues - Q(1-4)
 * We track them in a Epic so we can identify patterns, development metrics, etc.
 * Fix the problem first, create the card later

Bug Triage

 * Defects are logged in Bugzilla
 * Non urgent bugs will be dealt with as part of the regular backlog and story grooming process
 * Urgent bugs will be tagged as production issues and dealt with immediately

Quirks

 * We have many products and many stakeholders - most Agile perspectives assume a single product
 * Our releases correspond to quarters (They probably shouldn’t be called releases)
 * Team is completely distributed
 * Team does not work on same project at the same time
 * Managing infrastructure tasks in an agile way is challenging

Sprint Planning
TBC