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

[Joel Aufrecht]

On Tue, Mar 1, 2016 at 10:09 AM, Max Binder <mbinder at wikimedia.org> wrote:

> 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.
>
> What exactly do you mean here?  I can think of:

   - From a child, it should be possible to choose the parent.
      - Currently, this relationship can only be constructed by opening the
      parent, entering the child's name in a search function, and selecting it
      from a list.
      - It would be an improvement simply to be able to type in child IDs
      somewhere on the parent (since that's easier than the name
search thing if
      you have the ID handy), but actually better would be to open the child,
      click "Add Blocks", and pick titles (or IDs)
   - Data model and UI that differentiates between child/parent terms and
   blocked by/blocks.
      - Enforcement of acyclic directed trees for parent-child
   - While looking at a task, see the parent or parents (in the detail, or
   on the card, or in a tooltip for the card).


>    - 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).
>
> What would make tagging (categorizing) less lossy?  The main thing coming
to mind it to easily see untagged things, in order to create a feedback
loop where you can instantly see what's still untagged and tag it.  How
would that work?

>
>    - 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?"
>
It isn't right now, because moving a task from Project to Subproject is no
easier than changing it from Project A to Project B: in both cases you have
to edit the task, choose to change projects, enter a partial name for the
new (sub)project, and select it.  There's no way while looking at a project
board to see the subproject tasks, or even to know what the subprojects are
or that there are any -- you have to click the "Subprojects" option in the
left menu.  So the only benefit in the UI right now for Subprojects is that
you can filter a search by a project and get back subproject's tasks.
Which is a use case I haven't seen any teams need yet, actually.

Milestones have more UI functionality: When you create a Milestone, it by
default is presented as a column in its parent project's workboard.  so you
can assign tasks to Milestones within a project via drag-and-drop, and you
can see all tasks in all Milestones within a project.  If that
functionality were available for Subprojects, that has some immediate uses.


>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160301/b4dfe7c3/attachment.html>