Seems kinda good now? Could maybe use some style/layout tweaks on the table (I'd like resolved tasks to be more obvious, for example), but that graph seems like it's actually pretty good/useful to me at first glance. Need to poke around more.

Now it looks pretty and actually first glance tells something :)

in first glance, I'm not sure if A depends on B or the other way around:

A
|
B

@avivey Do you have any ideas on how to make that more clear? I'm imagining it will probably be obvious on real data when you know what the tasks are and you'll get used to it pretty quickly, but maybe not.

(We could add arrows or something, but I don't think that really disambiguates things because it's not immediately clear if the arrows point at parents or children.)

After looking through real-life applications, this now seems obvious and in @avivey example A is Parent of B. At first glance - there's relation. But yeah, arrows would help, only thing problematic is agreeing on arrow notation.

Not a good idea, but an idea:

(I remember that when discussing this in FB, even the relation between "child/parent-task" and "needs to happen before/after" wasn't trivially clear.)

It's clear enough to me that higher -> more parental. It might be nice to make T123 not a link and bold, like elsewhere, for easy copy-pasta.

I guess that after some exposure, it would be clear; If we're prioritizing experienced users over new ones, it's fine the way it is.

A few tasks (like T2637) are still drawing crazily enormous trees. I think our tasks are especially highly-connected and 97% of what I've looked at seems reasonable, so this might not be much of an issue for other installs, but I think we definitely need some kind of behavior where we hide the more distant parts of the tree once it gets too big.

(I think we might also just have some bad data on old tasks like T2041, since that tree doesn't make sense given what the algorithm is supposed to do.)

T2637 cycles down to itself again

Current task graph is great for visual representation... but can we get somewhere very simple list of blocks/blocked by?

Just FYI, but on this install there's some weird rendering going on:

This is for T5955.

One possible solution might be to make "Task Graph" box "Task Dependecies" and have a separate tab for a straight list (default, parent/sibling only) and graph.

That would be perfect!

I'm leaning toward making it a "Relationships" box with "Task Graph", "Mocks" (with a thumbnail/gallery view instead of just titles), and "Commits/Revisions" (probably with a little more status information than we currently show).

It might be reasonable to add a fourth "direct parents/children" tab which just has a list with no graph, although I want to figure out the paging/collapsing behaviors for large tasks first.

I'm also not sure why this view is interesting, exactly. T11283 appears to describe a task with hundreds (?) of subtasks (this seems unusual -- what is the use case?).

As a possible alternative, we could potentially just mark parents/children more clearly on the graph. For example, we could add a column to the left of the graph with markers like:

• for direct parents
• for the current task (currently highlighted)
• for direct children

It would look a bit like this:

That seems useful if the problem is just difficulty picking out adjacent tasks (although I'm not sure why you necessarily need to), but maybe not useful if the underlying problem is unusual use cases (hundreds of direct subtasks?).

There are also several parent/child/blocking/unblocking query issues connected to T8126, but we could resolve those and just link to the search results page for "Ancestors", "Parents", "Children" or "Descendants" of the current task.

@epriestley, the use case is actually from my content development department. It's hard to explain the task, but the hundreds of direct subtasks was unavoidable, and the project workboard did not work well in their workflow. Developing content for educational software can be extremely demanding. That said, I'll admit it isn't common to have hundreds of subtasks. Still, it is a scenario that can happen, so the UI should still look good given that edge-case.

More commonly, you could have dozens of subtasks (such as many bug reports all relating to a single feature that went haywire), in which case the graph may still look overly large.

Unrelated to that, it was useful to be able to see directly adjacent tasks in the "blocking"/"blocked by" design. It allowed one to "walk up" and "walk down" the blocking tasks to find one that could be done now, while keeping the whole thing in perspective (you know which subtask you're walking down into before selecting one of its sub-subtasks). It is also useful in finding tasks when one doesn't want to have to craft a custom query - you start at the root task and see everything directly attached.

Although the new graph display has the branch-like display at the left, that column is removed from the task titles (2 columns away) - which aren't indented to clearly show the parent-child relationship.

It looks nice and crisp, but I am finding it more difficult to grasp the hierarchy at a glance like title indentation would do.

Perhaps I've gotten too used to P1094 - I am hoping to be able to continue using an indented title display for children tasks, even if they are duplicates due to multiple parents.

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

For example, we could degrade it by simply showing "This task has more than 100 subtasks" and not showing the tasks. Some advantages of doing that is that it's very simple to implement, and very easy to understand, and improves the performance of the page. I have no idea whether this is a good fit for your problem or not since the only information I really have on it is that the problem is "hard to explain". It's possible that all use cases with more than 100 tasks aren't really using the relationship as subtasks, and that the list is not really important.

It's also possible that we could implement (or improve the discoverability of) some other feature (for example, in projects or workboards) to solve this problem better, and then moot the need to accommodate it in this UI. But, again, we can't think about solutions in that vein since we don't really know what the problem is.

These kinds of considerations are why we ask for descriptions of problems, not just desired solutions. When you've already decided what the right solution is ("Make Task Graph Collapsable") it prevents us from finding different or better solutions.

@epriestley, I'm not expecting any particular solution, just as long as the list of subtasks is navigable in some sane fashion.

I'll do my best to explain our use case, but you'll have to believe me that the task/subtask structure is necessary for it. One of the many aspect of the game content is "story packs," which are sets of reading content from various works of fiction and non-fiction. The screenshot is from the umbrella task for story packs. Each story pack is its own task, and that contains four subtasks. We have hundreds of story packs. That department needs the umbrella task for the story packs (vs. a workboard), as they use the prioritization, description, comments, and multiple custom fields inherent to Maniphest tasks.

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

I can share a screenshot if you need it - just say the word.

In T4788#184537, @epriestley wrote:

so the UI should still look good given that edge-case.

Understanding the use case is important in choosing how the UI degrades.

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

In T4788#185751, @bd808 wrote:

The task graph can get a bit out of hand -- https://phabricator.wikimedia.org/T2001

^ Just in case you want a lesson in how not to do task relationships.

The best of the best is of course our https://phabricator.wikimedia.org/T4007 ;-)

Re the limiting to hardcoded 100 nodes without any criteria:

I think the most intuitive would be limiting to the first level of dependencies (ie. show direct children, but no further descendants*) and also show only direct line to the root (= don't show other tasks which the parent, grandparent, ... depend on).

* however, those might be expandable to the next single level via AJAX request

Also, before that is done, rather than showing "Task graph too large to display ..." message, have fallback to the old plain list of tasks. Therefore the information will still be available, but just simply not provided as fancy...

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

+1. The hysterical raisin for why we have tasks with a huge number of subtasks is that they are an artifact of our Bugzilla use, which didn't make it easy to make new "components" for short-lived projects. We had "tracking" tasks which had a bunch of blocking tasks. We even had a meta tracking task, which all of the tracking tasks were blockers of. As you can imagine, that doesn't make sense in the world of Phabricator and is an (our) anomaly.

In T4788#185851, @chad wrote:

If you have more than 100 subtasks, the task should probably be a project so it can be properly organized.

(Not that I wouldn't agree, but I'm pointing out the real situation.)

First of all, the task graph doesn't show subtasks only, but parent tasks as well.

Second: Using Agile and having things Epic → Story → Task → Subtask can simply result in tree with 100+ tasks in it. (Example from real life - I've experienced tracker where they have used separate tasks for each of M, V, C component of MVC architecture. Dependency tree was not deep, but wide.)

Another thing is, that the dependency tree shows everything what is somehow connected together. So you can easily have 3 trees with 34 members (which is reasonable as standalone tree) but since they will meet in some points (furthermore not necessarily in the same one), suddenly the displayed tree would be bigger than 100...

It might be useful if the dependency resolution was only two-levels deep. That wouldn't really solve the problem for extremely wide trees though.

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

In T4788#185925, @CodeMouse92 wrote:

[...] Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations [...]

+1 to exploring this potential solution, or to just showing a subset of the graph but the full listing. [and otherwise, I love this feature. ty!]

See T4788#184477 for current plans.

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

Just a indentation is fairly good:

• task1
  • sub1task
  • sub1task
    • sub2task
    • sub2task
  • sub1task
  • sub1task

Count of sub tasks will no affect the width, only depth.

Not a thoughtful idea, thanks phabricator.

@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

• Dependencies can be edited both ways in all applications with relationship dependencies.
• Task dependencies are now rendered as a graph.
  • If a task has fewer than 100 related tasks, the entire graph is shown.
  • If a task has more than 100 related tasks, but no more than 100 directly related (parent/child) tasks, only directly related tasks are shown.
    • In this mode, the graph itself is not drawn, since it is implied by the parent/child markers.
  • If a task has more than 100 related tasks, and more than 100 directly related (parent/child) tasks, the graph UI is not shown at all (instead, the text "Task graph too large to display..." is shown).
• Selecting Search... → Search Parent Tasks or Search... → Search Subtasks from the dropdown near the graph will take you to a query result view listing all parents or children, regardless of how many there are, as a search result.
  • You can apply additional filtering to this to find, e.g., open subtasks or unassigned subtasks; or bulk-edit the results. This UI will use pagination to accommodate arbitrarily large result sets.
• A new "Mentions" tab shows objects which mention the current task and objects which the current task mentions.

Here's some additional context:

More Than 100 Subtasks: I don't recommend making tasks with more than 100 subtasks. Instead, use projects to organize large bodies of work which need to be split into more than 100 distinct pieces.

Maniphest should now handle tasks with more than 100 subtasks reasonably well, but I don't expect parent tasks to be good at organizing huge lists of work. They aren't a tool built for doing this, and I haven't seen any use cases presented which present compelling arguments that they should be built for doing this (see T4788#184537 for discussion of why use cases are important):

• @CodeMouse92 presented a use case in T4788#184632 but couldn't explain it ("you'll have to believe me").
• WMF presented several use cases in this task, but the consensus seemed to be that they shouldn't really be parent/child tasks, there was just a legacy reason that those relationships existed. Major issue just seemed to be the UI not handling them with even a modicum of grace. We should now handle those tasks reasonably, they just aren't built to serve as great containers.
• @rrfeng presented a screenshot showing a possible use case in T11680, but did not explain the use case.
• @Danny_B presented a use case in T4788#185923, but it was hypothetical; did not explain why tasks (vs projects) should be used for epics/stories; and the UI should now accommodate this case reasonably well.

If you have a task with more than 100 subtasks, use Search... → Search Subtasks to review and manage them. This workflow now lets you find open subtasks, unassigned subtasks, subtasks in certain projects, etc. You can also bulk edit results from this workflow.

Indentation: I have no plans to ever pursue an indentation-based task graph UI.

As discussed elsewhere, indentation can not show a graph without duplicating nodes, because dependencies may exist like A → B, A → C, B → D, C → D. These dependencies create this graph shape:

This graph shape can not be represented as an indented list without duplicating the node D. The list looks like this:

• A
  • B
    • D
  • C
    • D

Note that there are two copies of "D". If "D" had subtasks, there would be two copies of those subtasks.

I think this is very counterintuitive and confusing, and will produce more confusing results with certain graph shapes. I am very hesitant to ship features which I believe to be counterintuitive because they tend to have a high support cost. If a UI isn't clear, we get a lot of questions about why it works like it does or if it's broken. When you see a list full of duplicate nodes, many users' first thought will be "looks like a bug", not "oh, that's an inevitable result of rendering a graph as an indented list". Although there are other ways we could draw this indented graph, I am not satisfied that any are sufficiently clear to avoid becoming a support burden.

I believe graph shapes like this (where grandchildren block multiple children) are reasonable and common, and that allowing these relationships to be represented is very useful.

I believe we've arrived at a reasonable balance of concerns here, and the only

If you are certain that an indented view of subtasks is useful for you despite these problems, you should fork Phabricator and implement it locally.

Other Relationships: I have no plans to pursue other types of relationships, like "followup", "related", "see also", "blocker-but-not-a-subtask", "blocked-but-not-a-parent-task", "child (tree)", "parent (tree)", etc. T10034 has some discussion.

These relationships all seem like they're fairly low-value and overlap a great deal. If we added all of them, it would make the UI much more complex, and I would guess that only a tiny fraction of installs would ever use any of them. These terms are also so similar that I think human users are likely to use them differently, and it decreases the value of these relationships if users use them to indicate different things.

In particular, Phabricator itself would never handle these relationships differently, which I believe to generally be a fairly good litmus test for whether they should be separate relationships or not.

Instead, as a sort of general catch-all tool, I've added a "Mentions" tab which lists all objects which mention the current task, as well as all tasks mentioned in the discussion of the current task. You could already find this information by scrolling through the transaction log and reading everything carefully, it could just be difficult to pick out in long conversations. The new UI makes it easier to find this information quickly.

Although I don't think this is a full solution to any of the requests we've seen for expanded relationships, my hope is that it's a 60% solution for many of them. For example, you can now comment "See some related discussion in T123." and then find that task later in this new tab, even if there's a lot of discussion and you've lost track of your comment. This isn't as formal as a first-class "followup" relationship, but I think it may be helpful for keeping track of loosely-related objects with less-formal relationships.

If you identify bugs with any of this, please file new tasks following Contributing Bug Reports.

If you have further feature requests, please file them separately following Contributing Feature Requests.

(These relationships aren't accessible via the API yet, but T5873 is the broader task for exposing edges via the API.)