[teampractices] Use cases for work tracking, sub-projects, etc in Phabricator

Max Binder mbinder at wikimedia.org
Tue Mar 1 18:09:24 UTC 2016


I think the appeal of Subprojects is that they offer a new alternative to
the clunky UI that Phab offers for tagging/parenting/columning. What I'd
love to see is what "clunk" is relieved and, inevitably, what clunk is
added. Ultimately, my main issue is that all the ways we've identified, for
tracking tasks in Phab, are lossy. All the options for organizing work
after the fact, but are not terribly approachable (and thus not terribly
sustainable).

   - Parenting is too cumbersome because it's not bidirectional.
   - Tagging is lossy because it's too easy to forget to do it, and
   sometimes the wrong default tags are applied by default (such as when
   creating a subtask).
   - Columns are workable but they cause a loss of priority of tasks across
   columns.

I guess my question/hope for Subprojects is, "Is it easy to use?"

On Mon, Feb 29, 2016 at 3:08 PM, Joel Aufrecht <jaufrecht at wikimedia.org>
wrote:

> Hi,
>
> I'm trying to work out, on behalf of VE, exactly how we would want to use
> the new sub-project and milestone functionality.  Without going into a full
> requirements analysis, I wanted to try to enumerate key use cases and think
> through how they are currently met with Phabricator UI (without
> sub-projects), how we could use sub-projects, and what data model or UI
> changes might be necessary to improve on current processes.  The list below
> starts with VE, and I would be excited to see how other teams are doing
> these things (or what other use cases are important):
>
> *Triage*
>
> *As a Product Owner, I want to categorize and prioritize incoming tasks so
> that they can be worked on by the right people at the right time.*
> VE does this with a weekly triage meeting in which the Product Owner views
> all new tasks in the last week, in order of submission (or reversed), and
> triages one at a time.  Specifically, the PO looks at tasks in the default
> column of the VisualEditor project, edits the Priority field, possibly adds
> a comment, and drags the task to a different column.  In VE, the columns
> represent different
> [initiatives/ultra-milestones/goals/tranches/categories] (for example,
> "Rich Media" or "Language Support").
>
> *Overview (grooming)*
>
> *As a Product Owner with new priorities, I want to alter the backlog for
> my project to reflect new priorities.*
> VE does this via the PO adding and renaming columns and moving tasks
> between columns on the work board.  (All VE work is on a single workboard,
> which means it's all in one project.)  We have also experimented with using
> the "Blocked By" relationship to identify a tree of related tasks, but this
> is not visible in Phabricator workboards (nor can ancestor Blocked-By be
> seen or sorted or filtered on) and can only be seen in Phlogiston reports.
>
>
> *As a Product Owner with knowledge of work in my project, I want to review
> the backlog for my project so that I can see if the backlog is current and
> correct compared to reality.*
> In VE, this has two parts: First, are tasks in right categories?  This
> normally happens in triage, but the Product Owner occasionally notices
> something out of place (a task in the wrong column) while examining the
> board view for other purposes.  Second, are categories right in relation to
> one another?  This happens when the PO looks at the board, but more often
> when the PO looks at the Phlogiston report that shows not only columns but
> also task family (blocked by)-based categorizations.
>
> VE sometimes does overall work planning (in the style of Scrum card
> mapping, where tasks from different areas/columns are all sliced into
> different releases/rows) from the board.  I've already heard that some
> teams have approximated Scrum card mapping by using "dummy tasks" in
> columns, so that tasks above or below that task in a column can be
> perceived to be in a theoretical "row" that may be consistent across
> columns.
>
> The main activity in VE that isn't supported adequately in Phabricator is
> mixing blocked-by relationships and columns.  For example, VE may have 50
> tasks in the "Language" column, and five of those tasks may all be set to
> block a "Release Korean support".  Those six tasks comprise "sub-category"
> within Language, where Language is a broad, long-term grouping and "Release
> Korean support" is a subset with a fixed scope.  There is no way directly
> in Phabricator to see, in one view, which tasks share the same blocking
> relationship.  One way to support this in Phabrictor would be to add a
> display field in the task and/or task card showing the ancestor "blocks"
> task(s).  Currently we can see this in aggregate, but not per-task, in
> Phlogiston reports.  The sub-project construct supports the same underlying
> data relationship, but in a different, reversed way: in Phabricator, you
> can filter on a project and you will see all tasks belonging to
> sub-projects.
>
> *Decide what to work on next*
> *As someone doing work in a project, I want to use category and priority
> and assignment information to figure out which task to work on next.*
>
> Normally, VE team members do this via consultation with the Product Owner,
> but on occasion they navigate to the VE work board and look at the top of
> the columns they are working on to identify new work.
>
> *Definitions*
> "Category" refers to fields differentiating the type of work or subject of
> the work (which software package, which team, which website, etc) that
> people use to filter tasks.  I've seen teams use project tags, project
> columns, blocked by relationships, and tacit conventions about task
> placement within Phabricator project boards, and combinations thereof, to
> categorize work.  "Priority" refers to any task information used to
> determine relative importance; I'm aware of teams using either the Priority
> field, or position and rank within a Phabricator project or columns, or
> both.
>
>
>
> *--Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160301/74ec1cf1/attachment.html>


More information about the teampractices mailing list