Team Practices Group/Improving burndown charts

Introduction
This page is a work in progress, reflecting current thinking. It is not authoritative in any way.

Terminology

 * Burndown Chart
 * https://en.wikipedia.org/wiki/Burn_down_chart
 * Burnup Chart
 * http://brodzinski.com/2012/10/burn-up-better-burn-down.html
 * Sprint Burnup Chart
 * A burnup chart whose scope is limited to a single sprint
 * Product Burnup Chart (or Release Burnup Chart)
 * A burnup chart whose scope spans multiple sprints
 * Phragile
 * A tool that generates graphs of data pulled from phabricator's API
 * Phabricator
 * The issue-tracking system used by the WMF
 * Phabricator Sprint Extension
 * Adds "Sprint" type projects, which add a "Story Points" field to any task in that project
 * Written by the WMF (?)

Assumptions

 * Burnup charts will be accepted by management (in lieu of Burndown charts)
 * Product/Release charts are the focus of this initiative (as opposed to Sprint charts)
 * Forward-looking prediction is the focus of this initiative (as opposed to retrospective)
 * An external chart generation tool is acceptable (it doesn't have to be built into phab)
 * At least for now, exporting raw data, and generating fancy charts in a spreadsheet would be acceptable
 * We have some budget to spend on upstream Phabricator coding, as needed
 * We have the ability to configure our phab instance however we wish
 * We have limited human hours available for phab coding
 * Any phab coding we do should be in the form of patches pushed upstream

Current State

 * Phabricator's built-in burndown charts:
 * Work OK within a single Sprint, but require a ton of work to span multiple sprints
 * Are Burndown charts, not burnup charts
 * Handle weekends in ways that some people dislike, but that's really a Sprint chart issue more than a Release chart issue
 * Phragile:
 * Is being developed by wmde
 * Provides ??? charts (I haven't seen examples yet)
 * Is an external tool, which would be acceptable
 * Would need to interface with phab authentication/authorization system?
 * To be able to handle security issues, yes, but for normal projects, is this true?
 * Currently provides BOTH graph generation AND sprint creation
 * Should these be separated?
 * Robla's "wbstatus" script:
 * Is written in python
 * Scrapes phab html to generate a state model of issues on a workboard
 * Could be used as a template to create a similar tool for burnup purposes
 * Example output: https://mw-core-wbstatus.wmflabs.org/?r=2015-03-16_to_2015-03-20
 * Source code: https://github.com/robla/phab-wbstatus