Meeting Notes/2015-12-29 Reading Web Phlogiston
Adam, Bryan, Joel, Jon
- 1 Agenda
- 1.1 What does Reading web want in terms of dashboards and metrics?
- 1.2 Review Phlogiston Reading Web charts as-is
- 1.3 Review what Phlogiston can provide (burnups, progress vs milestones, maintenance fraction, velocity backcasts & completion forecasts)
- 1.4 Review what to consider changing in Reading Web Phabricator & Phlogiston config
- 2 Next Steps
- 3 References
What does Reading web want in terms of dashboards and metrics?
Jon: Not clear what we want from burnups, progress, etc. Hoping to start visualizing what's possible. I'm interested in how I can translate the existing Phabricator dashboard into this tool. https://phabricator.wikimedia.org/dashboard/manage/125/
See the relative effort we are investing for the different goals. When we do sprints we don't always finish everything. We estimate stories but at the end of the sprint maybe not everything is done, but also the sense we were distracted by other things; want to see where the effort is going. would be good to be able explain what happened.
Adam: Echoing what Jon said. don't want to do too complex of things; want to understand the burn rate (velocity). Understand what work we ought to be committing to. Some sense of core and maintenance versus new and strategic. The part I'm less clear on is, how sophisticated our input needs to be in order to track work for specific goals.
Jon: looked at prototype Phlogiston, the categories don't quite make sense so would like to fix that in this meeting if we can.
Bryan: Very broad scope of work, tied into very many things. would like at some point to make that manageable. Adding projects, deleting projects, filtering, e.g. "we want things in this project tracked but not if they are in that project". Those will become important questions down the road, though not at the initial kickoff. Example query driving the current Phab dashboard: https://phabricator.wikimedia.org/maniphest/query/dqE6A7iVb6pM/
Review Phlogiston Reading Web charts as-is
Review what Phlogiston can provide (burnups, progress vs milestones, maintenance fraction, velocity backcasts & completion forecasts)
Bryan: need to work with configuration to make sure that the data in the charts is the data we expect.
Jon: should show that. Joel: only if the other work results in resolved tasks in the time period of interest. Is there interrupt that doesn't show up that way? Jon: we close tasks. Bryan: what about something like code review? What does VE do with story pointing community items? Joel: they point all stories they do. (TODO: discuss with James what to do with corner case: community submits issue relevant to Korean but also a bug - is that Interrupt or Korean?) Jon: unless there's some way of spanning multiple projects and sifting through multiple categories.
Jon: edge case: code review (no task), longer task. Maybe we could track all work assigned to people?
Review what to consider changing in Reading Web Phabricator & Phlogiston config
Set up project_list. Adam: So ideally all in 1 project? For Phlogiston, but also I think as a general best practice, to have all of a team's tasks in one project (not only in one project, but at least in 1 master project).
(clarify: all tasks to be counted must be tagged in project_list. Phlogiston will trace parent relationships but only for tasks that are already in the "list")
Bryan: so every time we add a milestone, we have to update the csv? Yes, but there's a feature request to automate that.
Joel: Consider using one project, e.g., "Reading Web Planning", as the master board, and when something is started, leave it on that board and also put it on another board. What are the cons to that approach? Adam: that board will get pretty cluttered. Bryan: At most one click to filter or it's too hard.
JK is emphatic on wanting a single source of truth that these are all the things that he as the product owner thinks should be done for the product. (e.g., no tech debt, no bugs, unless he's approved them)
Joel: could you track maint fraction by checking your list of untagged, resolved every week and tagging them? Is that a lot of work? Adam: should we tag everything up front? Bryan: I haven't seen such a volume that it would be more than maybe 15 min to go back and tag. (followup: would need to be retroactive? Confirm how that works - is maint. fract. based on what tag was applied as of midnight the day it was closed)
Will the board get too big with old stuff? Yes, but there's a "zoom list" feature to hide stuff from the current board, and a feature request to provide an "unzoomed" backup list.
Bryan and Jon to update two configs, send pull request, and then see how it changes.
Bryan to plan: Talk to Joel a couple weeks after all-hands to review.