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) VisualEditor shall always have an open Tranche 0, defined as "Interrupt", tasks which are urgent enough to jump ahead of all other planned work.
 * 17) Tranche 0 will also be stack-ranked.
 * 18) Tranche 0 will include (among other things) critical bugs for Wikitext, VisualEditor, and any other projects the VE team is responsible for.
 * 19) 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.
 * 20) All numbered tranches should be maintained fully stack-ranked
 * 21) TR0, and the next two active Tranches should be carefully ranked; other tranches may be loosely ranked.
 * 22) As a tranche is completed, it is hidden but not deleted/emptied. So Tranche 1 will disappear soon, and eventually "Tranche 20" will be the new "Tranche 1".  To be clearer, we will use "Interrupt Tranche" for Tranche 0, "Primary Tranche" for the next open Tranche, "Secondary Tranche" the one after that, etc.
 * 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.
 * 30) Etc through all numbered tranches.
 * 31) Note that technically, Tranche 1 is still more important than Tranche 20 even when tranches 1-19 are all Done and closed and hidden.  This seems purely theoretical but may matter for reporting.
 * 32) All open tasks in any "Next Up" columns, in no order (no order with columns and no order between columns)
 * 33) All open tasks in To Triage and in Backlog, in no order
 * 34) 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 =
 * 1) How far can an Epic go before it must be decomposed?
 * 2) * Option: No epics in TR0, Primary Tranche, Secondary Tranche. <-- Decided
 * 3) * 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)
 * 4) What's the definition of an Epic for VE?
 * 5) * Will take one member of VE staff more than a few days of solid work. In practice, over 8 points.  Decided.
 * 6) How is pre-coding work (requirements, design) accounted for?
 * 7) * 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.
 * 8) * Option B: separate "Grooming" story for preparing one or more other stories to be shovel-ready. Pointed and forecast.
 * 9) * 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 and forecast appropriately. <-- Decided
 * 10) ** Some of option A is inevitable; e.g., bulk work to prioritize or define 50 tasks in one 30-minute sitting is not pointed or tracked.
 * 11) ** If anyone non-Product Person (James or Neil) is spending time grooming or working on a Task (good rubric: is it assigned to them?), it should be a Task or part of another Task, be pointed, and be estimated.
 * 12) * Option D: Spikes, which are unpointed stories that are identified and prioritized, but not estimated or forecasted.
 * 13) What are we doing with the Doing column?
 * 14) * keep it? Then how does it relate to tranches?
 * 15) * move those tasks back into Tranches?
 * 16) * Treat that as tranche -1, and then stop using it after current tasks are done <-- Decided
 * 17) What are we doing with the Done column?
 * 18) stop using it after current tasks are done  <-- Decided
 * 19) What is an activity period?  A monthish? (Decide Later)
 * 20) Don't need to nail this down - will be informed by data.
 * 21) How much of the backlog has to be well-ordered to have a realistic plan 4-6 months out? (Decide Later)
 * 22) Guessing 100 items.
 * 23) As of 18 June 2015, there are about 50 fully stack-ranked items and 1300+ tied for 51st.
 * 24) Will come back to this in a few weeks or months.
 * 25) Can/should/will we do any ordering outside of the top hundred (or fifty)?
 * 26) Option A: use vague tranches
 * 27) Option B: use "Next Up" columns to hold things above the 1300+ but below the numbered tranches
 * 28) Option C: Use priority field
 * 29) Option D: actually stack-rank (where - in what Projectcolumn? could do this in Backlog column in VisualEditor)
 * 30) Option E: Like Option B but with Epics and Super-Epics
 * 31) What does the Priority field mean for VE tasks?
 * 32) Option A: use the priority field for priority (and if so, how will it interact with the stack-ranking)
 * 33) Option B: severity as perceived by reporter <-- Decided
 * 34) Option C: something else
 * 35) Option D: ignore it

Goals

 * 1) What exactly is “goals”?  Objectives, Key Results, Milestones?
 * 2) What is the relationship between milestones and KRs (same thing, or one is child of other, or peers?)
 * 3) What is the best data structure for goal-related
 * 4) Separate levels of Goal, Epic, Task, so that each Task has 1 Epic parent and each Epic has 1 Goal parent?
 * 5) Or put many assorted tasks into grab-bag Epics and Goals?
 * 6) What are the useful queries for different stakeholder groups, and does this design support them?
 * 7) What are the edge cases?  E.g., Tasks which are technically small but have complex implications or dependencies - treat as Task and pass-through Epic, or Task is Epic, or Task rolls up into catch-all Epic?
 * 8) How exactly do we get the roadmap back from this?
 * 9) Is it the list of Epics?
 * 10) How do we relate OKRs to tasks?
 * 11) Leave OKR in Wiki pages, don't link tasks to OKRs
 * 12) Leave objective in wiki page, create a tranche projectcolumn for each key result
 * 13) Put tasks into the related tranche
 * 14) Leave objective in wiki page, create a task for each KR
 * 15) Make related tasks blockers of of the KR tracking task
 * 16) Create task for each objective and create subtasks for each tracking task
 * 17) Make related tasks blockers of of the KR tracking task

Estimation

 * 1) How are Epics estimated?
 * 2) *Option A: Use "Epic Points", either 1/2/4/8/16 or Fibonacci, which are separate from Story Points but calibrated to them
 * 3) *Option B: Use very big numbers of Story Points <-- Decided
 * 4) *Option C: Use T-shirt sizing (S/M/L/XL), correlate to Story Points via calibration sample
 * 5) How far through the backlog should we estimate?
 * 6) Option A: All stack-ranked <-- Decided (need to try for 1-4 weeks and see if this satisfies Option E)
 * 7) Option B: All stack-ranked plus all Next Ups
 * 8) Option C: All stack-ranked, and others as touched/needed
 * 9) Option D: all 1300 :)
 * 10) Option E: Enough to get 3-5 months' visibility
 * 11) who does it for initial catchup? James, Done.
 * 12) Who does it on an ongoing basis?
 * 13) James
 * Ed
 * 1) Neil
 * 2) Rotating
 * 3) Some two-level pass of initial + validation
 * 4) Are there homogeneous groups of tasks that can be assigned the average estimate from a subset?
 * 5) The full 1300, based on average of all estimated tasks (including history, not including history?
 * 6) No <-- Decided
 * 7) some other set
 * 8) What range of values should we use for velocity? (Decide Later)
 * 9) come back to this