Engineering teams can communicate their capacity for core vs new work

This goal is tracked in Phabricator as T122838. This wiki page is a prototype for performing work breakdown on this goal, experimenting with how best to mix Mediawiki and Phabricator.

The first three top-level headings were copied in from TPG Goals.

Documented and agreed upon definition of ‘core work’ (T122839)

 * 1) Acceptance Criteria
 * 2) All audience-facing product teams accept and understand how to use a shared definition of 'core work'
 * 3) Documentation includes guidelines for handling work that doesn't easily fit in this framework included. (e.g., "other" (non-core, non-strategic))
 * 4) Documentation includes answers for all previously raised questions/alternate definitions (e.g., "interrupt", etc)
 * 5) Expected work sequence
 * 6) Initial definition proposed
 * 7) Derived from Wes's outline combined with previous efforts (Measuring Types of Work ))
 * 8) via email?  Via in-person at allhands?  Via strategy process?  All three?
 * 9) Request for input made to all affected teams
 * 10) Refine and finalize definition
 * 11) Review previously raised questions/issues and make sure they are addressed

Agreed upon method for tracking data (T122841)

 * 1) Acceptance Criteria
 * 2) Method(s) for recording core/strategic/other in Phabricator and viewing it in reports are documented
 * 3) Tracking method(s) are accepted by all audience-facing product teams
 * 4) Tracking method(s) work(s) well for most common work definition patterns amongst teams, and accommodates uncommon patterns to some degree
 * 5) Expected work sequence
 * 6) Propose a method for tracking data, including both "total completed work" and "which tasks are core/strategic"
 * 7) Solicit input from all affected teams
 * 8) Refine and finalize method(s)
 * 9) Pilot tracking with at least one team
 * 10) Pilot reporting in phlogiston

Audience-facing product teams able to produce evidence-based data about the proportion of time spent on core vs. non-core work (T122842)
''Note that "able" is different from "willing", and even if they are able and willing, TPG can't force teams to actually deliver the data. This is relevant to setting acceptance criteria that are within TPG's control.''
 * 1) Acceptance Criteria
 * 2) At least one team has produced a report covering at least one week of completed work
 * 3) All teams have started tracking core work <-- Not part of TPG Q3 goal
 * 4) All teams produce report covering more than 50% of Q3 and more than 50% of total work <-- Not part of TPG Q3 goal
 * 5) Teams have qualitative and quantitative evidence of the quality of these metrics <-- Not part of TPG Q3 goal
 * 6) Teams have qualitative or quantitative evidence of the cost of these metrics <-- Not part of TPG Q3 goal
 * 7) Teams have performed a retrospective on the best practices for collecting this information <-- Not part of TPG Q3 goal
 * 8) Expected work sequence
 * 9) at least 1 team produces report following these rules
 * 10) Rollout to Embedded audience-facing product teams (Android, iOS, Discovery, VE, FR-Tech)
 * 11) Rollout to other audience-facing product teams are tracking core/strategic (Reading web, Community Tech, ???)
 * 12) All audience-facing product teams are producing reports <--- Not part of TPG Q3 goal
 * 13) 2-3 teams with 2+ months of track record makes recommendations for changes <-- Not part of TPG Q3 goal

Teams able to answer the question, "can you do X next quarter?"
This is out of Scope for FY16Q3, and is included for context of the broader vision of this work
 * 1) Teams have backlogs
 * 2) Backlogs are prioritized
 * 3) Backlogs are estimated/quantified
 * 4) New work is identified
 * 5) New work is estimated
 * 6) New work is prioritized relative to current backlogs