VisualEditor/Backlog design

Decisions from planning meeting:
 * 1) Make the minimum number of changes to the VE Phabricator data necessary to produce:
 * 2) A stack-ranked backlog suitable for discussion and planning by most stakeholders
 * 3) A Product Burnup chart
 * 4) Don't (yet) try to do anything with orthogonal categorization of VE tasks (for example, don't try to tag all mobile tasks vs all desktop tasks, and/or all security vs all performance).  May come back to this later but not needed yet.
 * 5) Don't try to create a new project to contain a full stack-ranked list of all VE bugs (well, stack-ranked from 1-100).
 * 6) Reason 1: huge amount of Phab spam if we bulk-move 1300+ active and 3000+ closed tasks.
 * 7) Reason 2: Don't explicitly need it yet
 * 8) Do create tranches in order to organize the backlog.
 * 9) A tranche is an ordered set of all Stories and Epics (Tasks, in Phab) which the VE team intends to complete prior to all Stories and Epics in all lower-ranked tranches.
 * 10) For now, each tranche is intended to address a group of related issues.  (I.e., each tranche is effectively the top-priority tasks from a set of all tasks within a category, but the full list of all tasks in each category is not yet explicitly documented within Phab) The specific tranches planned are
 * 11) Fix anything that would block making VE available to more editors, or community acceptance thereof (empty for now)
 * 12) Demo of mobile version of VisualEditor
 * 13) Language-related improvements
 * 14) usability improvements to link inspector
 * 15) Tranches are implemented as columns within the VisualEditor project in Phabricator.
 * 16) As a tranche is completed, it is hidden but not deleted/emptied.
 * 17) VisualEditor shall always have an open Tranche 0, defined as "Interrupt", tasks which are urgent enough to jump ahead of all other planned work.
 * 18) Tranche 0 will also be stack-ranked.
 * 19) Tranche 0 will include (among other things) critical bugs for Wikitext, VisualEditor, and any other projects the VE team is responsible for.
 * 20) Logically, therefore, work on Tranches 1+ will only occur when Tranche 0 is empty or when the VE team is sufficiently staffed to have capacity available after engaging with all Tranche 0 tasks.
 * 21) All numbered tranches should be maintained fully stack-ranked
 * 22) TR0, and the next two active Tranches should be carefully ranked; other tranches may be loosely ranked.
 * 23) There is no intentional ranking for any tasks that are not in Tranches
 * 24) The existing VisualEditor columns (of the form "Next Up:"  in Phabricator) may serve as a card mapping area for items before they are assigned up to a tranche or down to the unordered lower backlog.
 * 25) This area may come and go.  Currently, we don't see a need for it in this SOP.
 * 26) The complete, stack-ranked list of VisualEditor tasks may therefore be derived from this algorithm:
 * 27) All open tasks in Tranche 0, in "natural order" as stored on the Phabricator board
 * 28) All open tasks in Tranche 1, in natural order
 * 29) All open tasks in Tranche 2, in natural order, etc.
 * 30) All open tasks in any "Next Up" columns, in no order (no order with columns and no order between columns)
 * 31) All open tasks in To Triage and in Backlog, in no order
 * 32) We will try to construct a Product burnup from a Phab data dump of this arrangement and refine the plan if that is not possible

= Open questions =
 * How far can an Epic go before it must be decomposed?
 * Option: No epics in TR0, TR1, TR2. <-- Decided
 * After an Epic is broken out, the Epic tag should be removed and it should become either closed (since it's wholly juiced out) or a Tracker (if it retains some integration work, which must still be <= 1 task worth of work)
 * TODO: rename this document to clarify that TR1 is really "Primary" (since TR1 itself will get closed out)
 * How is pre-coding work (requirements, design) accounted for?
 * Option A: Part of continuous "Backlog Grooming" that is assumed to take a fixed percentage of Product Owner's time as overhead. Not counted in points.
 * Option B: separate "Grooming" story for preparing one or more other stories to be shovel-ready
 * Option C: considered part of the lifecycle of a story, so that a story should be created as early as possible after basic scope definition, and the story assigned to appropriate people in sequence (such as designer, User Research, etc) and pointed appropriately. <-- Decided
 * Option D: Spikes, which are unpointed stories that are identified and prioritized, but not estimated or forecasted.
 * What are we doing with the Doing column?
 * move those tasks back into Tranches? (or treat that as tranche -1, and then stop using it after current tasks are done)
 * keep it? Then how does it relate to tranches?
 * What are we doing with the Done column?
 * stop using it after current tasks are done
 * How to generate estimates?
 * who does it?
 * which tasks need to be estimated?
 * are there homogeneous groups of tasks that can be assigned the average estimate from a subset?
 * How do we tie this explicitly to goals/OKRs?
 * Do we move OKRs into Phab?
 * How do we link Tasks to OKRs?
 * What is an activity period? A monthish?
 * How much of the backlog has to be well-ordered to have a realistic plan 4-6 months out?
 * can we do any ordering outside of the top hundred?
 * will we use the priority field for priority (and if so, how will it interact with the stack-ranking), or for severity, or for something else?