Meeting Notes/2016-08-17 Phlogiston Triage

edit

There are a number of open Phlogiston requests that are all interrelated, as they all have to do with identifying projects of interest in Phabricator.

Results of Triage, in priority order

edit
  1. [1 pt] Import by ID.
    1. https://phabricator.wikimedia.org/T142258, Phlogiston can select projects and tasks to import by project ID
    2. Use case: subprojects, which have a partial names won't match properly without ID matching
    3. TODO: rename task to reflect core use case, which is about renaming [milestones] without messing up Phlogiston categorization.
  2. [2 pts] Categorize by Single ID
    1. https://phabricator.wikimedia.org/T143040, Phlogiston can categorize tasks according to project ID
    2. Match on a single project ID (match on intersection of two IDs already implemented)
    3. Should we solve the entire class of this: match on any number of project IDs, or even match on boolean recipes?
      1. Max: no use case.  Reading web does have a triage funnel query to catch things that uses exclude.
  3. [0]. DUPE. https://phabricator.wikimedia.org/T139814, Phlogiston can categorize tasks according to multiple tags.
    1. Dupe.  TODO: Joel to close as dupe of (find task for original functionality)
  4. [3 pt].  Import everything in Recat, don't have a scope list. 
    1. https://phabricator.wikimedia.org/T143033, Remove or reduce project duplication in Phlogiston config files
    2. scope uses the order of items in the list; have to substitute the priority order (top to bottom, left to right) in the recat
  5. [5 pts].  Import by wildcard.
    1. https://phabricator.wikimedia.org/T139813, Phlogiston can learn about new projects in a scope without manual updating.
    2. Design: treat project name as match substring (e.g., append wildcards to beginning and end)
    3. Alternatives?
      1. subprojects? (is this a dupe of "import by child project" below? probably)
      2. Reading web has mix including community stuff - maybe pull from wiki page or something?
        1. just moves the config file to other places.  But still better from community perspective because that config could be more accessible to community than a github file.
        2. Not urgent.
  6. [5 pts]. List tasks that remain in progress for a while ("shiny objects" that don't get resolved)
    1. Use case "Is someone working on something that she isn't finishing, but which is keeping her from working on other things?"
    2. Currently: look at the doing column and notice that it's been stuck there for 4 days.  But what if it didn't get tagged properly?  how would we notice?
    3. Is there a logical query that would return a list of tasks that are clogging things up, without a lot of false positives?
    4. Currently Phlogiston has only two valid states for tasks: open and resolved.
    5. Have to use column data to identify "in progress"
    6. Possible design:
      1. Report showing # of days each task has been in its current state:
        1. Task ID
        2. Task title
        3. Project
        4. Column
        5. State
        6. Days since ?
          1. since any change at all
            1. This does not have much extra - not much value over Phab query.
          2. since project, column, or state changed.
    7. What is the priority?
      1. This would be #1 for Josh
        1. The most valuable existing feature for Josh is recently closed list: http://phlogiston-dev.wmflabs.org/ios_recently_closed.html
      2. James says he would use it.
  7. [20 pts].  Graph tasks by cycle time
    1. Is this a forthcoming Phab feature?
      1. "Start Tracking Time" on the righthand menu: ex - https://phab-01.wmflabs.org/T82
    2. Because Phabricator has a very limited set of choices for status, have to get this from columns.
    3. Would the list of values be consistent across teams, or would Phlogiston need arbitrary intermediate states?
    4. How would we map this data from Phabricator?  Either Phlogiston would need a different heuristic for each team, or all teams would have to be consistent.
  8. [3 pts].  Recat by wildcard.  https://phabricator.wikimedia.org/T139812, Recategorization configuration accepts in-line wildcards
    1. Currently does wildcard matching for start and end of match string
    2. Not supported: "iOS-foo-bar" matching for "iOS-*-bar"
  9. [8 pt] Import by child project.
    1. Alternate solution to 142258: pull in all child projects.

Priority and Cost/Benefit

edit

Kevin: I would favor limiting work to "blockers". The definition I would use for blocker is: Something that would cause existing users to stop using phlogiston. A more liberal definition would include problems that are causing "significant" pain for existing users or phlog admins.

Max: Cut line is first 5 IMO.

Design

edit

Current design:

edit

Scope file includes a "project list" variable, a list of Phabricator projects, by name, to be imported into a report scope

Recat file is a list of categories.  Each category can be defined by a text string or by a pair of project IDs.  

Proposed new design:

edit
  1. eliminate the project list variable from scope file.
  2. Generate a project list from the recat file
  3. Accept ID or project name match substring

Complications:

edit
  1. In the current design, the project list variable is used to provide precedence order, to make sure that tasks don't get double-counted.  Have to figure out how this even works in the current design, that it can do this but it's still possible to do recategorization based on intersection of two different project IDs.  Shouldn't the double-counting-prevention make it impossible to recategorize based on two projects?
  2. Current design has one field for matchstring for each category, which can contain strings intended to match against project name, column title, or category parent task title.  If we use this string for substring project match, may get false positives.
  3. Could separate out project matchstring from other matchstrings, in both recategorization file and code.
  4. Possibly could bring in some projects that aren't intended, in the corner case where an exact match brings in project X, but a substring match intended to match project X brings in project Xa and Xb as well.